Что такое логи

Как читать логи сервера и что это такое?

Логи – это инструмент, при помощи которого можно отслеживать рабочий процесс сервера или сайта. Поэтому знать, как читать логи это полезное умение для выявления сбоев в работе ПО, быстрого и результативного реагирования на другие проблемы (выявление злонамеренных действий), эффективного анализа рабочий процесс, противодействия DDoS-атакам.

Содержание:

Что такое логи и зачем они нужны

Логи (log) – это специальные текстовые файлы, в которых в хронологическом порядке фиксируется информация обо всех действиях программы или пользователей. Проще говоря, это журнал регистрации всех событий происходивших в системе:

Логи доступа указывают на уязвимые места сайта (в случае взлома), помогают собирать статистику посещаемости, узнавать откуда проводились запросы и какие ресурсы ссылаются на этот сайт, оценивать популярность страниц. По файлам ошибок проще найти источник проблемы и оперативно устранить баги и сбои. Журналы сервера (server logs) облегчают контроль рабочего процесса серверной машины.
В файлах логов записывается и отслеживается история работы всего программного комплекса. Поэтому специалисты рекомендуют периодически просматривать их, даже если никаких подозрительных моментов не произошло. И тем более немедленно обратиться к ним, если резко возросло количество ошибок, посыпался спам или заметно увеличилась нагрузка на сервер.

Типы логов и где их найти

Месторасположение логов зависит от используемого ПО, настроек, прописанного админом пути. Чаще всего server logs сохраняются в var/log/. Однако, не все сервисы помещают файлы регистрации в эту директорию. В любом случае, можно уточнить такую информацию у веб-хостера.
У дистрибутивов Linux CentOS или Fedora логи серверной машины лежат в /var/log/. Там можно найти:

Лог ошибок MySQL ($hostname.err) хранится в /var/lib/mysql/. Для Debian или Ubuntu местоположение логов аналогично, за исключением log file ошибок MySQL: /mysql/error.log. А также – логи веб сервера Apache сохраняются по пути /var/log/apache2.
У ОС Windows дружной метод структурирования log-файлов. События делятся на несколько уровней:

Их можно отсортировать или отфильтровать и выбрать необходимое.

Запуск и отключение логов осуществляется с административной панели. Как правило, доступ через раздел «журнал» или «логи». При этом стоит учитывать, что файлы не сохраняются годами. Поэтому, при необходимости посмотреть log, это нужно сделать своевременно.

Какая информация хранится в логах и как ее интерпретировать?

Для большинства пользователей содержимое log-файлов это бессмысленный набор символов. Как читать логи, чтобы понять, что в них зашифровано?
Строка access.log сервера содержит:

Как правило, такой информации достаточно, чтобы проанализировать ситуацию и сделать нужные выводы. Например, заблокировать бота, который создал чрезмерную нагрузку на сайт.
Файл ошибок (error.log) регистрирует моменты, когда что-то пошло не так. Из них можно узнать:

Конечно, даже после расшифровки, данных логов еще нужно проанализировать. Для этого существует различное ПО, которое помогает отрабатывать данные из логов – Weblog Expert, WebAlyzer, Analog, Webtrends, Awstats, SpyLOG Flexolyzer и другие платные и бесплатные программы.

Источник

Логирование: что это и в чем его польза

Система логирования – один из важных моментов в процессе разработки программных продуктов, контроля над работой сервисов, веб-сайтов. Но часто ее недооценивают, не используют своевременно. А необходимость в ней понимают только тогда, когда проект уже находится на этапе сдачи и что-то в нем идет не так и остается только разводить руками. Чтобы этого не произошло, надо знать, что это, запись логов, зачем она нужна, когда и как ее применять на практике. К ней стоит обращаться IT-специалистам, чтобы разобраться, почему не работает или работает некорректно приложение или сайтов. Администраторы, основываясь на логах, смогут причины в сбое сервисов. Используя логирование, система безопасности сможет быстро установить вид взлома, оценить нанесенный ущерб, а в ряде случаев еще и выявить злоумышленника. Но, обо всем по порядку.

Проблемы, с которыми сталкиваются реальные приложения

Чтобы понять, для чего нужны лог файлы, следует знать, с какими проблемами могут столкнуться реальные программные продукты. Так, рассмотрим самый простой сайт. Он включает:

Это самая простая из возможных структур. Но большая часть современных сайтов имеет куда более сложное строение. Огромное количество дополнительных серверов, систем кеширования для ускорения доступа, внешние, в том числе облачные сервисы, очереди, асинхронные коды и многое другое. В результате написанный программистом код обрастает многослойной, разветвленной структурой. И что делать, если произошел сбой? Основная задача – найти, где это случилось и почему. Но в решении она очень сложная. И самое неприятное то, что проблемы могут быть выявлены не на этапе создания продукта, а уже тогда, когда он запушен в работу.

Зачем нужно логирование

И единственный способ эффективно решить ее – проанализировать лог. Осталось только понять, что значит логирование? Речь идет о записи специального текстового файла (лога) с полной информацией о работе программы, действиях пользователей. В результате получается некий журнал, каждая строчка в котором соответствует определенному действию. И если возникает любая непредвиденная ситуация, специалисту надо анализировать логи. Так он сможет узнать, что происходило и когда. Анализируя данные, программист выявит не только проблему, но и те факторы, которые спровоцировали ее появление, сможет понять, возникает ли она постоянно или только при определенных обстоятельствах.

Логи стоит записывать в процессе работы каждого компонента IT-инфраструктуры. Выгоду от его использования получит каждый специалист:

Контроль над приложением необходимо будет продолжить даже после того, как оно пойдет в работу. Это позволит постоянно быть в курсе происходящего, мгновенно реагировать на чрезвычайные происшествия. То есть анализ логов – это одна из обязанностей в работе ИТ-специалистов. Это возможность быстро находить и проблемы, и их источники, устранять их, выявлять конфликты в конфигурационных файлах, следить за безопасностью. Поэтому специалисты не рекомендуют пренебрегать логированием и повсеместно использовать его администрировании бизнеса, при отладке программных продуктов, диагностике проблем как ПО, так и баз данных.

Знакомимся с типами логов

Чтобы процесс работы с логами был более простым и удобным, их разделяют на несколько типов:

Для каждого из них надо создавать отдельный журнал записи в особом формате. Так будет более удобно анализировать состояние продукта, находить источники проблем и инструменты для работы с ними.

Дополнительно предусмотрена классификация логов по степени их важности. Так, к группе Fatal/critical error будут относиться те, которые требуют как можно более быстрого выполнения. Ошибки, которые не будут влиять на работу пользователей стоит записывать в группу Not critical error. В файле Warning будут храниться предупреждающие строки, то есть то, на что стоит обратить внимание. Для записи информации о запросах баз данных, вызовах API или других серверов предусмотрена категория Initial information.

Знакомимся с уровнями логирования

Заниматься логированием необходимо во время разработки и последующей эксплуатации всех IT-систем. Но если так делать, подучим огромное количество файлов и разобраться в них будет крайне сложно. Даже в том случае, если классифицировать их по типам и степени важности. Чтобы не разводить хаос, систематизировать важную информацию, упростить ее последующее использование, предусмотрены уровни логирования. Всего выделяют 4 основных:

Как работать с каждым из этих уровней прописывается в соответствующие методологической документации и внутренних правилах компании. Она определяет последовательность действия специалистов при возникновении той или иной ситуации, порядок обработки каждого из уровней.

Основы грамотного логирования

Чтобы получить файлы логирования, которые будут удобными в последующей работе, следует грамотно подойти к процессу их создания:

Задать вопросы специалистам компании «Xelent, получить профессиональную помощь в логировании, узнать условия сотрудничества можно по телефону или через форму обратной связи.

Источник

Что такое логи logs файл(ы) сайта и зачем они нужны?

log file, лог-файл, логи, logs.

Возможно, вам встречались эти слова?

Хочу рассказать, что это такое и зачем они нужны.

Иногда бывает, нужно посмотреть:

1) ошибки, которые возникали при обращении к сайту;

2) Кто и сколько раз приходил на сайт;

3) Параметры посещений (каким браузером и откуда был выполнен переход и.т.д.);

В общем, нужна статистика сайта.

Конечно, есть современные системы статистики, такие как Google Analytics и Яндекс.Метрика, которые позволяют получать эти данные в удобном виде.

Но, бывают ситуации, что на некоторых сайтах эти системы не установлены, а получить статистику все равно нужно.

Например, произошла какая-то критическая ситуация с сайтом и вам нужно выяснить что произошло, а никаких систем статистики на сайте не было.

Практически на любом сайте, по умолчанию, существуют специальные текстовые файлы, в которые записывается вся информация о посещения и ошибках, которые были на вашем сайте.

Эти файлы и называются логами (log file, log-файлами, лог-файлы, логи).

В общем, логи – это текстовые файлы, в которых хранится информация о посещениях, параметрах посещений вашего сайта и ошибках, которые возникали на нем.

Имя файла логов, для наглядности и чтобы можно было понять их назначение, состоит из двух частей:

Т.е. указывается назначение файла и добавляется приставка «_log».

Данные о посещениях

Данные об ошибках

Логи создаются серверным программным обеспечением. Этим они отличаются от систем Яндекс.Метрика и Google Аналитика, которые работают на основе Javascript-кода. Этот код встраивается на веб-страницы и передается браузером посетителя (клиентом) в базу данных систем статистики, которая хранится уже не на вашем сайте, а на сервере статистики.

Чтобы оставить сообщение, зарегистрируйтесь/войдите на сайт через:

Или зарегистрируйтесь через социальные сети:

Источник

Что такое логирование

Известно, что программисты проводят много времени, отлаживая свои программы, пытаясь разобраться, почему они не работают — или работают неправильно. Когда говорят про отладку, обычно подразумевают либо отладочную печать, либо использование специальных программ – дебагеров. С их помощью отслеживается выполнение кода по шагам, во время которого видно, как меняется содержимое переменных. Эти способы хорошо работают в небольших программах, но в реальных приложениях быстро становятся неэффективными.

Сложность реальных приложений

Возьмем для примера типичный сайт. Что он в себя включает?

И это только самый простой случай. Реальность же значительно сложнее: множество разноплановых серверов, системы кеширования (ускорения доступа), асинхронный код, очереди, внешние сервисы, облачные сервисы. Все это выглядит как многослойный пирог, внутри которого где-то работает написанный нами код. И этот код составляет лишь небольшую часть всего происходящего. Как в такой ситуации понять, на каком этапе был сбой, или все пошло не по плану? Для этого, как минимум, нужно определить, в каком слое произошла ошибка. Но даже это не самое сложное. Об ошибках в работающем приложении узнают не сразу, а уже потом, — когда ошибка случилась и, иногда, больше не воспроизводится.

Логирование

И для всего этого многообразия систем существует единое решение — логирование. В простейшем случае логирование сводится к файлу на диске, куда разные программы записывают (логируют) свои действия во время работы. Такой файл называют логом или журналом. Как правило, внутри лога одна строчка соответствует одному действию.

Выше небольшой кусок лога веб-сервера Хекслета. Из него видно ip-адрес, с которого выполнялся запрос на страницу и какие ресурсы загружались, метод HTTP, ответ бекенда (кода) и размер тела ответа в HTTP. Очень важно наличие даты. Благодаря ей всегда можно найти лог за конкретный период, например на то время, когда возникла ошибка. Для этого логи грепают:

Когда программисты только начинают свой путь, они, часто не зная причину ошибки, опускают руки и говорят «я не знаю, что случилось, и что делать». Опытный же разработчик всегда первым делом говорит «а что в логах?». Анализировать логи — один из базовых навыков в разработке. В любой непонятной ситуации нужно смотреть логи. Логи пишут все программы без исключения, но делают это по-разному и в разные места. Чтобы точно узнать, куда и как, нужно идти в документацию конкретной программы и читать соответствующий раздел документации. Вот несколько примеров:

Многие программы логируют прямо в консоль, например Webpack показывает процесс и результаты сборки:

Во фронтенде файлов нет, поэтому логируют либо прямо в консоль, либо к себе в бекенды (что сложно), либо в специализированные сервисы, такие как LogRocket.

Уровни логирования

Чем больше информации выводится в логах, тем лучше и проще отладка, но когда данных слишком много, то в них тяжело искать нужное. В особо сложных случаях логи могут генерироваться с огромной скоростью и в гигантских размерах. Работать в такой ситуации нелегко. Чтобы как-то сгладить ситуацию, системы логирования вводят разные уровни. Обычно это:

Поддержка уровней осуществляется двумя способами. Во-первых, внутри самой программы расставляют вызовы библиотеки логирования в соответствии с уровнями. Если произошла ошибка, то логируем как error, если это отладочная информация, которая не нужна в обычной ситуации, то уровень debug.

Во-вторых, во время запуска программы указывается уровень логирования, необходимый в конкретной ситуации. По умолчанию используется уровень info, который используется для описания каких-то ключевых и важных вещей. При таком уровне будут выводиться и warning, и error. Если поставить уровень error, то будут выводиться только ошибки. А если debug, то мы получим лог, максимально наполненный данными. Обычно debug приводит к многократному росту выводимой информации.

Уровни логирования, обычно, выставляются через переменную окружения во время запуска программы. Например, так:

Существует и другой подход, основанный не на уровнях, а на пространствах имен. Этот подход получил широкое распространение в JS-среде, и является там основным. Фактически, он построен вокруг одной единственной библиотеки debug для логирования, которой пронизаны практически все JavaScript-библиотеки как на фронтенде, так и на бекенде.

Принцип работы здесь такой. Под нужную ситуацию создается специализированная функция логирования с указанием пространства имен, которая затем используется для всех событий одного процесса. В итоге библиотека позволяет легко отфильтровать только нужные записи, соответствующие нужному пространству.

Запуск с нужным пространством:

Ротация логов

Со временем количество логов становится большим, и с ними нужно что-то делать. Для этого используется ротация логов. Иногда за это отвечает сама программа, но чаще — внешнее приложение, задачей которого является чистка. Эта программа по необходимости разбивает логи на более мелкие файлы, сжимает, перемещает и, если нужно, удаляет. Подобная система встроена в любую операционную систему для работы с логами самой системы и внешних программ, которые могут встраиваться в нее.

С веб-сайтами все еще сложнее. Даже на небольших проектах используется несколько серверов, на каждом из которых свои логи. А в крупных проектах тысячи серверов. Для управления такими системами созданы специализированные программы, которые следят за логами на всех машинах, скачивают их, складывают в заточенные под логи базы данных и предоставляют удобный способ поиска по ним.

Здесь тоже есть несколько путей. Можно воспользоваться готовыми решениями, такими как DataDog Logging, либо устанавливать и настраивать все самостоятельно через, например, ELK Stack

Источник

Тестирование ПО

Цель работы тестировщика

Зачем нужно тестировать софт?

Идёт 2022-й год и такой вопрос задают реже, но ответ на него знать нужно.

Тестировщик вообще нужен бизнесу для того, чтобы снять с разработчиков самую простую работу. Просто потому, что время тестировщика дешевле.

Изучение логов

Логи в стиле Матрицы. Фото: freepik.com

Если у Вас возникли проблемы с работой софта первым делом стоит изучить логи.

Что такое лог

Какие бывают логи

Лог может быть подробным, тогда он занимает больше места на диске и отвлекает больше ресурсов.

Чтобы сократить занимаемое место можно записывать только самые важные события.

Один и тот же софт может иметь несколько режимов логирования. Режим задаётся в настройках и отличается уровнем детализации.

Степень детализации может отличаться очень сильно. От никаких или минимальных записей вроде

2022-03-22-10-06-01T Включился
2022-08-24-00-00-01T Выключился

До записи каждого действия.

Часто одной и той же программе можно указать разный уровень подробности логов.

Далеко не всегда используются все уровни. Например, во встроенном в Python модуле logging уровней всего пять, два из которых (INFO и DEBUG) отключены по умолчанию

Затем возвращать настройки в INFO или WARN для экономии места.

Для работы с логами может пригодится знание скриптовых языков программирования, или текстовых препроцессоров (sed, grep, awk)

Пример: показать только сегодняшние ERROR и WARNING строки из лога а также те, где присутствует слово panic

Где лежат логи в Windows

Лог файл обычно называется по дате, например 2022-08-24-heiheiru-log.txt или 2022-08-24-heiheiru.log

Расположение лог файла обычно зависит от конкретного проекта, например:

У одного клиента логи могут лежать в

Glassfish на Windows server может писать в

Где лежат логи в Linux

В Linux системные логи находятся в

Например, лог утилиты cron за сегодня находится в

Иногда проще спросить расположение логов у разработчика

Зачастую полезно посмотреть, что именно клиент пытается отправить на сервер.

Откройте логи с помощью Notepad++ и сделайте поиск по слову POST

Советую не пренебрегать опцией Find All in Current Document.

Зачастую смотреть полный лог нет смысла. В нём может быть очень много мусора, который легко убрать с помощью текстовых препроцессоров.

Кто должен читать логи: тестировщик или разработчик

Логи для того и созданы, чтобы когда софт работает неправильно тестировщик мог, например по таймкоду, найти проблемное место и приложить нужный кусок лога к баг-репорту.

Конечно, разработчик и сам может всё это сделать. Но его время стоит дороже и для бизнеса выгодно, чтобы всё что может делать тестировщик делал тестировщик.

Тестирование пользовательского ввода

Если есть хотя бы небольшой шанс того, что Вы будете тестировать что-то связаннное с user input, почитайте статью Big List of Naughty Strings

Изучение спецификаций

Перед началом работы над новым проектом Вам нужно будет изучить одну или несколько спецификаций.

То какая информация попадает в одну спецификацию, а какая в другую зачастую завист от менеджера ведущего проект, либо может быть чётко прописана в корпоративных правилах.

В любом случае, в спецификации интерфейсов мы ожидаем увидеть описание API и задача тестировщика здесь сводится к тому, чтобы

Так как логика разработчиков отличается от логики тестировщиков бывает полезным уточнить какие из перечисленных запросов создаются непосредственно клиентами а какие являются вторичными, то есть нуждаются в запросе триггере, который приходит от клиента или бэкенда.

Результатом проверки спецификации интерфейсов будет карта составленная в виде документа, либо просто в воображении тестировщика, которая накладывает на бизнес процессы соответсвующием им запросы либо цепочки запросов.

Контроль версий

Руководств и тренировочных материалов довольно много, моё можете найти в статье «GIT для начинающих»

Чем занимается тестировщик

Нужно помнить, что тестирование сильно зависит от того, в какой компании работает тестировщик.

Это очевидно, но тем не менее акцентирую внимание на том, что очень сложно стать универсальным тестировщиком, разве что сменив несколько работодателей из разных IT сфер.

Я прочитал некоторые вакансии в рунете и в LinkedIn и сделал подборку популярных требований и описаний задач.

Постараюсь перевести их на понятный новичку язык.

Тестирование отдельных задач в тестовом и рабочем окружениях

Если Вы тестируете сервер, который хостится Вашей конторой, то разница только в ответственности.

Покрытие тест-кейсами функционала системы

Означает, что нужно изучить спецификацию и понять, что можно протестировать. Затем описать эти тесты.

Проверка входящих баг-репортов из Tech Support

Клиенты обычно жалуются на баги и не только на баги.

Поддержка не всегда может быстро понять, что к чему, поэтому проще переслать баг-репорт тому тестировщику, который знаком с проектом.

Вы проверяете воспроизводится ли баг в тестовом окружении, если нет, то ковыряетесь в production логах где-нибудь на Kibana.

Функциональное тестирование и отслеживание качества выпускаемого сервиса

Анализ функциональности сервиса

Может означать всё что угодно. Похоже скорее на задание для исследовательского тестирования.

Общение с командой разработки и менеджерами, принятие совместных решений об улучшении сервиса.

Это неотъемлемая часть работы практически любого инженера по тестированию, причём не только софта.

Локализация и документирование дефектов.

Под локализацией обычно понимают выяснение источника проблемы. Это выливается в поиск логов, относящихся непосредственно к ошибке и отслеживанию stack trace.

Документация это: описать что вызывает баг, какое действие клиента или какой конкертно запрос. Максимальное количество полезной информации приветствуется.

Обязательно указывать версию ПО в которой был получен баг и приложить логи.

Оптимизация процесса тестирования внутри команды и постановка задач разработчикам автотестов

Запуск и анализ результатов автотестов

Это очевидное продолжение предыдущего пункта.

Проведение ручного функционального тестирования

Участие в регрессионном тестировании

Регрессионное тестирование обычно означает следующее. У Вас уже есть работающий продукт, но к нему пришёл Change Request (CR) и разработчики сделали новую фичу.

Фича работает, но теперь нужно понять не сломала ли новая фича что-то из старого функционала.

Ведение тестовой документации, подготовка тест кейсов

Рутина, без которой никуда особенно в большиъ компаниях.

Регистрация найденных дефектов в баг-трекере, контроль их исправления.

Назначение баг-трекеров это упрощение контроля за ошибками.

Взаимодействие с командой разработки.

2019-01-10 10:01:15 [ERROR]: Something is not ok

О ней написан репорт. Разработчик выпустил фикс. Тестировщик проверил и не увидев больше этого предупреждения в логах зааксептил.

Прошла неделя, тестировщик тестирует совершенно другую историю и вдруг

2019-01-17 10:01:15 [DEBUG]: Something is not ok

Тестировщик звонит разработчику и говорит, что ошибка снова появилась.

Присылайте свои истории в комментарии. Лучшие я включу в статью.

Куда складывают задачи и/или баги

Список планировщиков проектов и багтрекеров:

Источник

Необходимо ли логирование программ?

Мне часто приходилось сталкиваться с полным отсутствием понимания назначения логирования в приложениях, хотя система логирования это далеко не второстепенная фаза в разработке проекта. Но, зачастую, люди это понимают уже на стадии сдачи поекта, когда введение полноценной системы логирования — процесс достаточно затратный и как результат, оставляют все как есть. Что в результате имеем? А имеем мы систему, в которой любая проблема у заказчика превращается в головную боль разработчика, т.к невозможно восстановить причины возникновения проблемы у заказчика, т.е у разработчика есть только описание проблемы от человека, у которого эта проблема воспроизвелась. К сожалению, мы живем не в идеальном мире и как правило описания проблемы носит малоинформативный характер, т.к пользователи системы не являются грамотными тестерами и не могут описать проблему подробно(есть конечно приятные исключения, но их мало). Особенно остро проблема логирования стоит когда нет возможности воспроизведения проблемы на своей стороне.

Реализация:

#include string >
#include
#include
#include
#include
#include

namespace smart_log
<
typedef void (*ErrorHandler)( const std:: string &);
typedef const std:: string (*Obfuscater)( const std:: string &);
//This type provides constant which set the writing log mode.
//If a current mode is bigger then methods mode the writing will be ignored.
//It needs for log flood control
enum LogLevel;

struct LogParameters
<
std:: string m_strLogFileName;
//Pointer to a function which does appropriate manipulations in case of a log corruption. Set to 0 if it doesn’t need.
ErrorHandler m_pErrorHandler;
//Pointer to a function which obfuscates each string writing to a log file. Set to 0 if it doesn’t need.
Obfuscater m_pObfuscater;
size_t m_uiLogMaxSize;
unsigned short m_siMaxSavedLogs;
//Is the thread synchronization needed?
bool m_bIsMultiThreaded;
//Indicates whether log will be saved or not. If this flag is set then log will be saved when its size exceed m_uiLogMaxSize.
//Use m_siMaxSavedLogs to control how many log files will be saved. If the current number of log files has reached the m_siMaxSavedLogs then
//new saved log would replace the oldest one.
bool m_bIsSaveLog;
LogLevel m_xLogLevel;
//Path to the log location. It will be created if no exists.
boost::filesystem::path m_xLogSavedPath;
>;

class Logger
<
//—————————————Data
size_t m_uiCurrentLogSize;
short int m_siCurrentSavedLogs;
LogParameters m_xParameters;
std::ofstream m_xOfstream;
boost::interprocess::named_mutex m_xMutex;
//File name with full path in which it will be create
boost::filesystem::path m_xFullFileName;
//—————————————Internal methods
private :
//Common method for message writing
void WriteLog(LogLevel xLevel, const std:: string & strMessage);
void HandleLogSizeExcess();
std:: string Timestamp();
void CreatePath(boost::filesystem::path xPath);
//—————————————Interface
public :
Logger( const LogParameters& xParameters);

//Set of methods which concretize the common WriteLog method to log levels.
void WriteNormalLog( const std::ostringstream& strMessage)
<
WriteLog( eNormal, strMessage.str() );
>
void WriteExtendedLog( const std::ostringstream& strMessage)
<
WriteLog( eExtended, strMessage.str() );
>
void WriteDebugLog( const std::ostringstream& strMessage)
<
WriteLog( eDebug, strMessage.str() );
>
//————————————Setters
void SetErrorHandler(ErrorHandler pErrorHandler)
<
m_xParameters.m_pErrorHandler = pErrorHandler;
>
void SetLogMode(LogLevel xLevel)
<
m_xParameters.m_xLogLevel = xLevel;
>
>;
>
#endif _LOGGER_

namespace fs = boost::filesystem;
namespace multiprocess = boost::interprocess;
using namespace smart_log;

void Logger::WriteLog(LogLevel xLevel, const std:: string & strMessage)
try
<
multiprocess::scoped_lock xLock;
if (m_xParameters.m_bIsMultiThreaded)
<
xLock = multiprocess::scoped_lock (m_xMutex, multiprocess::defer_lock_type());
xLock. lock ();
>
CreatePath(m_xParameters.m_xLogSavedPath);

>
catch (fs::basic_filesystem_error )
<
if (m_xParameters.m_pErrorHandler)
m_xParameters.m_pErrorHandler( «Problem with a directory creation» );
else
throw ;
>

std:: string Logger::Timestamp()
<
SYSTEMTIME xTime;
::GetSystemTime(&xTime);
std::ostringstream xStream;
xStream «.»
«.»
«-»
«.»
«.»
«.»
return xStream.str();
>

Пример создания удобного интерфейса к классу:

class LogInstance
<
static boost::scoped_ptr m_spLogger;
public :
static const boost::scoped_ptr & GetLog()
<
if (!m_spLogger)
<
smart_log::LogParameters xParams;
xParams.m_bIsMultiThreaded = true ;
xParams.m_pErrorHandler = 0;
xParams.m_pObfuscater = 0;
xParams.m_siMaxSavedLogs = 0;
xParams.m_strLogFileName = «log_file» ;
xParams.m_uiLogMaxSize = 8192;
xParams.m_xLogLevel = smart_log::eNormal;
xParams.m_xLogSavedPath = «./log/log/log» ;
m_spLogger.reset( new smart_log::Logger(xParams));
>
return m_spLogger;
>

#define NORMAL_LOG(MSG)\
<\
std::ostringstream xStrm;\
xStrm «: » » » «(): » WriteNormalLog(xStrm);\
>
#define EXTENDED_LOG(MSG)\
<\
std::ostringstream xStrm;\
xStrm «: » » » «(): » WriteExtendedLog(xStrm);\
>
#define DEBUG_LOG(MSG)\
<\
std::ostringstream xStrm;\
xStrm «: » » » «(): » WriteDebugLog(xStrm);\
>

Надеюсь этим постом я сподвигну людей не использующих логи, на их использование и надеюсь моя реализацию будет им полезна. Удачной всем отладки 🙂

Источник

Логи. зачем, почему, как.

Условия:
— в машине не более двух человек (вы — рулите, пассажир — снимает лог. либо вариант — вы рулите а лог снимается сам ).
— двигатель полностью прогрет
— выключен кондиционер (не горит кнопка АС на ручном кондиционере; климат-контроль в положении ECON)
— выключены системы ASR/ESP (на приборной панели горит индикатор в кружочке, кнопка ASR/ESP на центральной консоли горит желтым)
— все боковые стекла закрыты
— имеется кусок прямой дороги ВНЕ населенного пункта протяженностью не менее 1.5км с идеальным, сухим, асфальтовым покрытием, без пешеходных переходов и каких либо препятствий. Скорость на конец записи лога в некоторых случаях может достигать 180 км/ч если не уверены — не подвергайте себя и окружающих опасности! все делаете исключительно на свой страх и риск!

Механика процесса:
1) подключаем диагностический кабель к машине, запускаем vag-com
2) залезаем в контроллер двигателя (Двигатель 01), выбираем канал «измерения 08», вводим номера требуемых для записи групп (максимум — три. какие конкретно — смотрим ниже) с параметрами основных датчиков, внизу на этой же вкладке жмем кнопку Лог (при этом становится доступно меню по названию лог-файла и месту его расположения на жестком диске. если не требуется чего-то дополнительного — оставляем все так как нам предлагает программа). Все, система готова для записи лога (кнопкой старт мы начинаем записывать лог, кнопкой стоп останавливаем запись лога).
3) включаем запись Лога нажатием кнопки старт.

Эта же последовательность действий в видеоинструкции (спасибо Владимиру kishunv ):
качаем инструкцию по этой ссылке

4) трогаемся и разгоняемся по прямой до скорости, при которой на 3 ПЕРЕДАЧЕ на МИНИМАЛЬНО возможных оборотах (примерно в районе 1100-1200 об.) может ехать машина (в случае АКПП — необходимо перевести коробку в режим типтроника, и выбрать третью передачу, либо выставить третью передачу на селекторе и дать переключиться коробке до 3-й передачи). Вдавливаем относительно быстро педаль акселераторав пол до упора (для владельцев АКПП — педаль газа нужно продавить так что бы при этом НЕ сработал режим кик-дауна, когда коробка резко переключится на передачу вниз) и не отжимаем её ни на миллиметр до достижении мотором 6000-6300 оборотов. (для дизеля до 4000-4200 оборотов).
5) бросаем газ, тормозим, останавливаем запись лога нажатием кнопки стоп (там где была кнопка старт до начала записи ).

В процессе снятия лога постоянно контролируйте имеющееся у вас в запасе расстояние для нормального безопасного торможения не отвлекайтесь на ноутбук, там все записывается и без вашего участия

Всё, лог записан. стирайте со лба пот и радуйтесь вновь освоенному ремеслу возвращайтесь домой для того что бы выложить записанный вами лог-файл на форум в профильную ветку и ждать оценки вашего творчества коллегами по цеху (к слову, сказать по логам пора «капиталить» мотор или нет — нельзя…посему — в ожидании оценки можете сильно не волноваться ).

1) для моторов 1.8Т с буквенными кодами APU, ANB, ATW, AUG, AWM, AWT (М7.X, имеющих датчик давления наддува) — 003/114/115 и 003/020/031 (два лога). после записи лога посмотреть на холостом ходу значения в первых двух полях 032-ой группы (запомнить/переписать, указать их в сообщении при выкладывании лога на форуме).
2) для мотора 1.8Т с буквенным кодом АЕВ (М3.X) — 002/013/024 и 002/024/025 (два лога). после записи лога посмотреть на холостом ходу значения в первых двух полях 008-ой группы (запомнить/переписать, указать их в сообщении при выкладывании лога на форуме). для мотора 1.8Т с буквенным кодом АЕВ (М5.Х) — 002/020/114. после записи лога посмотреть на холостом ходу значения в первых двух полях 032-ой группы (запомнить/переписать, указать их в сообщении при выкладывании лога на форуме).
3) для моторов 2.8 V6 с буквенными кодами ACK, APR (М3.X и М7.X) — 002/003/020 и 002/020/021 (два лога). после записи лога посмотреть на холостом ходу значения всех четырех полей 008-ой(ACK)/032-ой(APR) группы (запомнить/переписать, указать их в сообщении при выкладывании лога на форуме).
4) для моторов 2.8 V6 с буквенными кодами ATQ, AMX, BBG (МЕ 7.X) — 003/020/021 и 002/003/031 (два лога). после записи лога посмотреть на холостом ходу значения всех четырех полей 032-ой группы (запомнить/переписать, указать их в сообщении при выкладывании лога на форуме).
5) для моторов 2.0 (20V) с буквенным кодом ALT (МЕ 7.X) — 002/003/020 (один лог). после записи лога посмотреть на холостом ходу в первых двух полях 032-ой группы (запомнить/переписать, указать их в сообщении при выкладывании лога на форуме).
список будет обновляться по мере поступления информации и наличии свободного времени…
помните, что по ЛЮБОМУ из этих параметров вы сможете снять лог и оценить (при наличии знаний и/или добрых людей ) работу интересующей вас системы в требуемых условиях.

Ну и для тех кто дочитал до этого момента, поняв в себе прилив новых сил и знаний, выкладываем программу для самостоятельного просмотра снятых вами логов dp_logview_rus11.zip (если по каким то причинам эта версия не открывает ваши логи — пробуйте более раннюю версию dp_logview_rus.zip), за последнюю, адаптированную под криворукие русификаторы vag-com-а, версию этого вьюера логов уважение и почет Алексею kalex

Те, кто не смог подружиться с установкой/использованием выше указанного вьюера — могут воспользоваться онлайн сервисом для просмотра логов #

Самостоятельный анализ снятых логов на примере мотора 1.8Т:

Немного о той скромной практике расшифровки логов 1.8Т и интерпретации данных с различных датчиков наших авто. Сразу оговорка – все двигатели абсолютно разные по степени износа, качеству обслуживания и т.п. Поэтому материал крайне поверхностный и не претендует на полный объем информации. Итак:

Соленоид N75 – (смотрим в 025 АЕВ /114 APU, ANB, ATW, AUG, AWM, AWT и АЕВ с блоком управления М5.9 (американская версия)) – его сложная работа заключается в поддержании давления наддува (понижении или повышении) во всем диапазоне оборотов двигателя. Управляется ШИМ сигналом (широтно-импульсная модуляция) — соленоид при этом открывает то одну, то другую магистраль в соответствии с управляющим сигналом, степень открытия этого клапана меняется от 5% до 95%. В свою очередь клапан управляет клапаном вестгейта (WG) – «калиткой» — в «горячей» части турбины, приоткрывая ее для снижения наддува или закрывая – для увеличения.
В случае отсутствия сигнала (повреждена проводка, ошибка 01262) клапан N75 открыт и весь наддув подается на актуатор (механизм управления тягой калитки WG), который и стравливает его минуя горячую крыльчатку через клапан весгейта – наддува выше 0.3 не получим. При снятии и расшифровке логов обращать внимание на % тактирования клапана, который косвенно покажет производительность турбины: 90% и выше – система набирает наддув, после 2200 – 2300 об/мин % должен упасть до 50-60, что скажет о том, что турбокомпрессор в хорошем состоянии. Если в рабочем диапазоне от 2400 до 4700 скважность клапана не опустится ниже 75-80 %, можно говорить о том, что турбина уже «уставшая» либо в турботракте до интеркуллера присутствует дыра через которую стравливается не зарегестрированный датчик давления наддув. На чипе процент тактования будет выше: в районе 75% (турбокомпрессор работает с большей нагрузкой).

Еще один важный параметр, который рассматривается при расшифровке логов – лямбда регулирование – (смотрим в 008 АЕВ/031 ANB, ATW, AUG, AWM, AWT) – коррекция топливной смеси по сигналам с лямбда-зондов (ЛЗ). ЛЗ (являющийся датчиком кислорода) передает сигнал в ЭБУД о концентрации кислорода в отработавших газах, по сигналу ЛЗ оптимизируется состав рабочей смеси в сторону обогащения или обеднения. Правильная стехиометрическая смесь (это соотношение воздуха и топлива 14.7: 1 = L) даст не только паспортную мощность двигателя, правильную работу форсунок и катализатора, но и экономию топлива в спокойных режимах. Если L 1, значит налицо избыток воздуха, смесь бедная. Мощность при L=1,05 — 1,3 падает, но зато экономичность растет. При L > 1,3 смесь перестает воспламеняться, и начинаются пропуски в зажигании. Бензиновые двигатели развивают максимальную мощность при недостатке воздуха в 5-15% (L=0,85 — 0,95), тогда как минимальный расход топлива достигается при избытке воздуха в 10-20%% (L=1,1 — 1,2). То есть соотношение L при работе двигателя постоянно меняется и диапазон 0,9 — 1,1 является рабочим диапазоном лямбда-регулирования.
На практике правильной смеси нет — чаще в логах наблюдается обеднение, что говорит о проблемах с подачей топлива, не корректных показаниях ДМРВ, возможной негерметичности турботракта и т.п. Хорошие данные ЛЗ примерно такие: на минимальных оборотах: 1300-1500 – 0.950, постепенно «богатеет» до 0.750 в пике – при 5700 об/мин.

Данные 032 группы, при условии корректно работающих лямбда-зондов, следует рассматривать так (для 008 группы по аналогии):

Аддитив (032 группа 1-ое поле):
положительный (бедная смесь в режиме ХХ) — негерметичность впуского тракта, некорректная работа обратных клапанов в системе ВКГ, недостаточное давление топлива.
отрицательный (богатая смесь в режиме ХХ) — высокое давление топлива, негерметичность форсунок, датчик температуры ОЖ, некорректная работа обратных клапанов в системе ВКГ.
Мультипликатив (032 группа 2-ое поле):
положительный (бедная смесь в режиме нагрузок) — чаще всего недостаточная производительность топливного насоса или низкое давление в топливной рампе (работа РДТ), дыры в турботракте, некорректная работа дмрв.
отрицательный (богатая смесь в режиме нагрузок) — негерметичность впускного тракта после тубины, дмрв, некорректная работа форсунок (текут), датчик температуры ОЖ.

Источник

Логи сервера

Сервер хостинга — довольно самостоятельная система. Если все настроено правильно, его программы могут месяцами работать без вмешательства человека. При этом на сервере постоянно происходит множество событий:

Для контроля и анализа всего этого и ведутся логи.

Что такое logs server или логи сервера? Это текстовые файлы, в которых протоколируется информация о всех событиях на сервере. Log server переводится как «журнал сервера». Запись информации проводится автоматически.

В статье мы рассмотрим, какие виды логов бывают, как устроены логи, как их найти и прочитать и т. д.

Виды логов

Существует несколько типов логов сервера:

Каждое ПО часто ведет свои собственные логи. Так, на сервере хостинга отдельно протоколируются события:

Где можно найти логи сервера

Посмотреть логи сервера можно:

Что касается панели хостинга, то здесь логи часто размещают прямо в веб-интерфейсе панели, в разделах с аналогичным названием: «лог FTP-сервера», «лог ошибок сайта». Точное расположение разделов можно посмотреть в справке или уточнить у техподдержки.

На виртуальном или выделенном сервере журналы сервера ищем на жёстком диске. В зависимости от типа сервера, операционной системы, настроек программного обеспечения точное местоположение может быть разным — уточните у техподдержки, где искать тот или иной лог. Но есть универсальные моменты, которые помогут вам найти логи самостоятельно:

Зачем нужно смотреть логи?

Часто о логах никто не вспоминает, пока не появляются проблемы: сайт тормозит, сайт взломали. Правильнее смотреть логи сервера регулярно. Тем более, многие хостеры хранят некоторые виды логов непродолжительное время: 2 недели, месяц, 3 месяца.

Просматривая логи, можно увидеть:

Обнаружив начинающиеся проблемы заранее, можно предпринять соответствующие меры: заблокировать зловредные IP-адреса, оптимизировать SQL-запросы, перейти на тариф с большим количеством ресурсов.

Как читать логи

Логи в панели управления хостингом представлены в удобном виде в виде таблиц. Например, лог FTP-сервера на хостинге содержит колонки:

Логи сервера на жестком диске представляют собой текстовые файлы, в которых в хронологическом порядке записывается информация. Открыть их можно любым текстовым редактором, предпочтительно специализированным, например, Notepad+++. Данные представлены в виде строк с разделителями и на первый взгляд часто выглядят как непонятное смешение символов.

Для удобного чтения можно скачать логи и просмотреть их через специальные программы: Analog, Weblog Expert и другие.

Логи сервера Windows более структурированы и понятны для изучения. В них есть несколько уровней событий: ошибка, предупреждение, информация, подробные сведения. Отдельно выделяются критические события.

Как проверить логи, если у вас VPS-сервер

Пользователям, арендующим VPS-сервер, для доступа к логам можно:

Как проверить логи на хостинге

Расскажем, как найти логи сервера в разных типах панели управления хостингом. Будем искать файлы логов, а не их представление в веб-интерфейсе панели.

В ISPmanager

В Менеджере файлов зайдите в папку logs, найдите и скачайте нужный файл. Просматривайте логи на своем ПК или ноуте.

В CPanel

Аналогично описанному выше, только внутренний файл-менеджер называется «Диспетчер файлов».

В Plesk

Здесь, чтобы зайти в папку logs и загрузить на свой ПК логи, вам нужно войти на вкладку «Файлы».

Источник

Как читать логи сервера

Что такое логи?

Краткая справка из Википедии:

Файл регистрации, протокол, журнал или лог (англ. log) — файл с записями о событиях в хронологическом порядке. Различают регистрацию внешних событий и протоколирование работы самой программы, источника записей (хотя часто всё записывается в единый файл). Например, в лог-файлы веб-сервера записывается информация, откуда пришёл тот либо иной посетитель, когда и сколько времени он провел на сайте, что там смотрел и скачивал, какой у него браузер и какой IP-адрес у его компьютера.

Для чего нужны логи?

Обычно при нормально работающем сайте лог-файлами мало кто интересуется, но когда начинает расти нагрузка на сервер, запускается рассылка спама, а сайт начинает вести себя довольно странно или изобиловать ошибками, без логов не обойтись.

Как включить запись логов?

Обычно для экономии дискового пространства ведение логов на хостинге выключено.

Приведу включение записи на примере панели управления хостингом Timeweb.

В панели управления переходим во вкладку «Логи», выбираем из выпадающего сайта нужный (если их несколько) и активируем ползунок «Лог доступа (access_log)»

Примерно через час, когда накопится достаточное количество записей, переходим в директорию сайта и скачиваем файл.

Открываем в любом текстовом редакторе (на примере второй столбец, с адресом сайта закрашен).

Разберем для примера строку № 49

Даже при беглом взгляде видно, что с адреса 85.93.93.102 идет множество запросов. Обращение было как раз по чрезмерной нагрузке на сайт. Как только адрес бота Linguee Bot был запрещен, нагрузка практически сразу вернулась в норму.

И все за несколько минут, благодаря логам; без них на выяснение причины понадобилось бы гораздо больше времени. Также были замечены обращения по адресам, содержавшим вставки типа xd0\xbe\xd1\x82\xd0\xb7\ …

Тот, кто занимается «лечением» сайтов, знает, что подобные запросы могут создавать запредельные нагрузки на сервер.

Иногда самые простые методы – самые действенные, а защита на уровне сервера самая надежная.

Источник

Логи сервера

Если вы хотите знать всё про логи сервера, читайте нашу статью. Мы расскажем, что такое logs, для чего они нужны и покажем, как посмотреть их.

Что такое логи

Чтобы объяснить, что такое логи сервера, скажем несколько слов о самих серверах.

На серверах хранятся файлы сайтов. Чтобы перейти на сайт, пользователь заходит в браузер и вбивает запрос. Затем браузер обращается к серверу, получает файлы нужного сайта и отображает их пользователю. Попадая на сайт, посетитель совершает различные действия — переходит на страницы, оформляет заказ, совершает оплату и другое. При каждом действии посетитель и сервер взаимодействуют друг с другом на уровне интернет-системы.

Логи — это текстовые файлы, в которых хранится информация о пользователях, их взаимодействии с сервером, а также системная информация о работе сервера. Логи формируются в автоматическом режиме и сохраняются в хронологическом порядке. Поэтому их также называют журналом сервера (Server Logs).

Можно выделить несколько основных типов логов:

Где хранятся логи сервера

В некоторых случаях для хранения логов используют отдельный файловый сервер. Но чаще всего логи хранятся на жёстком диске основного сервера. Они располагаются в корневой директории хостинга в системной папке logs. Точный путь до лога будет зависеть от операционной системы сервера. Например, логи SSH Ubuntu хранятся в /var/log/auth.log, а логи SSH CentOS в /var/log/secure.

Зачем проверять логи

Чаще всего обращаться к содержимому логов и анализировать его приходится системным администраторам. Анализ логов необходим в следующих ситуациях:

Однако уметь анализировать журнал полезно не только админам, но и владельцам сайтов и другим пользователям с доступом в админку. Для этого нужно понимать, как устроены логи.

Как устроены логи

Каждый тип logs имеет свою структуру. В качестве примера разберём структуру access_log:

Также структура логов зависит от операционной системы сервера. Например, логи сервера Windows устроены в виде структурированной таблицы. Поэтому, чтобы научиться «читать» логи, нужна практика.

Если вы разобрались со структурой logs, можно приступать к их просмотру. Существует несколько способов, с помощью которых можно посмотреть журнал сайта. Выбор способа будет зависеть от типа платформы, на которой расположен ваш сайт — VPS-сервер или хостинг.

Как проверить логи сервера VPS

Чтобы посмотреть логи:

Введите команды cd logs и ls —all, чтобы посмотреть содержимое папки logs: Логи сервера Linux

Как проверить логи хостинга

Чтобы посмотреть содержимое журнала, нужно открыть папку и скачать нужный файл на локальный ПК. Это можно сделать одним из двух способов:

Источник

Учимся разбираться в названиях логов

Наверняка я вам не открою Америки рассказом о том, что логи назвали логами из-за судовых журналов, куда записывали всякое интересное (и не очень), что происходило на корабле во время плавания. (Возможно, некоторые из вас не знают, но по воде ходят именно корабли, а судно — это в больнице. Хотя тут показания расходятся.)

Но не об этом мы сегодня. Сегодня мы поговорим о структуре логов в Veeam Backup & Replication, об их названиях и ожидаемом содержимом. Список будет большим, но не исчерпывающим, ибо всё описать — задача практически невозможная.

Backup Job

Итак, логи любой уважающей себя джобы лежат в отдельной папке, повторяющей её название из GUI Veeam. Кстати, если в гуе это название изменить, то папка с логами не переименуется, ибо человекочитаемые названия — тлен, а id в базе вечны.

Немного примеров других агентских логов:

Agent.VddkHelper В этом логе отмечаются API вызовы, запрещающие и разрешающие vCenter мигрировать машину во время бекапа.

Сейчас самое время запомнить простое правило: если в названии лога есть слово Source, значит, это лог агента, который что-то откуда-то читает. Если видим в названии лога слово Target, значит, это лог агента, который что-то куда-то записывает. В большинстве случаев работают они в паре и позволяют однозначно идентифицировать, где именно болит. Если сорсной агент не может прочитать данные, то не надо искать проблему на стороне репозитория.

Также есть небольшая порция специфических логов, которые появляются при работе с Hyper-V:

SnapshotCreator/SnapshotImporter Логи, связанные с VSS снапшотами. Есть смысл читать только вместе с Windows events.

HvWmiProxy- Логи отправляемых WMI запросов

Replication Job

Уверен, что вы уже поняли идею общей структуры логов. Всегда есть общий лог джобы. У него есть саб-логи тасок, где ведутся записи про каждую отдельную машину из джобы. Без тени сомнения могу сказать, что логи тасок несут в себе максимум полезной информации для решения большинства проблем. Но “большинства” не значит “всех”. Поэтому рядом с ними будут лежать логи агентов, которые делятся на сорсные и таргетные. Понимание этой незамысловатой структуры позволит вам детально разобраться с происходящим в любой вимовской джобе. Другой вопрос, что информация в логах может быть технически сложной, но про это будет в следующей статье. И не забываем, что некая часть логов оставляется агентами на бекапируемой/реплицируемой машине. И если проблема была на передающей стороне, искать её надо в логах сорсных агентов на соответствующей машине (читай прокси).

Ну а мы продолжаем.

Restore/Failover

Эти товарищи живут своей отдельной жизнью. Причём у них даже нет какого-то специального отдельного места для хранения своих логов. Просто создаётся папка с названием восстанавливаемой машины, и туда пишется вся информация. Правда, тут есть определённое неудобство, т.к. в одну папку могут попасть логи от разных ресторов, что (теоретически) приводит к путанице. Но с логикой наименования всё довольно просто:

Как видите, у каждой джобы есть какие-то свои особенности, которые накладывают свой отпечаток на содержание лог файлов. Но всегда и всюду наименование остаётся человекочитаемым и довольно прозрачно отражает суть содержимого. Поэтому с логами, лежащими в папочках, я хочу закончить и перейти к так называемым

Standalone Logs

Как нетрудно догадаться, здесь поговорим про логи, не лежащие в какой-то особенной папочке, а расположенные прямо в корне логохранилища Veeam. Сделано это в основном по причине того, что они несут в себе информацию про какие-то общие процессы, и делать под каждый такой лог свою папку — занятие странное. Хотя, положа руку на сердце, иногда всё же хочется подумать над группировкой, ибо если просто начать перечислять всё, что может лежать в папке C:\ProgramData\Veeam\Backup, то это будет больше двух страниц (проверено). Поэтому давайте самостоятельно немного сгруппируем логи по смыслу.

Вот есть целая группа логов, начинающихся с Svc. Это логи наших сервисов.

Svc.VeeamBackup.log Лог того самого Veeam Backup Service, без которого ничего работать не будет. Поэтому в него приходит довольно много информации: расписание джоб, распределение ресурсов, отслеживание внутренней коммуникации между модулями, и так далее, и тому подобное. Тот редкий случай, когда в лог что-то постоянно пишется без перерывов на обед и сон.

Svc.VeeamBES.log То же самое, но это самый важный лог уже для Veeam Enterprise Manager

Дальше всё просто и понятно.

Svc.VeeamInstaller.log Фиксирует все действия Veeam Installer Service (aka Veeam Deployment service)

Svc.VeeamCatalog.log Содержит в себе записи о работе сервиса индексации гостей.

Svc.VeeamInstallerDll.log Поскольку Installer Service также проводит некоторые операции с файловой системой (проверка свободного места, поиск файлов, создание VBM и т.д.), было решено записывать эти события в отдельный лог. К слову, это единственный сервис, который приходится разворачивать через админскую шару и SCM. Все остальные устанавливаются уже с его помощью.

Svc.VeeamHvIntegration В этом логе фиксируется информация об операциях создания VSS снапшотов и взаимодействия с нашим проприетарным драйвером. Часть про VSS снапшоты одинакова с VeeamVssSupport.log файлом на гостевой машине. А поскольку у Hyper-V Integration сервисы работают в пассивном режиме, от них остаются только ответы на запросы.

Svc.VeeamWANSvc.log Логи WAN Accelerator сервиса. Лог пишется на обеих сторонах канала связи.

Svc.VeeamTransport.log Фиксирует работу Veeam Backup Proxy сервиса.

Svc.VeeamTape.log Здесь находится всё что связано с Remote Tape Server.

Svc.VeeamRestAPI.log Лог RESTfullAPI реквестов.

Svc.VeeamNFS.log. Та самая магия, которая позволяет ESXi хостам монтировать виртуалки прямо из бекапов. Используется для FLR, IR, SureBackups и прочих Other-OS File Recovery.

Есть сервис — должен быть отдельный лог. Или даже несколько, если так удобней.

Так же имеется плеяда агентских логов.

Agent.DynGroupMount Агент отвечающий за монтирование динамических дисков.во время Windows FLR, например.

Agent.NfcCommander.Client/Server В этом логе фиксируются операции c VMFS вольюмами: чтение конфигурации, удаление/создание директорий и файлов. Используется при IR, Failover и Other OS FLR.

VeeamAgent.FileOperation.Client/Server.log В том или ином виде есть во многих подпапках. Хранит информацию о таких операциях как File Copy Job, экспорт логов и ещё нескольких.

А вот логи инструментов работающих с инфраструктурой убрали в отдельную папку \Utils\

Util.CatCleanup Лог, ведущийся тулой Catalog Synchronization. Проверяет соответствие информации в VBRCatalog и реальных бекапов.

Util.VeeamBackupConfiguration.Restore Логи восстановления базы данных самого VBR.

Util.VmBackupValidate Этот лог создаётся, если руками запустить Veeam.Backup.Validator.exe. Проверяет целостность блоков данных на уровне хранилища.

Util.DatabaseResynchronizer Это уже не отдельный лог, а полноценная папка с логами процесса синхронизации базы данных и фактического содержимого бекапных репозиториев.

Util.VolumesHostDiscover Другая полноценная папка, где хранятся логи так называемых Volumes Discovery тасков. Этот процесс проверяет диски, подключенные к прокси серверам, на предмет возможности их использования в качестве точки монтирования при ресторе элементов приложений.

И, конечно же, есть гора логов-одиночек.

Job.DatabaseMaintenance Раз в неделю Veeam проводит обслуживание своей базы: дефрагментирует индексы, удаляет ненужные данные, и так далее. Завершается это всё перезапуском основного сервиса.

VeeamBackupMksConsole Фиксирует информацию про открытие окна консоли машин, запущенных в рамках SureBackup.

RTS.ResourcesUsage.log Здесь хранятся записи планировщика ресурсов всех компонентов Veeam.

VeeamShell Всё, что происходит в GUI, оставляет свой отпечаток здесь

PowerShellInvokerWrapper Лог связи между Veeam сервером и SCVMM

VeeamBackupManager Логи менеджера, запускающего джобы и таски. Практически вся информация записывается в соответствующие логи, так что здесь мало чего остаётся. Однако, где-то это надо фиксировать.

Логи по папочкам

И есть ещё логи, которые напрямую к бекапам не относятся, однако свою отдельную папочку заслужили по разным причинам.

%Something% Explorer Логи от одного из AIR (Application-Item restore) визардов. Active Directory, SQL, Oracle и так далее.

ResourceScan, Чтобы поддерживать в актуальном виде информацию о состоянии бекапной инфраструктуры, Veeam с определённой периодичностью сканирует всё, что к нему было подключено.

BackupConfigurationJob Логи джобы, бекапящей конфиг самого Veeam сервера (по сути, делающей дамп базы).

Console Информация о запусках консоли от разных пользователей. Информация внутри поделена на разные логины, однако учтите, что лог хранится на той машине откуда, запускалась консоль, а не на самом VBR сервере.

EvacuateBackupsJob Появляется при эвакуации бекапов с SOBR репозитория.

Exportlogs Логи визарда, собирающего логи для сапорта. Да, это логи на логи =)

Filefromtaperestore Удивительно, но тут живут логи восстановления файлов с лент.

FLRSessions Практически вся информация про FLR и Other OS ресторы.

Import_job Логи процесса импорта бекапов

NfsDatastore Всё, что связано с работой vPower NFS, фиксируется здесь

Satellites Своих спутников на орбите, к сожалению, у нас пока нет, однако есть несколько вспомогательных процессов, разгружающих GUI. Следы этих процессов будут в этой папке.

На этом пока всё. Повторюсь: это даже приблизительно не полный список логов и папок с ними. Как вы могли убедиться, логи пишутся буквально на каждый чих. Такова уж специфика софта, обеспечивающего защиту ваших данных. А поскольку функционал Veeam Backup&Replication невероятно огромен, то и логи генерируются в олимпийских количествах. И помимо таких очевидных вещей, как простой запуск бекапа/реплики, есть ещё фоновые задачи, такие как Health Check, например. И они тоже генерируют свои логи, дабы в случае аварии всегда можно было максимально подробно восстановить картину мира и понять, что мешает успешной работе.

Поэтому основная цель, которую я перед собой ставил — это показать на примерах, как происходит именование файлов и как выглядят логи самых часто используемых функций. Надеюсь, всё получилось, и если нелёгкая заставит вас открыть %ProgramData%/Veeam/Backups, то вы сможете сориентироваться в этом море названий. А в следующей статье мы уже наконец-то перейдём к азам чтения самих логов. Поговорим про общие правила, которых надо придерживаться, и научимся вычленять базовую информацию.

Источник

Что такое лог (log) программы.

Решая различные компьютерные задачи, можно не раз столкнуться с таким понятием как лог (с англ. log). Лог какой-то программы. Давайте попробуем разобраться что это такое и для чего это нужно.

Log (с англ. журнал). У большинства программ, которые установлены на вашем компьютере, есть этот самый журнал.

Т.е. это такой же обычный файл, который мы с вами можем создать на компьютере. Таким же образом программа работая на компьютере, может создать этот файл и вносить туда программным образом какие-то текстовые пометки.

Зачем же программе вести какие-то записи, какой-то журнал?

Дело в том, что если мы с вами будем следить за человеком, который работает на компьютере, мы можем сказать, что этот человек делал в конкретный момент времени, какие программы он запускал, какие ошибки он совершал при работе на компьютере и.т.д.

Но, если мы говорим о компьютерной программе, здесь все не так ясно. Все действия, которые производит программа, они скрыты от взгляда обычного пользователя. Они обычно происходят с такой большой скоростью событий, что человеческий глаз просто не успеет за все этим уследить.

Для того, чтобы отслеживать состояние какой-то программы. Что делала программа в какой-то конкретный момент времени, какие при этом возникали ошибки, кто с этой программой взаимодействовал и др. вопросы. Все события, которые происходили с этой программой, эта программа может записывать в специальный журнал, так называемый лог-файл.

В каждой записи содержится информация о том, что происходило с программой и когда это происходило.

Давайте подведем итог, что такое лог и зачем он нужен. Это текстовый файл, в который программа записывает какие-то события, которые с ней происходят. Благодаря этим событиям мы можем получить какую-то дополнительную информацию, что происходило с этой программой в какой-то определенный момент времени, получить отладочную информацию, чтобы легче устранить какую-то ошибку.

Надеюсь, что стало понятнее что такое лог-файл и зачем он нужен и вы теперь будете использовать этот журнал в своей работе.

Источник

Где посмотреть и как читать логи с ошибками сервера

Блоги, форумы, посадочные страницы и другие интернет-ресурсы представляют собой совокупность графического, текстового, аудио- и видео-контента, размещенного на веб-страницах в виде кода. Чтобы обеспечить к ним доступ пользователей через интернет, файлы размещают на серверах. Это аппаратное обеспечение (персональный компьютер или рабочая станция), на жестком диске которого и хранится код. Ключевые функции выполняются без участия человека, что актуально для всех типов оборудования, включая виртуальный выделенный сервер. Но это не означает, что контроль не осуществляется. Большинство событий, которые происходят при участии оборудования, пользователей и софта, включая ошибки, логи сервера фиксируют и сохраняют. Из этой статьи вы узнаете, что они собой представляют, зачем нужны, и как их читать.

Что такое логи

Это текстовые файлы, которые хранятся на жестком диске сервера. Создаются и заполняются в автоматическом режиме, в хронологическом порядке. В них записываются:

Посмотреть логи сервера может каждый, у кого есть к ним доступ, но непосвященному обывателю этот набор символов может показаться бессмысленным. Интерпретировать записи и получить пользу после прочтения проще профессионалу.

Классификация логов

Для каждой разновидности софта предусмотрены соответствующие файлы. Все логи сервера могут храниться на одном диске или даже на отдельном сервере. Существует довольно много разновидностей логов, вот наиболее распространенные:

Записи в системные журналы выполняет установленный софт.

Зачем нужны логи

Анализ логов сервера — неотъемлемая часть работы системного администратора или веб-разработчика. Обрабатывая их, специалисты получают массу полезных сведений. Используются в следующих целях:

После изучения информации можно получить точную статистику в виде сводных цифр, информацию о юзерах, выявить поведенческие закономерности пользовательских групп.

Читайте также

Где посмотреть логи

Расположение определяется хостинг-провайдером или настройками установленного софта. На виртуальном хостинге доступ к лог-файлам предоставляется из панели управления хостингом. Если администратор не открыл его для владельца сайта, получить информацию не получится. Но большинство провайдеров разрешают свободно пользоваться журналами и проводить анализ логов сервера. Независимо от разновидности сервера лог-файлы хранятся в текстовом документе. По умолчанию он называется access.log, но настройки позволяют переименовать файл. Это актуально для Nginx, Apache, прокси-разновидностей squid, других типов. Для просмотра их надо скачать и открыть в текстовом редакторе. В качестве альтернативы можно использовать Grep и схожие утилиты. Они позволяют открыть и отфильтровать логи прямо на сервере.

Как читать логи. Пример

Существует довольно много форматов записи, combined — один из наиболее распространенных. В нем строчка кода может выглядеть так:

Директивы имеют следующее значение:

Еще один пример чтения логов можно посмотреть в статье «Как читать логи сервера».

Опытные веб-мастера для сбора и чтения лог-файлов используют программы-анализаторы. Они позволяют читать логи сервера без значительных временных затрат. Вот некоторые из наиболее востребованных:

Логи сервера с ошибками error.log

Это журнал с информацией об ошибках на сайте. В нем можно посмотреть, какие страницы отсутствуют, откуда пришел пользователь с конкретным запросом, имеются ли «битые» ссылки, другие недочеты, включая те, которые не удалось классифицировать. Используется для выявления багов и погрешностей в коде.

Источник

Как разобраться с логированием: гайд для начинающих

Этот материал мы ориентировали на тех, кто в первый раз сталкивается с логированием серверных служб и web-серверов. Познакомим с уровнями логирования, расскажем об основных типах логов и перечислим инструменты для работы с ними.

Зачем оно вообще нужно, это логирование?

На анализе логов базируется работа большинства ИТ-специалистов. Администраторы ищут в файлах логирования причины сбоя сервиса. Разработчики опираются на логи, чтобы локализовать и устранить ошибки приложения или веб-сайта. Служба безопасности по логам, как по физическим уликам, определяет вид взлома, оценивает нанесенный ущерб и даже может идентифицировать взломщика. Вот почему логирование мы рекомендуем отладить в первую очередь: в любой непонятной ситуации ответ на вопрос вы будете искать в логах!

Уровни логирования

В идеале логи пишутся во время работы всех IT-систем, однако если писать все подряд и «складывать в кучу», полезная информация превратится в хаос. Чтобы упростить поиск и чтение логов, их делят на уровни. Основных четыре:

Debug — запись масштабных переходов состояний, например, обращение к базе данных, старт/пауза сервиса, успешная обработка записи и пр.

Warning — нештатная ситуация, потенциальная проблема, может быть странный формат запроса или некорректный параметр вызова.

Error — типичная ошибка.

Fatal — тотальный сбой работоспособности, когда нет доступа к базе данных или сети, сервису не хватает места на жестком диске.

Дополнительно файл логирования может расширяться записями еще двух уровней:

Trace — пошаговые записи процесса. Полезен, когда сложно локализовать ошибку.

Info — общая информация о работе службы или сервиса.

Работа с уровнями логирования регламентируется методическими документами и внутренними правилами организации. В них может определяться соответствие источника сообщения уровню логирования, значимость, порядок обработки каждого уровня и другие параметры.

Типы логов

Для удобства обработки логов их делят на типы:

системные, связанные с системными событиями,

серверные, отвечающие за процесс обращения к серверу,

почтовые, работающие с отправлениями,

логи баз данных, которые отражают процессы обращения к базам данных,

авторизационные и аутентификационные, которые отвечают за процесс входа, выхода из системы, восстановление доступа и пр.

У каждого типа логов свой журнал записи. Для проверки логов авторизации нужно идти в журнал доступов, чтобы проверить загрузку системы — в журнал dmesg, за данными о запросах пользователей — в access_log. Когда одни логи пишутся отдельно от других, проще диагностировать ситуацию и найти источник проблемы.

Логи в access_log

Инструменты для работы с логами

Сбор, хранение и анализ логов вручную хороши, когда у вас один сервер. Когда серверный парк разрастается, а приложений и сервисов становится больше десяти, работу с логами целесообразно автоматизировать и использовать специальные системы логирования, например, Graylog, ELK, Loggy или Splunk. Некоторые из них позволяют организовать полномасштабный мониторинг, настроить алерт раннего обнаружения конкретной проблемы или установить пороговые значения показателей, коррелирующих с угрозами информационной безопасности.

Логи сетевого, инженерного оборудования, баз данных и приложений мы храним в облачном хранилище. И вам советуем. Даже когда у вас полно места на жестких дисках и стоит мощная защита на все случаи жизни. Оборудование рано или поздно, а чаще неожиданно, выходит из строя, а злоумышленники давно умеют чистить файлы логирования, так что логи в облаке — это возможность восстановить события и расследовать инцидент даже при полном отказе системы.

Хранение логов в облаке

Логирование кажется второстепенным процессом, который занимает время, но не дает видимых результатов. Однако это только кажется и только до тех пор, пока не появится реальная проблема, с которой можно разобраться только по логам. И только если они записаны, распределены по уровням, собираются и доступны для анализа.

Источник

Логирование. NLog Platform. Зачем нужны логи в приложении

Здесь мы затронем тему логирования в нашем приложении, что такое логи, и как правильно вести логи, насколько это необходимо и полезно. Рассмотрим систему логирования NLog Platform.

Ведение логов помогает разработчику в процессе создания и последующего сопровождения приложения, при поиске ошибок в коде и в разрешении непонятных ситуаций, когда наше приложение в момент работы ведет себя странным образом, и нам нужно найти причину такого поведения.

Любой разработчик сталкивается с подобными ситуациями, когда какой-то компонент приложения отрабатывает странным образом, выдает не тот результат или вообще перестает работать. Использование логов поможет нам в подобных ситуациях. Время поиска проблемных мест в нашем коде сократится в разы, и мы быстрее сможем решить ту или иную проблему.

Вообще, на сегодняшний момент ни одно более или менее серьезное приложение не обходится без написания логов.

Под таким журналом можно понимать и записи в обычный текстовый файл, и записи в базу данных, и записи на удаленный веб-сервис, и даже email-письма на определенный адрес о тех или иных состояниях нашего приложения.

Какие записи делать в этот журнал, то есть, какую конкретно информацию записывать, определяет сам разработчик. Это могут быть сведения о том, что все работает в штатном режиме, то есть просто ежедневный мониторинг нашего приложения, или что произошла какая-то ошибка, на которую нужно максимально срочно отреагировать и устранить, и так далее.

Всего существует шесть уровней логирования, каждый из которых предназначен для сообщений того или иного типа, той или иной важности:

Trace – максимально детальная информация о том, что происходит с целевым участком кода, по шагам. Например: Попытка открыть подключение к БД, успешно\неуспешно. Сколько времени заняла эта операция. Сколько времени выполнялась выборка из БД, успешно\неуспешно. Сколько записей извлечено. Какая была нагрузка на систему, сколько использовано памяти. Сколько записей прошло нужную фильтрацию. Сколько записей оказалось в результирующей выборке, куда эти записи отправились дальше. Проверка нужных значений в каждой записи.

Debug – это информация для отладки. Логирование крупных операций, менее детально, чем в Trace. Здесь мы не так подробно описываем весь процесс операции, но, тем не менее, заносим в журнал основные операции. Например: Совершено обращение к БД. Из базы выбрано N записей. Записи успешно обработаны и отправлены клиенту.

Info – это более общие информационные сообщения о текущей работе приложения, что происходит с системой в процессе ее использования. Например: Была выгрузка студентов в Excel-файл. На сайте зарегистрирован новый студент. Студент добавил новый отчет. Студент перемещен в другую группу.

Warn – сообщения о странной или подозрительной работе приложения. Это еще не серьезная ошибка, но следует обратить внимание на такое поведение системы. Например: Добавлен студент с возрастом 2 года. Студент получил отрицательный балл. Преподаватель завершил курс, в котором училось 0 студентов. В группе находится больше студентов, чем максимально возможно.

Error – сообщения об ошибках в приложении. Подобные сообщения – это уже большая проблема, которую нужно решить для дальнейшей правильной работы системы. Например: Ошибка сохранения нового студента в БД. Невозможно загрузить студентов в данной группе. Ошибка при входе в личный кабинет студента.

Fatal – сообщения об очень серьезных ошибках в системе. Чаще всего это связано с работоспособностью всего приложения или его окружения на сервере. На такие сообщения следует реагировать МАКСИМАЛЬНО оперативно. Например: Приложение постоянно перезагружается из-за нехватки памяти или места на жестком диске. Приложение завершило работу по неизвестной причине. Нет доступа к базе данных. Нет доступа к сети. Заблокирован какой-то порт.

То есть, прежде чем отправить какое-то сообщение в лог, нам нужно отнести его к той или иной группе.

Например, мы написали новый функционал и хотим его протестировать, как правильно и быстро он работает. Для этого мы будем использовать тип сообщений Trace, то есть все наши сообщения в логе будут помечены как Trace.

Подобным образом мы можем описать, как работает наше приложение в целом, сообщения будут с пометкой Info.

Если же в опасных участках кода мы генерируем исключение, то теперь мы также добавим запись в лог с пометкой Error.

К какой группе отнести то или иное сообщение решает сам разработчик. К данному вопросу следует подойти с максимальной серьезностью. Очевидно, что ошибки не следует помечать как Info, не следует игнорировать ошибки и просто не записывать их в лог. От правильно настроенной системы логирования будет зависеть простота сопровождения всей системы, оперативность реагирования на ошибки и время, затраченное на устранение проблемы.

Иногда разработчики ленятся писать логи, не хотят тратить на это время. В дальнейшем оказывается, что время, затраченное на поиск и исправление ошибок, в разы больше времени, которое потребовалось бы на создание системы логов.

Естественно, многое зависит от сложности проекта. Если вы создаете простейший трехстраничный сайт-визитку или консольное приложение для собственных нужд у себя на локальном компьютере, то написание сложной системы логирования может быть дольше, чем создание самого проекта. В таком случае в логи можно записывать только сообщения об ошибках или почему упал сайт. Но если вы работаете над сложным проектом в команде с другими разработчиками, то грамотное ведение логов просто обязательно.

Для того, чтобы начать логирование, мы подключим в наш проект платформу NLog. Это можно легко сделать посредством менеджера NuGet (прямо из Visual Studio).

Обратите внимание на конфигурационный файл NLog.config. В этом файле находятся настройки логгера (куда будут выводиться логи, формат записи логов и т.д.). Давайте настроим файл следующим образом:

Далее уже в коде объявим новый логгер (здесь код проекта приводится в сокращенном виде, исходный код всего проекта можно скачать в конце статьи):

Чаще всего следует объявлять один статичный логгер в пределах всего класса. Здесь мы посредством класса-менеджера LogManager объявили новый логгер, с которым будем работать.

Начнем логирование с уровня Trace. В методе, где мы выбираем студента по его идентификатору, давайте максимально подробно опишем как это происходит:

Теперь давайте добавим несколько сообщений уровня Debug. Как мы помним, это тоже отладочная информация, но менее детальная. Данный подход мы используем в другом методе, для наглядности:

Идем далее. На уровне Info мы описываем регулярные операции в нашем приложении, то есть поднимаемся еще на уровень выше. Предположим, что мы работаем над ASP.NET MVC приложением, и у нас есть действие в контроллере, которое обращается к ранее описанному методу GetStudentById():

Теперь добавим в логи сообщения уровня Warn. Как мы помним, на этом уровне логирования мы описываем все потенциально опасные ситуации, странное и нелогичное поведение компонентов. Будем заносить в лог запись, если студенту меньше 15 лет:

Далее обработаем ошибку в нашем коде и запишем в лог сообщение уровня Error:

Теперь определим, что же нам записать на уровне Fatal. В нашем простейшем примере просто смоделируем подобную ситуацию:

Мы рассмотрели все шесть уровней логирования и описали процесс работы нашего приложения максимально подробно. Теперь мы можем сразу проанализировать работу сайта, просто изучив логи, и не заглядывать в исходный код.

Подобным образом происходит логирование. В нашем простейшем примере, где мы моделируем работу со студентами, все предельно ясно и прозрачно даже без логов. Но в сложных проектах ведение логов является неотъемлемой частью разработки.

Конечно, это далеко не полные возможности настройки платформы NLog. В конфигурационном файле можно настроить запись логов в другие места, например, в базу данных, на консоль, в оперативную память, отправлять как емаил-сообщение, отправлять сообщения по сети и так далее. Также можно настроить фильтрацию сообщений, более сложный шаблон сообщений. Если вас не устраивает стандартный функционал логгера, то можно написать свое собственное расширение и подключить.

На этом здесь все, давайте подведем небольшой итог. Мы изучили тему логирования в приложении. Посмотрели как правильно логировать те или иные участки кода, а также познакомились с одной из самых популярных платформ логирования – это NLog Platform, также рассмотрели ее возможности и как можно настроить генерацию логов на этой платформе.

Источник

Что такое логи впн и чем они опасны

Технический прогресс не стоит на месте и уже достиг того уровня развития, когда устройства способны следить за действиями пользователей в Интернете и не только. При этом логи, которые ведутся устройствами, могут попасть в руки злоумышленников или правоохранительных органов. Как вы понимаете, в такой ситуации ни о какой безопасности не может быть и речи.

В связи с этим особенно остро встает вопрос обеспечения анонимности пользователей в Интернете.

Что такое логи?

Логи, они же лог-файлы или журнал vpn – это файлы, в которые записывается информация о действиях пользователей или программ. Также в эти файлы может записываться разного рода информация о пользователе, в том числе информация, позволяющая однозначно идентифицировать пользователя.

VPN без логов решит проблему анонимности.

Что такое логи VPN сервера

Логи VPN сервера – журнал, в который сохраняются данные о действиях пользователя в Интернете. В него может записываться реальный IP адрес, другая информация о пользователе и параметрах его устройства. Также записывается история подключений и действий в сети.

Данная информация собирается с целью обеспечения безопасности в сети и не только. К сожалению, содержимое журналов может попасть к злоумышленнику, если вы выбрали ненадежный VPN. При утечке данных, кроме реальных IP адресов для идентификации пользователя VPN могут использоваться ID в системе, параметры устройства и другие.

Как проверить vpn и определить, что поставщик ведет логи?

Чтобы определить, ведет сервис VPN ли логи, спросите его об этом. При этом не стоит рассчитывать на честный ответ.

Также вы можете выполнить действия, которые запрещены условиями сервиса. Если сервис заблокирует аккаунт, значит логи все-таки ведутся. Однако, определять анонимность поставщика VPN таким образом не рекомендуется. Если поставщик ведет логи, он обязан передавать сведения правоохранительным органам.

Для проверки анонимности VPN сервиса без юридических последствий предлагаем воспользоваться нашим чек-листом:

Спросите специалистов технической поддержки, ведутся ли поставщиком логи. Если логи ведутся, необходимо уточнить какие именно данные о пользователях сохраняются на сервере. Если хранятся данные непосредственно относящиеся к пользователю и его устройству, данный сервис не гарантирует анонимность.

Прописано ли в документах поставщика право сохранять информацию о пользователях? Изучите «Условия использования» или подобный документ поставщика VPN. Вас должен особенно заинтересовать текст, который представлен мелким шрифтом. Увидели слова типа «Сервис оставляет за собой право сохранять информацию в целях обеспечения безопасности»? Что бы там не писали в рекламных слоганах на главной странице, этот сервис не является анонимным.

Какие отзывы пользователей о сервисе? Изучите отзывы о VPN сервисе в интернете. Не те, которые приведены на сайте этого поставщика, а те, которые размещают на сайте отзывов, на тематических форумах и т.д.

Как работает анонимный VPN сервис

Любой интернет-cервис обязан реагировать на абузы – жалобы владельцу IP на запрещенные действия в интернете.

Если сервис ведет логи и может определить конкретного пользователя, с устройства которого выполняются действия, указанные в абузе, его аккаунт блокируется.

При работе анонимного VPN на серверах отсутствуют сведения о его пользователях, а также об устройствах, с которых осуществляется доступ к VPN. Безо всяких оговорок. Определить конкретного пользователя нет возможности, чтобы остановить запрещенные действия, доступ к сайту блокируется для всех пользователей VPN.

Можно ли использовать бесплатный vpn?

Бесплатные VPN сервисы чаще всего представляют собой лишь видимость защиты. В них может не быть важных функций типа шифрования. При использовании таких сервисов пользователи нередко отмечают снижение скорости, а также наличие назойливой рекламы.

Чтобы использовать платный анонимный VPN достаточно несколько долларов в месяц. При этом у поставщиков нередко действует система скидок, например, при оплате годового доступа.

Как найти проверенный VPN без логов

Подробнее о выборе надежного VPN сервиса вы можете прочитать в нашей статье.

Политика нашего сервиса гарантирует анонимность пользователей. Мы не ведем логов. Наш VPN тщательно скроет и очистит все следы вашего присутствия в Интернете. В результате никто не сможет связать вашу активность в интернете с вашим реальным адресом.

Источник

Логирование как инструмент повышения стабильности веб-приложения

Каждый проект так или иначе имеет жизненные циклы: планирование, разработка MVP, тестирование, доработка функциональности и поддержка. Скорость роста проектов может отличаться, но при этом желание не сбавлять обороты и двигаться только вперёд у всех одинаковые. Перед нами встаёт вопрос: как при работе над крупным проектом минимизировать время на выявление, отладку и устранение ошибок и при этом не потерять в качество?

Существует много различных инструментов для повышения стабильности проекта:

В данной статье я хочу поговорить об одном из таких инструментов — логировании.

Логи — это файлы, содержащие системную информацию о работе сервера или любой другой программы, в которые вносятся определённые действия пользователя или программы.

Логи полезны для отладки различных частей приложения, а также для сбора и анализа информации о работе системы с целью выявления ошибок. Всё это необходимо для контроля работы приложения, так как даже после релиза могут встретиться ошибки, а пользователи не всегда сообщают о багах в техподдержку. Чем больше процессов у вас автоматизировано, тем быстрее будет идти разработка.

Допустим, есть клиентское приложение, балансировщик в лице Nginx, серверное приложение и база данных.

В данном примере не важны язык/фреймворк бэкенда, фронтенда или тип базы данных, а вот про веб-сервер Nginx давайте поговорим. В данный момент Nginx популярнее остальных решений для высоконагруженных сайтов. Среди известных проектов, использующих Nginx: Рамблер, Яндекс, ВКонтакте, Facebook, Netflix, Instagram, Mail.ru и многие другие. Nginx записывает логи по умолчанию, без каких-либо дополнительных настроек.

Логи доступны 2 типов:

Клиент отправляет запрос на сервер, и в данной ситуации Nginx будет записывать все входящие запросы. Если возникнут ошибки при обработке запросов, сервером будет записана ошибка.

2020/04/10 13:20:49 [error] 4891#4891: *25197 connect() failed (111: Connection refused) while connecting to upstream, client: 5.139.64.242, server: app.dunice-testing.com, request: «GET /api/v1/users/levels HTTP/2.0», upstream: «http://127.0.0.1:5000/api/v1/users/levels», host: «app.dunice-testing.com»

Всё, что мы смогли бы узнать в случае возникновения ошибки, — это лишь факт наличия таковой, не более. Это полезная информация, но мы пойдём дальше. В данной ситуации помог Nginx и его настройки по умолчанию. Но что же нужно сделать, чтобы решить проблему раз и навсегда? Необходимо настроить логирование на сервере, так как он является общей точкой для всех клиентов и имеет доступ к базе данных.

Первым делом каждый запрос должен получать свой уникальный идентификатор, что поможет отличить его от других запросов. Для этого используем UUID/v4. На случай возникновения ошибки, каждый обработчик запроса на сервере должен иметь обёртку, которая отловит эти самые ошибки. В этой ситуации может помочь конструкция try/catch, реализация которой есть в большинстве языков.

В конце каждого запроса должен сохраняться лог об успешной обработке запроса или, если произошла ошибка, сервер должен обработать её и записать следующие данные: ID запроса, все заголовки, тело запроса, параметры запроса, отметку времени и информацию об ошибке (имя, сообщение, трассировка стека).

Собранная информация даст не только понимание, где произошла ошибка, но и возможную причину её возникновения. Обычно для решения ошибки информации из лога достаточно, но в некоторых случаях может быть полезен контекст запроса. Для этого необходимо при старте запроса не только генерировать ID запроса, но и сгенерировать контекст, в который мы будем записывать всю информацию по работе сервера, начиная от результата вызова функции и заканчивая результатом запроса к базе данных. Такая реализация даст не только входные данные, но и промежуточные результаты работы сервера, что позволит понять причину появления ошибки.

При микросервисном подходе система не ограничивается одним сервером, и при запросе от клиента происходит взаимодействие нескольких серверов внутри системы. Наша реализация логирования на сервере позволит выявить дефект в работе конкретного ресурса, но не позволит понять, почему запрос вернулся с ошибкой. В данной ситуации поможет трассировка запросов.

Трассировка — процесс пошагового выполнения программы. В режиме трассировки программист видит последовательность выполнения команд и значения переменных на каждом шаге выполнения программы.

В нашем случае требуется передавать метаинформацию о запросе при взаимодействии серверов и записывать логи в единое хранилище (такими могут быть ClickHouse, Apache Cassandra или MongoDB). Такой подход позволит привязать различные контексты серверов к уникальному идентификатору запроса, а отметки времени — понять последовательность и последнюю выполненную операцию. После этого команда разработки сможет приступить к устранению.

В некоторых случаях, которые встречаются крайне редко, к ошибке приводят неочевидные факторы: компилятор, ядро операционной системы, конфигурации сервера, юзабилити, сеть. В таких случаях при возникновении ошибки потребуется дополнительно сохранять переменные окружения, слепок оперативной памяти и дамп базы. Такие случаи настолько редки, что не стоит беспочвенно акцентировать на них внимание.

С сервером разобрались, что же делать, если у нас сбои даёт клиент и запросы просто не приходят? В такой ситуации нам помогут логи на стороне клиента. Все обработчики должны отправлять информацию на сервер с пометкой, что ошибка с клиента, а также общие сведения: версия и тип браузера, тип устройства и версия операционной системы. Данная информация позволит понять, какой участок кода дал сбой и в каком окружении пользователь взаимодействовал с информацией.

Также есть возможность отправлять уведомления на почту разработчикам, если произошли ошибки, что позволит оперативно узнавать о сбоях в системе. Такие подходы активно используются в системах мониторинга и аналитики логов.

Способы, которые мы рассмотрели в статье, помогут следить за качеством продукта и минимизируют затраты на исправление недочётов в системе.

Источник

Python: Логируем как профессионалы

Часто вижу, что помимо обработки исключений, люди мучаются кое с чем еще, а именно с логированием.

Большинство людей не знают, что писать в логи, поэтому решают логировать все, что угодно, думая, что все подряд – это в любом случае лучше, чем ничего, и, в конечном итоге, просто создают шум. А шум – это информация, которая никак не помогает вашей команде понять, в чем дело и как решить проблему.

Более того, я не думаю, что эти люди могут уверенно пользоваться уровнями логирования, поэтому используют по умолчанию logger.info везде (если не пишут print ).

Наконец, люди, похоже, не знают, как сконфигурировать логирование в Python, понятия не имеют, что такое обработчики, фильтры, методы форматирования (форматтеры) и т.д.

Цель этой статьи – разъяснить, что такое логирование и как вы должны его реализовывать. Я постараюсь привести содержательные примеры и обеспечить вас гибкими эмпирическими приемами, которые следует использовать при логировании в любом приложении, которое вы когда-либо будете создавать.

Введение

Примеры облегчают визуальное восприятие, поэтому мы будем рассматривать следующую систему:

Пользователи могут подключать несколько интеграций к ресурсам (например, GitHub, Slack, AWS и т.д.)

Ресурсы уникальны в зависимости от интеграции (например, репозитории списков с GitHub, диалоги из Slack, экземпляры списков EC2 из AWS и т.д.)

Каждая интеграция уникальна, имеет свой набор сложностей, конечных точек, шагов и т.д.

Каждая интеграция может привести к различным ошибкам, которые могут возникнуть в любое время (например, неверная аутентификация, ресурс не существует и т.д.)

Я не буду сосредотачиваться на проблемах поддержки таких интеграций, просто пронаблюдаем за тем, как это работает.

Природа логирования: хорошее логирование имеет значение

Для начала давайте проанализируем характеристики логов.

Логи должны быть:

«Наглядными» мы их называем потому, что они предоставляют вам какую-то информацию, «контекстными», потому что они дают вам общее представление о том, как обстоят дела на данный момент времени. И наконец, «реактивными» они являются потому, что они позволяют вам предпринимать действия только после того, как что-то произошло (даже если ваши логи отправляются/получаются в режиме реального времени, на самом деле вы не можете изменить то, что произошло только что).

Если вы не будете учитывать природу логов, то будете производить только шум, что снизит вашу производительность.

Дальше я приведу несколько примеров, основанных на системе, которую мы определили выше:

Если вы зададите описание, к примеру «operation connect failed», но не добавите контекст, трудно будет понять, какая из интеграций не отработала, кто пострадал, на каком этапе подключения произошел сбой, поэтому и среагировать вы не можете. В конечном итоге вы будете копаться в тонне логов без малейшего представления о том, где может быть проблема.

О, а еще не стоит недооценивать способность разработчика испортить описание. Сделать это легко, просто отправив поверхностные сообщения без какого-либо контекста, например «An error happened» или «An unexpected exception was raised». Если я прочту такое, то даже не пойму, на что повлияла ошибка, потому что не буду знать, ЧТО конкретно произошло. Так что да, можно сломать даже основной смысл логов.

Логи – это конфиденциальная информация из вашего программного обеспечения, нужная чтобы вы оставались в курсе происходящего и могли реагировать на ситуации. Любые логи, которые не дают вам такой информации – это шум.

Когда нужно логировать?

Чтобы логи оставались реактивными, вам нужно логировать «события». Сделайте их такими же понятными и удобными для чтения, как эта статья. Возможно, вы не прочитали каждую строку, которую я написал выше, но вы все равно можете продолжить дальше, пропустить ненужные разделы и сосредоточиться на том, что привлекло ваше внимание. Логи должны быть такими же.

Есть эмпирическое правило построение логов:

В начале соответствующих операций или потоков (например, при подключении к сторонним сервисам и т.д.);

При любом достигнутом прогрессе (например, успешная аутентификация, получен валидный код ответа и т.д.);

При завершении операции (успешном или неудачном).

Логи должны рассказывать вам историю, у каждой истории есть начало, середина и конец.

Будьте осторожны с релевантностью, добавлять логи проще, чем удалять их, ведь все, что нерелевантно – шум.

Что логировать?

Чтобы логи были наглядными и контекстными, нужно предоставлять правильный набор информации, и я не могу сказать, какая информация будет являться таковой, не зная вашего случая. Давайте вместо этого воспользуемся нашим примером.

Рассмотрим интеграцию с AWS в качестве примера. Было бы круто иметь следующие сообщения:

Хороший пример логов

Сообщение

Понимание картины

Контекст

Connecting to AWS

Началась операция с AWS

Атрибуты лога должны позволить мне выяснить, кто его вызвал

Retrieved instances from all regions

Был достигнут существенный прогресс

Connection to AWS has been successful

Операция с AWS завершилась

Атрибуты лога должны позволить мне найти сущности, на которые операция произвела положительный эффект

Пример логов об ошибках

Допустим, что извлечь экземпляры из региона af-south-1 не удалось из-за какой-то внезапной ошибки в этом регионе.

Сообщение

Понимание картины

Контекст

Connecting to AWS

Началась операция с AWS

Атрибуты лога должны позволить мне выяснить, кто его вызвал

Failed to retrieve instances from regions af-south-1 when connecting to AWS for user X

Операция AWS не завершена, произошел сбой в регионе af-south-1, пострадал пользователь X

Я должен иметь возможность увидеть трассировку стека ошибки, чтобы понять, почему извлечение не удалось

В обоих случаях, я могу отследить, когда произошло какое-то событие (в логах есть отметки о времени), что именно произошло и кто от этого пострадал.

Я решил не указывать пользователя при начале и успешном завершении операции, потому что это не имеет значения (ведь это шум), поскольку:

Если я знаю, что что-то запустилось, но не знаю результата выполнения, то что я могу сделать?

Если все хорошо, то зачем беспокоиться?

Добавление таких данных делает логи шумными, потому что на них невозможно реагировать, делать-то с этим ничего не надо! Но я все еще должен быть в состоянии собрать детальную информацию из атрибутов (кто, когда, почему и т.д.). Если вы хотите что-то измерить, вам следует воспользоваться метриками, а не логами.

С другой стороны, логи об ошибках кажутся более подробными, и так и должно быть! Чтение таких логов дает достаточно уверенности, чтобы немедленно перейти к действиям:

Свяжитесь с пользователем Х и сообщите ему, что вам известно о проблеме в этом регионе.

Ключевой момент следующий: вы можете отреагировать сразу и для этого вам не требуется более глубокого изучения ситуации. Вы знаете все, что вам нужно, и можете немедленно принять меры для уменьшения ущерба. Разработчикам, возможно, потребуется углубиться в трассировку стека, чтобы собрать больше контекста (в случае с ошибкой), но общая картина уже становится ясна.

Любое сообщение об ошибке, в котором отсутствует эта минимальная информация, становится шумом, поскольку у вас появляется беспокойство, но вы все еще не можете действовать. Сначала нужно углубиться в ситуацию, чтобы понять, насколько проблема серьезна.

Если вы все еще не поняли, как писать полезные сообщения, я поделюсь с вами очень простым лайфхаком:

Всегда спрашивайте себя: Что я хочу уяснить для себя, после получения такого лога?

Предоставление контекста с помощью Python

В Python атрибуты логов можно добавить с помощью дополнительного поля, например:

Контекст не отменяет необходимости в содержательных сообщениях! Поэтому я бы так не делал:

Сообщения должны быть четкими и не оставлять места вопросам о том, что же вообще происходит. Контекст должен обогащать ваш опыт, предоставив информацию о более глубоких деталях, и давать вам понимание, по какой причине что-то произошло.

Нечто большее, чем logger.info и logger.error

Не так-то просто понять, что происходит, когда тысячи клиентов выдают логи «Connecting to Slack». Поскольку вы выдаете логи, а вашим приложением пользуются несколько клиентов, нужно иметь возможность фильтровать информацию по релевантности.

Чтобы упростить ситуацию, вот вам новое эмпирическое правило (будьте гибкими):

Уровень

Когда используется

Для какой-то действительно повторяющейся информации. Возможно, было бы полезно выдавать весь контекст информации, но порой этого не нужно.

Когда происходит что-то важное, достойное того, чтобы о нем было известно большую часть времени.

Случилось что-то странное (но не прервало поток/операцию). Если проблема возникнет на более поздних этапах, такой лог может дать вам подсказку.

Произошла ошибка, ее следует устранить как можно быстрее.

Произошла очень серьезная ошибка, она требует немедленного вмешательства. Если не уверены в критичности ошибки, применяйте ERROR .

Для описанной системы/потоков, я бы использовал уровни логов, как определено:

Что делать с logger.critical и logger.warning ?

WARNING – недостаточно веская причина для остановки потока, однако это предупреждение на будущее, если возникнет какая-то проблема.

CRITICAL – самый тревожный предупреждающий лог, который вы когда-либо получите. По сути, он должен быть той самой причиной встать в три часа ночи и пойти что-то чинить.

Для этих случаев мы рассмотрим:

Для AWS: если какой-то регион AWS недоступен, мы можем предположить, что у пользователя там нет никаких ресурсов, поэтому можно двигаться дальше.

Для Slack: если OAuth завершится неудачно из-за невалидного id клиента, значит остальные пользователи столкнутся с той же проблемой, интеграция не отработает, пока мы вручную не сгенерируем новый id. Это дело кажется достаточно критичным.

Непопулярное мнение: использование DEBUG -уровня на продакшене

Да, я считаю, что логи DEBUG нужно использовать на продакшене.

Другой вариант – включить дебаг после того, как странная ошибка потребует более детального разбирательства.

Простите, но для меня такой вариант недопустим.

В реальном мире клиентам нужна быстрая реакция, командам нужно выполнять свою работу и постоянно поддерживать системы в рабочем состоянии. У меня нет времени и пропускной способности для нового деплоя или включения флага и ожидания повторения проблемы. Я должен реагировать на неожиданные проблемы в считанные секунды, а не минуты.

Правильно настройте логгер

Еще я замечаю, что люди испытывают трудности при настройке логгера (или вообще его не настраивают). Конечно, документация в Python не очень дружелюбная, но это не оправдание, чтобы вообще ее не трогать.

Использование ручных команд непросто поддерживать и понимать;

fileConfig – негибкая история, у вас не бывает динамических значений (без дополнительных фокусов);

dictConfig – простая история в запуске и настройке.

Я поделюсь несколькими советами и определениями, которые вам надо знать, а затем мы создадим окончательную конфигурацию на реальных примерах из проектов, над которыми я работаю.

Вот кусочек того, о чем мы будем говорить дальше:

Что такое логгеры?

В любом случае, придерживайтесь:

Форматируйте логи

Форматтеры вызываются для вывода конечного сообщения и отвечают за него преобразование в конечную строку.

Когда я работал в Zak (бывшем Mimic), и даже сегодня в Lumos мы форматировали логи как JSON. Он является хорошим стандартом для систем, работающих на продакшене, поскольку содержит множество атрибутов. Проще визуализировать JSON, чем обычную длинную строку, и для этого вам не нужно создавать свой собственный форматтер (ознакомьтесь с python-json-logger).

Для локальной разработки я рекомендую использовать форматирование по умолчанию для простоты.

Ваше решение будет зависеть от вида проекта. Для Tryceratops я решил использовать обычный форматтер, поскольку он проще и работает локально, там нет нужды в JSON.

Фильтруйте логи

Фильтры можно использовать либо для фильтрации логов (внезапно), либо для добавления дополнительного контекста в запись лога. Рассматривайте фильтры, как хуки, вызываемые до обработки итогового лога.

Их можно определить следующим образом:

Или их можно добавить прямо в логгер или обработчик для упрощения фильтрации по уровням (скоро будут примеры).

Обрабатывайте логи и то, как все связано

Обработчики представляют из себя комбинации форматтеров, выходных данных (потоков) и фильтров.

С ними вы можете создавать следующие комбинации:

Выводить все логи из info (фильтр), а потом выводить JSON в консоль.

Выводить все логи, начиная с error (фильтр) в файл, содержащий только сообщение и трассировку стека (форматтер).

Наконец логгеры указывают обработчикам.

Пример logging.dictConfig

Теперь, когда вы понимаете, что делают все эти объекты, давайте писать собственные! Как всегда, я постараюсь показать вам примеры из реальной жизни. Я буду использовать конфигурацию Tryceratops. Вы можете открыть ссылку и посмотреть самостоятельно окончательную конфигурацию.

Шаблон конфигурации логирования

Начнем с такого каркаса, создадим константу LOGGING_CONFIG :

Version всегда будет 1. Это плейсхолдер для возможных следующих релизов. На данный момент версия всего одна.

Я рекомендую оставить значение disable_existing_loggers в False, чтобы ваша система не поглощала другие неожиданные проблемы, которые могут возникнуть. Если вы хотите изменить другие логгеры, я бы порекомендовал их явно переписать (хоть это и скучно).

Корневой логгер можно определить тремя разными способами, что сбивает с толку:

Выбирайте любой! Мне нравится оставлять его снаружи, поскольку так он выглядит очевиднее и подробнее говорит о том, чего я хочу, ведь корневой логгер влияет на все другие определенные логгеры.

Конфигурация логирования: форматтеры

Я дополню пример из Tryceratops примером с JSON из Lumos.

Конфигурация логирования: обработчики

Конфигурация логирования: логгеры и root

Давайте разберемся, что происходит:

Кроме того, обратите внимание, что я могу переписать правила по умолчанию. Через настройки или позже динамически. Например, каждый раз, когда triceratops получает подобный флаг от CLI, он обновляет конфигурацию logging чтобы включить дебаг.

Логирование – это важно, но наличие хорошо структурированных исключений и блоков try/except также важно, поэтому вы можете также прочитать, как профессионально обрабатывать и структурировать исключения в Python.

Всех желающих приглашаем на demo-занятие «Основы ООП». Цели занятия: научиться работать с классами и познакомиться с наследованием.
Краткое содержание:
— мутабельность экземпляров класса
— передача аргументов в инициализатор
— наследование
— переопределение методов
— обращение к методам суперкласса
>> РЕГИСТРАЦИЯ

Источник