Система системного журналирования (syslog) является одной из самых восхитительных вещей в UNIX. В отличие от некоторых операционных систем которые заставляют вас использовать лишь тот ограниченный диапазон журналов, которые они соизволят вам предоставить, UNIX позволяет вам регистрировать почти все что угодно с практически любым уровнем детализации. Так как стандартные системные средства журналирования предусмотрены для большинства средств системы UNIX, администратор может выбрать конфигурацию журналирования удовлетворяющую его требованиям. Моя сеть обычно имеет один журналирующий узел который поддерживает журналирование не только для FreeBSD-узлов, но и для маршрутизаторов Cisco, коммутаторов и любых других систем поддерживающих syslog.

Журналирующая система устроена достаточно просто. Программы шлют записи предназначенные для журналирования к системному демону syslogd. Syslogd сравнивает каждую пришедшую запись с правилами, которые находятся в файле /etc/syslog.conf. Когда обнаруживается соответствие, syslogd обрабатывает запись описанным в syslog.conf способом.

Файл /etc/syslog.conf состоит из двух столбцов. В первом указывается правило отбора записей для журнала. Во втором содержится описание действий, которые будут предприняты для обработки подошедшей записи. Большинство затруднений вызывает полное понимание того, как точно указать правило отбора журналируемых записей.

Источник журналируемых записей описывается указанием категории (facility) и уровня (level). Категория это или источник записей, или программа, которая шлет сообщения демону syslogd. Существуют следующие категории:

• auth – Все что связано с авторизацией пользователей, вроде login и su.
• authpriv – Тоже самое что и auth, однако пишет журнал в файл, который могут читать лишь некоторые пользователи (очевидно, автор имел в виду тот факт, что сообщения собираемые в этой категории могут содержать открытые пароли пользователей, которые не должны попадать на глаза посторонним людям, и следовательно файлы журналов должны иметь соответствующие права доступа).
• console – Сообщения, обычно печатаемые на системной консоли, могут быть записаны в журнал при помощи этой категории.
• cron – Сообщения от системного планировщика.
• daemon – Ловушка для сообщений от всех остальных системных демонов, которые не имеют явно описанных категорий.
• ftp – При помощи этой категории вы сможете сконфигурировать ваш FTP сервер, что бы он записывал свои действия. Смотрите /etc/inetd.conf.
• kern – Сообщения от ядра.
• lpr – Сообщения от системы печати.
• mail – Сообщения от почтовой системы.
• mark – Эта категория используется для того, что бы помещать в журнал сообщение каждые 20 минут. Она может быть полезна в комбинации с некоторыми другими журналами (например вы сможете узнать с 20-ти минутной точностью, когда же завис ваш сервер – прим. переводчика).
• news – Сообщения от сервера новостей.
• ntp – Сообщения от сервера точного времени.
• security – Сообщения от различных служб безопасности, таких как ipfw или ipf.
• syslog – Система журналирования может журналировать сообщения от самой себя. Только не пишите в журнал сообщение о том, что вы пишете в журнал сообщение от системы журналирования, иначе у вас закружится голова :-)
• user – Предназначена для сбора разнообразных сообщений. Если вы не укажете категорию журналирования для программ пользователя, то они будут использовать эту категорию (более чем спорное утверждение – прим. переводчика).
• uucp – Собирает сообщения от UNIX-to-UNIX Copy Protocol. Это часть истории UNIX и вероятнее всего она вам никогда не понадобится (хотя до сих пор определенная часть почтовых сообщений доставляется через UUCP – прим. переводчика).
• local0 - local7 – Зарезервированные категории для использования администратором системы. Многие программы дают возможность указать категорию журналирования, если ваша программа это позволяет, выбирайте одну из них.

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

FreeBSD предоставляет восемь уровней важности сообщений. С их помощью, вы можете сообщить syslog, что записывать в журнал, а что отбросить. Вот эти уровни, в порядке уменьшения важности:
emerg – Система в панике. Сообщения немедленно выводятся на все активные терминалы. Система обычно накрывается медным тазом :-), или остается чрезвычайно, чрезвычайно нестабильной. Продолжение работы невозможно.
alert – Это плохо, но не настолько плохо как уровень emerg. Система может продолжить работу, но эту ошибку следует устранить немедленно.
crit – Это критические ошибки, такие как проблемы с аппаратным обеспечением или серьезные нарушения работы программного обеспечения. Если ваш жесткий диск содержит плохие блоки, они проявятся в виде критических ошибок. Если вы очень смелый, попробуйте продолжить работу.
err – Разнообразные ошибки. Это скверно, такие ошибки должны быть устранены, но они не разрушат вашу систему.
warning – Разнообразные предупреждения.
notice – Общая информация которая должна быть записана, если она вам нужна, но вероятно она не потребует вашей реакции.
info – Различная системная информация.
debug – Этот уровень обычно используется программистами и иногда системными администраторами, которые пытаются понять – почему же эта программа так поступает? Отладочные сообщения могут содержать всю информацию которую счел необходимым вывести ее разработчик для отладки кода; между прочим она может содержать данные нарушающие приватность ваших пользователей.
none – Это специальный уровень означающий – «ничего не записывать в данной категории». Он обычно применяется для исключения информации из групповых записей.

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

mail.info /var/log/maillog

В журнал /var/log/maillog будут записаны сообщения от почтовой системы, с уровнем выше или равным уровню info.

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

mail.* /var/log/maillog

Для записи в журнал абсолютно всех событий происходящих в системе раскомментируйте строчку all.log (в файле /etc/syslog.conf – прим. переводчика):

*.* /var/log/all.log

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

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

*.*;authpriv.none /var/log/all.log

В /etc/syslog.conf вы можете использовать операторы сравнения. Допустимы следующие операторы: «<» (меньше чем), «=» (равно), «>» (больше чем). Применив эти операторы вы сможете например разделить журнал записей почтового трафика и журнал отладочной информации предоставляемой почтовой системой:

mail.info /var/log/maillog
mail.=debug /var/log/maillog.debug

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

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

local3.* /var/log/whatever

В качестве источника записей вы можете указать имя программы. Если программа позволяет использовать категории, применяйте их. Однако, если вам не хватает категорий (local0-7 вполне могут закончиться – прим. переводчика), или программа просто не поддерживает syslogd, то вы можете использовать ее имя.

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

!ppp
*.* /var/log/ppp.log

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

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

Вы можете отсылать журналируемую информацию на другую машину, предварив ее имя символом «@». Следующий пример демонстрирует как можно перенаправлять все получаемое вашим syslog’ом на выделенный syslog-сервер в моей сети:

/etc/syslog.conf на loghost используется для окончательной обработки присылаемых записей.

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

Наконец, если вы хотите воспользоваться какой-нибудь другой программой для журналирования, вы можете использовать символ «¦» для перенаправления потока ввода-вывода на эту программу:

mail.* |/usr/local/bin/mailstat.pl

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