Протокол логирования что это

Обновлено: 05.07.2024

Управление типом и подробностью журналируемой информации

Конфигурационный файл syslog.conf

Источник (он же категория) может быть следующим:

Обычный файл

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

Именованные каналы

Терминал и консоль

Терминал, такой как /dev/console.

Удаленная машина

Список пользователей

Пример несложного syslog.conf:

Как и во многих конфигурационных файлах, синтаксис следующий:

В синтаксисе конфигурационного файла можно поставить перед приоритетом знак !, чтобы показать, что действие не должно применяться, начиная с этого уровня и выше. Подобным образом, перед приоритетом можно поставить знак =, чтобы показать, что правило применяется только к этому уровню, или !=, чтобы показать, что правило применяется ко всем уровням, кроме этого. Ниже показано несколько примеров (man syslog.conf можно найти множество других примеров):

Запуск демона syslogd

Запуск демона протоколирования запускаются на этапе инициализации системы посредством скрипта /etc/rc.d/init.d/syslog, однако для того, чтобы задать параметры запуска, нет необходимости корректировать этот скрипт — начиная с версии 7.2, опции запуска считываются из отдельного конфигурационного файла /etc/sysconfig/syslog (/etc/default/syslog в debian).

Вот некоторые возможные параметры запуска демона syslogd:

После запуска демона syslogd создается файл статуса /var/lock/subsys/syslog нулевой длины, и файл с идентификационным номером процесса /var/run/syslogd.pid.

С помощью команды
kill -SIGNAL cat /var/run/syslogd.pid

можно послать демону syslogd один из следующих сигналов: SIGHUP — перезапуск демона; SIGTERM — завершение работы; SIGUSR1 — включить/выключить режим отладки.

Вообще-то в системе запускаются два демона протоколирования — syslogd и klogd. Оба демона входят в состав пакета sysklogd.

Автоматическая ротация (обновление заполненных файлов) и архивирование журналов

Со временем, файл журнала имеет свойство увеличиваться, особенно при интенсивной работе какого-либо сервиса. Соответственно, необходимо иметь возможность контролировать размер журналов. Это делается при помощи команды logrotate, которая обычно выполняется демоном cron. О работе cron я расскажу в следующих статьях. Главная цель команды logrotate состоит в том, чтобы периодически создавать резервные копии журналов и создавать новые чистые журналы. Сохраняется несколько поколений журналов и, когда завершается срок жизни журнала последнего поколения, он может быть заархивирован (сжат). Результат может быть отправлен по почте, например, ответственному за ведение архивов.

Для определения порядка ротации и архивирования журналов используется конфигурационный файл /etc/logrotate.conf. Для разных журналов можно задать разную периодичность, например, ежедневно, еженедельно или ежемесячно, кроме того, можно регулировать количество накапливаемых поколений, а также указать, будут ли копии архивов отправляться ответственному за ведение архивов и, если будут, когда. Ниже показан пример файла /etc/logrotate.conf:

Глобальные опции размещаются в начале файла logrotate.conf. Они используются по умолчанию, если где-то в другом месте не задано ничего более определенного. В примере ротация журналов происходит еженедельно и резервные копии сохраняются в течение четырех недель. Как только производится ротация журнала, на месте старого журнала автоматически создается новый. Файл logrotate.conf может содержать спецификации из других файлов. Так, в него включаются все файлы из каталога /etc/logrotate.d.

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

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

В этом примере ротация /var/log/messages производится по достижении им размера 100 КБ. Накапливается пять резервных копий, и когда истекает срок жизни самой старой резервной копии, она отсылается по почте на адрес logadmin@sysloger. Командное слово postrotate включает скрипт, перезапускающий демон syslogd после завершения ротации путем отправки сигнала HUP. Командное слово endscript необходимо для завершения скрипта, а также в случае, если имеется скрипт prerotate. Более полную информацию см. в страницах руководства man для logrotate.

Параметры, задаваемые в конфигурационном файле logrotate.conf:

Изучение и мониторинг журналов

Dec 17 16 : 35 : 57 proxy pppd [ 11345 ] : LCP terminated by peer ( ^ P ] kV ^ @ M - Mt ^ @ ^ @ ^ @ ^ @ )

Dec 17 16 : 35 : 57 proxy pppd [ 11345 ] : Script / etc / ppp / ip - down finished ( pid 12084 ) , status = 0x1

Далее в файле протокола можно обнаружить версию ядра, параметры его запуска, информацию о типе процессора и объеме ОЗУ:

Dec 17 08 : 32 : 56 syslog - server kernel : Memory : 125652k / 130560k available ( 1365k kernel code , 4200k reserved , 92k data , 236k init , 0k highmem )

Dec 17 08 : 32 : 56 syslog - server kernel : CPU : Intel ( R ) Pentium ( R ) 4 CPU 1.60GHz stepping 02

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

Dec 17 16 : 46 : 09 syslog - server pppd [ 12548 ] : pptpd - logwtmp . so ip - up ppp0 maikop 94.77.0.150

Dec 17 16 : 46 : 09 syslog - server pppd [ 12548 ] : Script / etc / ppp / ip - up finished ( pid 12552 ) , status = 0x0

Dec 17 16 : 46 : 49 syslog - server pptpd [ 12581 ] : CTRL : Client 85.175.197.65 control connection started

Dec 17 16 : 46 : 49 syslog - server pptpd [ 12581 ] : CTRL : Starting call ( launching pppd , opening GRE )

Dec 17 16 : 46 : 49 syslog - server pppd [ 12582 ] : Plugin / usr / lib / pptpd / pptpd - logwtmp . so loaded .

Кроме файлов-журналов, указанных в /etc/syslog.conf, существуют так же и другие файлы, например файл /var/log/dmesg, который хранит информацию о процессе загрузки системы до запуска syslogd, а так же файлы /var/log/lastlog, /var/log/wtmp, /var/log/btmp, имеющие двоичный формат и и хранящие информацию о последнем входе пользователя в систему, о всех удачных входах пользователей в систему и о всех неудачных входах пользователей в систему соответственно. Так же в каталоге /var/log/ могут находится лог-файлы таких демонов как веб-сервер или прокси-сервер. Формат данных файлов аналогичен журналам syslogd.

Подведем небольшой итог:

На сегодня это все. Надеюсь описал все максимально понятно. Со временем буду дополнять статью!

Управление типом и подробностью журналируемой информации

Конфигурационный файл syslog.conf

Источник (он же категория) может быть следующим:

Обычный файл

Терминал и консоль

Терминал, такой как /dev/console.

Удаленная машина

Список пользователей

Пример несложного syslog.conf:

Как и во многих конфигурационных файлах, синтаксис следующий:

Запуск демона syslogd

Вот некоторые возможные параметры запуска демона syslogd:

С помощью команды
kill -SIGNAL `cat /var/run/syslogd.pid`

Автоматическая ротация (обновление заполненных файлов) и архивирование журналов

Параметры, задаваемые в конфигурационном файле logrotate.conf:

Изучение и мониторинг журналов

Подведем небольшой итог:

На сегодня это все. Надеюсь описал все максимально понятно. Со временем буду дополнять статью!

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

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

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

Стандарт PSR-3. Уровни логирования

PSR — это свод рекомендаций для PHP-разработчиков. Он содержит советы по оформлению кода, некоторые интерфейсы и другие рекомендации. Один из его документов (PSR-3) посвящён реализации логера.

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

DEBUG — отладочная информация, подробно раскрывающая детали события;
INFO — любые интересные события. Например, когда пользователь авторизовался;
NOTICE — важные события в рамках ожидаемого поведения;
WARNING — исключительные ситуации, не являющиеся ошибками. Например, использование устаревшего метода, неправильный запрос в API;
ERROR — ошибки, которые следует отслеживать, но они не требуют срочного исправления;
CRITICAL — критическое состояние или событие. Например, недоступность компонента, неожиданное исключение (Exception);
ALERT — ошибка или событие, требующие срочных действий. Например, когда база данных недоступна;
EMERGENCY — ситуация, когда программа или система полностью выведены из строя.

Чтобы использовать эти уровни, достаточно добавлять их название к строке каждой записи журнала. Например:

На уровни ALERT и EMERGENCY часто ставят дополнительное информирование, например по SMS. По INFO можно легко восстановить последовательность действий пользователя, по DEBUG — узнать точные значения переменных, результат работы функции в определённом месте и прочее.

PSR-3. Интерфейс для класса-логера

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

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

Для начала загрузим код стандарта PSR-3 с помощью Composer.

В загруженном пакете содержится несколько классов, трейтов и интерфейсов. Среди них — LogLevel, который мы разобрали выше, и интересующий нас в данный момент LoggerInterface. Давайте создадим новый класс, реализующий этот интерфейс. Важно: убедитесь, что у вас подключён класс-автозагрузчик (vendor/autoload.php).

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

Для полного удовлетворения интерфейса LoggerInterface нам осталось написать реализацию для методов emergency, alert, critical, error, warning, notice, info и debug, которые соответствуют уровням (их мы разобрали выше). Их реализация сводится к очень простому принципу: мы вызываем метод log, передав в него необходимый уровень.

Использование логера

Теперь, когда наш класс реализует интерфейс, предложенный стандартом PSR-3, мы можем легко задействовать его в любом месте. Например, в файле index.php:

Или в любом другом классе.

Обратите внимание: в качестве типа аргумента конструктора мы указываем не конечную реализацию (FileLogger), а именно интерфейс стандарта PSR-3. Это удобно, потому что позволяет легко заменять применяемый логер на любой другой, поддерживающий этот интерфейс.

Контекст

Вы могли заметить, что все методы интерфейса LoggerInterface содержат аргумент $context. Зачем он нужен?

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

Чтобы применять этот аргумент, нам нужно поддержать его в методе log. Давайте доработаем его, учитывая, что $context — массив.

Теперь в любом месте вызова логера мы можем передать вторым аргументом массив дополнительной информации.

В результате мы получим запись следующего вида:

Библиотека Monolog

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

Здорово, что всё это уже реализовано в большинстве библиотек. Одна из самых распространённых – monolog.

Среди весомых преимуществ этого пакета:

полная поддержка PSR-3;
поддержка разных принципов обработки логов в зависимости от уровня;
поддержка имён каналов (имена логеров);
очень широкая поддержка фреймворков.

Чтобы начать использовать этот прекрасный инструмент, установим его с помощью Composer.

Использование Monolog

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

Если мы запустим этот код, в файле gb.log появится запись следующего вида:

Очень похоже на то, что было у нас ранее, кроме добавления имени канала (gb-demo).

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

Подключённый на уровень ERROR обработчик будет принимать на себя все записи уровня ERROR и выше. Поэтому вызов метода emergency попадает в оба файла: gb.log и errors.log

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

Все записи от одного запроса

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

Рассмотрим пример реализации такого приёма:

Что нам даёт такая простая доработка? Важную возможность — группировать все записи запросам пользователя.

Что дальше?

Monolog поддерживает множество полезных готовых обработчиков, на которые стоит обратить внимание:

TelegramBotHandler — отправляет записи в Telegram от имени бота. Пригодится для высоких уровней логирования;
SlackHandler — похож на предыдущий, но отправляет записи в Slack;
SwiftMailerHandler — позволяет отправлять записи по email;
ChromePHPHandler – даёт доступ к журналам прямо из браузера Chrome в режиме Live.

Заключение

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

Главное — помнить простые правила:

Следование PSR-3 позволит легче заменять классы-логеры в вашем коде и использовать внешние библиотеки.
Разные уровни логирования помогут сосредоточиться на важном.
Отделение динамической информации в контекст упростит поиск по журналам.
Библиотека Monolog реализует практически все возможные хотелки. Обязательно изучите её.
С помощью идентификатора сессии можно разделить записи в журналах по каждому запросу.
Лучше писать много лишних логов, чем не дописать один важный.

Стандарт PSR-3. Уровни логирования

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

DEBUG — отладочная информация, подробно раскрывающая детали события;
INFO — любые интересные события. Например, когда пользователь авторизовался;
NOTICE — важные события в рамках ожидаемого поведения;
WARNING — исключительные ситуации, не являющиеся ошибками. Например, использование устаревшего метода, неправильный запрос в API;
ERROR — ошибки, которые следует отслеживать, но они не требуют срочного исправления;
CRITICAL — критическое состояние или событие. Например, недоступность компонента, неожиданное исключение (Exception);
ALERT — ошибка или событие, требующие срочных действий. Например, когда база данных недоступна;
EMERGENCY — ситуация, когда программа или система полностью выведены из строя.

Чтобы использовать эти уровни, достаточно добавлять их название к строке каждой записи журнала. Например:

PSR-3. Интерфейс для класса-логера

Для начала загрузим код стандарта PSR-3 с помощью Composer.

Использование логера

Или в любом другом классе.

Контекст

Вы могли заметить, что все методы интерфейса LoggerInterface содержат аргумент $context. Зачем он нужен?

Теперь в любом месте вызова логера мы можем передать вторым аргументом массив дополнительной информации.

В результате мы получим запись следующего вида:

Библиотека Monolog

Здорово, что всё это уже реализовано в большинстве библиотек. Одна из самых распространённых – monolog.

Среди весомых преимуществ этого пакета:

полная поддержка PSR-3;
поддержка разных принципов обработки логов в зависимости от уровня;
поддержка имён каналов (имена логеров);
очень широкая поддержка фреймворков.

Чтобы начать использовать этот прекрасный инструмент, установим его с помощью Composer.

Использование Monolog

Если мы запустим этот код, в файле gb.log появится запись следующего вида:

Очень похоже на то, что было у нас ранее, кроме добавления имени канала (gb-demo).

Все записи от одного запроса

Рассмотрим пример реализации такого приёма:

Что нам даёт такая простая доработка? Важную возможность — группировать все записи запросам пользователя.

Что дальше?

Monolog поддерживает множество полезных готовых обработчиков, на которые стоит обратить внимание:

TelegramBotHandler — отправляет записи в Telegram от имени бота. Пригодится для высоких уровней логирования;
SlackHandler — похож на предыдущий, но отправляет записи в Slack;
SwiftMailerHandler — позволяет отправлять записи по email;
ChromePHPHandler – даёт доступ к журналам прямо из браузера Chrome в режиме Live.

Заключение

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

Содержание:

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

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

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

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

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

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

файл регистрации ошибок error.log;
данные о доступах log;
основной системный журнал syslog;
файл загрузки ОС dmesg;
журнал nginx.

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

предупреждение – Warning;
подробности (System и EventData);
ошибка – Error;
сведения – Information;
критический – Critical.

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

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

адрес ресурса;
IP-адрес пользователя;
дата и время посещения, часовой пояс;
GET/POST – запрос на получение или отправку данных;
к какой странице обращались;
протокол пользователя (как зашел на ресурс);
код отклика сервера;
число переданных байтов;
информация о посетителе (боте) – устройство, ОС, другие данные.

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

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

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