albibek — Журналирование событий. Часть 1 - Как и зачем?

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

Общая информация

Вообще, каждый программист вправе выбрать тот способ, каким он собирается доносить сообщения своей программы до пользователя. Можно просто вывести его в stdout или stderr, можно записать в какой-то файл, можно отправить по сети и т.п. Поскольку проблема возникла достаточно давно и стоит практически перед каждым программистом, существует стандартный способ получения таких сообщений, их классификации и управления каналами вывода. Способ этот получил название "system logging", или коротко - syslog.
Как подсказывает нам тов. Википедия, syslog появился как система обработки сообщений от Sendmail и впоследствии развился как стандарт де-факто для обработки сообщений от любых программ. На сам syslog стандарта как такового не существует, но существует RFC3164 - стандарт передачи сообщений журналов при помощи UDP, замещённый на сегодняшний день(пока, к сожалению только де-юре) стандартом RFC5424. Современные syslog-демоны достаточно четко придерживаются RFC в отношении сетевого обмена, поэтому и на уровне приложения оперируют понятиями из этого стандарта.

Терминология

Современные syslog-серверы, кроме понятия "сообщение" оперируют ещё двумя понятиями:

Facility(читается "фэсилити"). Более-менее адекватный перевод - "средство доставки сообщений". Позволяет классифицировать источник сообщения, т.е. отнести сообщение к некоторой категории. RFC содержит список всех возможнных facility, самые популярные среди которых:
- kernel messages - сообщения ядра
- user-level messages - сообщения уровня пользователя
- mail system - сообщения почтовой подсистемы
- system daemons - сообщения почтовых служб
- security/authorization messages - сообщения безопасности/авторизации
Кроме именованных есть также 7 пользовательских - от local0 до local7, которые вы можете трактовать по-своему, чем часто пользуются, например, циски и другие свитчи и роутеры.

Severity. Важность ошибки - задаётся в RFC некоторым списком (см. там же сразу после перечисления facility), упорядоченным по убыванию важности. Всего их 7, самая низкая - info(7), самая высокая - emergency(0).

Таким образом, каждое сообщение, отправляемое syslog-серверу, должно, кроме текста сообщения, обязательно иметь категорию источника и важность ошибки(дальше из-за лени буду писать facility и severity).

В результате, любая настройка syslog-сервера сводится к следующей задаче:
Определение действий над сообщением по критериям facility, severity, хосту-источнику(для приходящих по сети), собственно тексту сообщения, возможно, другим критериям: не делать ничего, записать в файл, записать в пайп(man fifo(7)), записать в БД, переслать на другой syslog-сервер, оповестить по по e-mail/jabber/ICQ, всё сразу и др.

Скорее всего, в вашем любимом дистрибутиве уже есть syslog-демон, он настроен и работает. Вместе с ним как правило система ротации журналов(как правило logrotate). Она занимается удалением старых логов и соответственно переименовываен новые. Свои журналы вы можете найти по адресу /var/log/*.log. Файлы /var/log/*.log.1 или /var/log/*.log.1.gz это журналы за вчера тоже самое, но с цифрой 2 - за позавчера и т.д.

Syslog для Desktop-юзеров

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

Когда десктоп пользователю есть смысл смотреть логи?
- если вы настраиваете что-то, пытаясь понять, почему же, блин, оно не работает, логи - ваш первый помощник
- если у вас происходит что-то странное, и вы не можете понять, что именно. Кстати, кроме команды cat /var/log/somelog.log вам может пригодиться команда dmesg, выводящая сообщения от ядра, хотя в некоторых дистрибутивах то же самое можно увидеть в /var/log/kern.log.

Syslog для системных администраторов

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

Если отвалился диск в рейд-массиве, кончается место на дисках, убежали часы, идут попытки подобрать пароль на ssh, не прошёл ночной бекап, упала нода кластера, код криворуких программеров постоянно выдаёт ошибку или вообще произошло Фигзнаетчто, скорее всего, кроме как из логов, больше вы ниоткуда об этом не узнаете. Само собой, никто не заставляет вас каждый день пролистывать(grep-ать, awkоsedить, perlить) 10000-строчный файл, содержащий все сообщения за прошедшие сутки/неделю/месяц/пятитысячелетие.

Всё уже украдено написано до нас! Существует множество утилит, которые (пока что) не являются темой для разговора. Посему:

- Нетерпеливые непрофессионалы курят документацию на разнообразные сислог-демоны: rsyslog, syslog-ng, sysklogd.

- Нетерпеливые профессионалы, уже настроившие syslog-серверы читают про logwatch, Prelude-LML, OSSEC и "многадумают".

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