Журнал LinuxFormat - перейти на главную

LXF91:Дневники демонов

Материал из Linuxformat
(Различия между версиями)
Перейти к: навигация, поиск
(Новая: == Ведение журналов Syslog и его окрестности. Записки демонов == ''Учитесь правильно читать файлы журналов:...)
 
Строка 12: Строка 12:
  
 
В данной серии из двух уроков мы хотели бы помочь вам понять и настроить процесс регистрации событий. Начнем с создания файлов журналов, затем разберемся, как и где настроить журналируемые события. А через месяц рассмотрим некоторые инструменты для управления, анализа и обобщения этих файлов.
 
В данной серии из двух уроков мы хотели бы помочь вам понять и настроить процесс регистрации событий. Начнем с создания файлов журналов, затем разберемся, как и где настроить журналируемые события. А через месяц рассмотрим некоторые инструменты для управления, анализа и обобщения этих файлов.
 +
 +
=== Тонкости Syslogd ===
 +
Нет единого жесткого правила, определяющего, что нужно записывать. По сути, сервис записывает сообщение при совершении действия, которое создатель программы посчитал достойным упоминания. FTP-
 +
сервер может создавать запись каждый раз при запросе файла; ядро – находя новое устройство; и т.д., причем обычно стараются записывать события, выходящие за рамки обычных.
 +
 +
Некоторые сервисы, например, ''Apache'', ведут свои собственные журналы. Другие – включая почту, печать, подсистему безопасности, ''Cron'' и ядро – делают записи с помощью отдельного демона, ''syslogd'', обрабатывающего сообщения от их имени. Рассмотрим сначала метод ''syslog''.
 +
 +
Отправляя записи через ''syslogd'', сервисы не только передают тексты сообщений, но и указывают ‘источник’ (facility) и ‘уровень’ (level). Источник идентифицирует подсистему, от которой пришло сообщение, а уровень означает его важность. Syslog имеет файл настроек, определяющий, куда посылать то или иное сообщение, на основе его источника и уровня (как мы увидим, записи не обязательно направляются в журнал, хотя это их обычный путь).
 +
 +
Список источников включает '''auth, authpriv, cron, daemon, fpm kern, lpr, mail, news, syslog, user, uucp''' и от '''local0''' до '''local7'''. Восемь источников '''local''' ''syslogd'' предоставляет для пользовательских нужд. Кому интересно, '''uucp''' означает ‘Unix to Unix copy’, это древний набор программ для удаленной передачи файлов и выполнения программ. Название также выдает возраст syslog: он начал использоваться с 1980-х.
 +
Существует восемь возможных уровней, начиная от щадящего до катастрофического, как показано в таблице «''Уровни Syslog''». (Описание каждого уровня является нашей интерпретацией). Между прочим, некоторые авторы используют термин ‘приоритет’, а не ‘уровень’, но большая часть документации по syslog использует термин ‘приоритет’ для обозначения комбинации источника и уровня. Будьте осторожны – возможны недоразумения.
 +
 +
Что происходит, когда сообщение доходит до ''syslogd''? Это зависит от файла настройки, но возможны пять вариантов:
 +
*Оно может быть добавлено в файл. Это наиболее распространенный выбор.
 +
*Оно может выдано на терминал любого указанного пользователя.
 +
*Оно может быть записано в FIFO (именованный канал). Это бывает полезно при отладке; или можно запустить grep и вытаскивать интересные сообщения из FIFO, пользуясь шаблоном регулярного выражения.
 +
*Оно может быть перенаправлено syslogd, находящемуся на удаленном узле.
 +
*Наконец, если для сообщения не определено, что с ним делать, оно просто игнорируется.
 +
 +
Мы скоро рассмотрим каждое из этих действий подробно. А сейчас
 +
займемся самым важным файлом настройки, '''/etc/syslog.conf''', который
 +
связывает все вместе. Вот возможные варианты строк этого файла.
 +
Это не настоящие настройки, просто набор примеров для пояснения
 +
синтаксиса. Номера строк даны для удобства ссылки – в сам файл они
 +
не входят.
 +
1    mail.err /var/log/mail
 +
2    mail.* /var/log/mail
 +
3    mail.debug /var/log/mail
 +
4    *.crit /var/log/critical
 +
5    *.* @loghost
 +
6    mail.=debug /var/log/maildebug
 +
7    mail.warn;cron.notice var/log/messages
 +
8    *.*;auth.none /var/log/messages
 +
9    auth,kern.crit /var/log/critical
 +
10  *.*;auth,kern.none /var/log/messages
 +
11  *.=debug;*.=info -/var/log/messages
 +
12  *.crit root
 +
13  *.crit *
 +
14  *.=notice;*.=warn |/dev/xconsole
 +
 +
Каждое правило содержит селектор и действие. Так, в строке 1
 +
селектором является '''mail.err'''. Это значит, что правило применяется к
 +
сообщениям от источника '''mail''' уровня '''err''' или выше; то есть уровни '''err,
 +
crit, alert''' или '''emerg'''. Затем идет действие – добавить сообщение в файл
 +
'''/var/log/mail'''. Легко, правда?
 +
 +
Правила бывают и посложнее. Селекторы допускают символы подстановки ('''*''') как для источника, так и для уровня. Так, селектор в строке '''2''' означает ‘все сообщения от источника '''mail'''’ согласно принципу ‘от этого уровня и выше’, строка '''3''' делает то же самое. Селектор в строке '''4''' означает ‘сообщения уровня crit (или выше) от любого источника’, а строка '''5''', понятное дело, применяется ко всем сообщениям. Знак равенства ('''=''') перед уровнем означает, что правило применимо только к этому уровню, поэтому правило в строке '''6'''применимо сообщениям от источника '''mail''' только уровня '''debug'''. Можно указать несколько селекторов, разделив их точкой с запятой(''';''') как показано в строке '''7''' (такой же эффект достигается написанием двух отдельных правил). Пустой уровень none используется для исключения всех сообщений от данного источника и обычно используется вместе с ''';''', как показано в строке '''8''', соответствующей всем сообщениям, кроме идущих от источника auth.
 +
{{Врезка|left|
 +
Заголовок=Новое поколение|
 +
Содержание=
 +
Некоторые из последних дистрибутивов – отметим SUSE – заменили
 +
''syslogd'' на ''syslog-ng''. Этот демон обратно совместим с syslogd (он все
 +
еще использует источники и уровни), но дает системному администра-
 +
тору больший контроль над тем, откуда приходит сообщение и куда оно
 +
пересылается (ценой усложнения файла настройки). Сообщения могут
 +
выбираться на основе регулярных выражений, и для удаленного журна-
 +
лирования используется TCP, а не UDP. Если вы хотите, чтобы мы рас-
 +
смотрели syslog-ng подробно, пишите на letters@linuxformat.ru.|
 +
Ширина=350px}}
 +
Наконец, если надо, чтобы селектор включал несколько источников одного уровня, отделите имена источников запятой (''',''') как показано в строке '''9'''. Между прочим, для сообщения вполне нормально соответ-
 +
ствовать более чем одному селектору – '''syslogd''' просто выполнит все предписанные действия, по очереди.
 +
 +
=== Предпринимаем действие ===
 +
Как мы уже упомянули, чаще всего сообщения добавляются к файлу; вы просто определяете в качестве действия (абсолютный) путь к нему, как мы делали в наших примерах. Обычно '''syslogd''' сбрасывает свои буферы на диск после каждой записи. Это увеличивает шансы сообщения попасть в файл до того, как система рухнет, но это также значит, что менее критичные (и более объемные) сообщения уровней '''debug, '''info''' и '''notice''' вызывают излишнюю дисковую активность. Поставив дефис ('''-''') перед именем файла, вы разрешите '''syslogd''' не сбрасывать буферы на диск каждый раз (см. строку '''11'''). Можно попросить сообщение отобразиться на консоль любого подключенного пользователя ('''root''' является фаворитом), определив в качестве действия имя учетной записи, как в строке '''12'''.
 +
 +
Здесь также применяется символ подстановки ('''*'''); действие в строке '''13''' означает ‘написать всем подключенным пользователям’. Во времена, когда системный администратор постоянно сидел в текстовой консоли (если такое вообще было), это имело значение, но настольные компьютеры работают в графическом режиме, а за серверами особо не присматривают. Вы можете заставить '''syslogd''' перенаправлять сообщения на удаленную машину, добавив знак @ перед именем машины, указанным в качестве действия; пример приведен в строке '''5''', но мы подробно рассмотрим его попозже.
 +
 +
Наконец, можно велеть syslogd записывать сообщения в именованный канал, поставив символ канала ('''|''') перед его именем; пример – строка '''14''' (взятая из стандартного '''syslog.conf''' в Ubuntu).
 +
 +
=== Поэкспериментируем ===
 +
В порядке иллюстрации, настроим '''syslogd''' так, чтобы он посылал все сообщения от источника '''local6''' в файл '''/var/log/daemon'''. Для внесения изменений необходимо быть суперпользователем. Добавьте в файл '''syslog.conf''' строчку:
 +
local6.notice  /var/log/demolog
 +
 +
Далее, из командной строки, пошлите '''syslogd''' сигнал '''SIGHUP''', что-
 +
бы он перечитал файл.
 +
 +
# pkill -HUP syslogd
 +
 +
Для отправки сообщения в '''syslogd''' из командной строки служит команда '''logger'''. Вот типичный пример ее использования (опция '''-p''' указывает на источник и уровень сообщения):
 +
 +
# logger -p mail.info “Тестовое сообщение от источника mail”
 +
 +
Чтобы послать сообщение с созданным нами приоритетом '''local6.notice''', выполните
 +
 +
# logger -p local6.notice “Это тест”
 +
 +
Теперь просмотрите файл '''/var/log/demolog'''. Там должна быть примерно такая строка:
 +
 +
Dec 27 10:38:38 frodo chris: Это тест
 +
 +
Вы увидите, что '''syslogd''' предварил сообщение некоторой информацией: в данном случае это отметка времени, имя машины и UID процесса, пославшего сообщение. Попробуйте записать сообщения от источника '''local6''' с различными уровнями и проверить, какие уровни записываются.
 +
 +
Если посылать одно и тоже сообщение '''syslogd''' много раз подряд, то '''syslogd''' будет сохранять их раз в минуту и добавлять отметку вроде ‘'''last message repeated 22 times'''’ [«последнее сообщение повторялось 22 раза»] в конце каждого интервала времени. Это не дает демонам распоясаться и затопить файлы журналов потоком однотипных сообщений.

Версия 19:34, 10 марта 2008

Содержание

Ведение журналов Syslog и его окрестности. Записки демонов

Учитесь правильно читать файлы журналов: они дают ценные данные о вашей системе. Д-р Крис Браун начинает серию руководств из двух частей с рассказа о syslogd

Не будем врать: файлы журналов, вероятно, скучнейшие из всех в Linux-системе. Они однообразны и нудны, и просматривать их – все равно что перематывать бесконечные видеозаписи службы безопасности в поисках чего-нибудь интересного. Вдобавок сообщения в журнале часто пишутся в расчете на разработчика, а не конечного пользователя, и понять их трудно. Логично спросить: зачем вообще смотреть файлы журналов? Никуда не денешься: файлы журналов рассказывают о сервисах системы (демонах) и других программах, которые не имеют видимого пользователю интерфейса и не могут сами рассказать о своих действиях и ошибках. Файлы журналов – это записки демонов.

Например:

  1. Файлы журналов сообщат, насколько загружен сервер. Допустим, вам нужно выставить счет за его использование или понять, хорошо ли сервер работает как средство маркетинга или доставки данных. Журналы web-сервера особенно важны, и существует довольно много инструментов, позволяющих выдавать статистику на основе файлов журналов сервера Apache.
  2. Файлы журналов помогут выявить ошибки в настройках (например, неправильные настройки авторизации) или отсутствие файлов (например, ошибки типа ‘404 файл не найден’).
  3. Файлы журналов прояснят, почему сервис не желает правильно запускаться. Это особенно ценно при первом запуске приложения после изменений в настройке. Мудрые администраторы запускают tail -f на файле журнала (тогда можно просматривать файл по мере его роста) в одном окне терминала, а в другом запускают сервер.
  4. Файлы журналов расскажут, что кто-то норовит вломиться в вашу систему. Фактически, о любой машине, имеющей внешний видимый IP-адрес, можно утверждать, что кто-то пытается в нее проникнуть. Вопрос, преуспел ли этот кто-то? К примеру, журнал сервера под управлением автора содержит свыше 50000 строк, относящихся к попыткам проникновения – и это только за одну неделю!

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

Тонкости Syslogd

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

Некоторые сервисы, например, Apache, ведут свои собственные журналы. Другие – включая почту, печать, подсистему безопасности, Cron и ядро – делают записи с помощью отдельного демона, syslogd, обрабатывающего сообщения от их имени. Рассмотрим сначала метод syslog.

Отправляя записи через syslogd, сервисы не только передают тексты сообщений, но и указывают ‘источник’ (facility) и ‘уровень’ (level). Источник идентифицирует подсистему, от которой пришло сообщение, а уровень означает его важность. Syslog имеет файл настроек, определяющий, куда посылать то или иное сообщение, на основе его источника и уровня (как мы увидим, записи не обязательно направляются в журнал, хотя это их обычный путь).

Список источников включает auth, authpriv, cron, daemon, fpm kern, lpr, mail, news, syslog, user, uucp и от local0 до local7. Восемь источников local syslogd предоставляет для пользовательских нужд. Кому интересно, uucp означает ‘Unix to Unix copy’, это древний набор программ для удаленной передачи файлов и выполнения программ. Название также выдает возраст syslog: он начал использоваться с 1980-х. Существует восемь возможных уровней, начиная от щадящего до катастрофического, как показано в таблице «Уровни Syslog». (Описание каждого уровня является нашей интерпретацией). Между прочим, некоторые авторы используют термин ‘приоритет’, а не ‘уровень’, но большая часть документации по syslog использует термин ‘приоритет’ для обозначения комбинации источника и уровня. Будьте осторожны – возможны недоразумения.

Что происходит, когда сообщение доходит до syslogd? Это зависит от файла настройки, но возможны пять вариантов:

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

Мы скоро рассмотрим каждое из этих действий подробно. А сейчас займемся самым важным файлом настройки, /etc/syslog.conf, который связывает все вместе. Вот возможные варианты строк этого файла. Это не настоящие настройки, просто набор примеров для пояснения синтаксиса. Номера строк даны для удобства ссылки – в сам файл они не входят.

1    mail.err /var/log/mail
2    mail.* /var/log/mail
3    mail.debug /var/log/mail
4    *.crit /var/log/critical
5    *.* @loghost
6    mail.=debug /var/log/maildebug
7    mail.warn;cron.notice var/log/messages
8    *.*;auth.none /var/log/messages
9    auth,kern.crit /var/log/critical
10   *.*;auth,kern.none /var/log/messages
11   *.=debug;*.=info -/var/log/messages
12   *.crit root
13   *.crit *
14   *.=notice;*.=warn |/dev/xconsole

Каждое правило содержит селектор и действие. Так, в строке 1 селектором является mail.err. Это значит, что правило применяется к сообщениям от источника mail уровня err или выше; то есть уровни err, crit, alert или emerg. Затем идет действие – добавить сообщение в файл /var/log/mail. Легко, правда?

Правила бывают и посложнее. Селекторы допускают символы подстановки (*) как для источника, так и для уровня. Так, селектор в строке 2 означает ‘все сообщения от источника mail’ согласно принципу ‘от этого уровня и выше’, строка 3 делает то же самое. Селектор в строке 4 означает ‘сообщения уровня crit (или выше) от любого источника’, а строка 5, понятное дело, применяется ко всем сообщениям. Знак равенства (=) перед уровнем означает, что правило применимо только к этому уровню, поэтому правило в строке 6применимо сообщениям от источника mail только уровня debug. Можно указать несколько селекторов, разделив их точкой с запятой(;) как показано в строке 7 (такой же эффект достигается написанием двух отдельных правил). Пустой уровень none используется для исключения всех сообщений от данного источника и обычно используется вместе с ;, как показано в строке 8, соответствующей всем сообщениям, кроме идущих от источника auth.

Наконец, если надо, чтобы селектор включал несколько источников одного уровня, отделите имена источников запятой (,) как показано в строке 9. Между прочим, для сообщения вполне нормально соответ- ствовать более чем одному селектору – syslogd просто выполнит все предписанные действия, по очереди.

Предпринимаем действие

Как мы уже упомянули, чаще всего сообщения добавляются к файлу; вы просто определяете в качестве действия (абсолютный) путь к нему, как мы делали в наших примерах. Обычно syslogd сбрасывает свои буферы на диск после каждой записи. Это увеличивает шансы сообщения попасть в файл до того, как система рухнет, но это также значит, что менее критичные (и более объемные) сообщения уровней debug, info и notice вызывают излишнюю дисковую активность. Поставив дефис (-) перед именем файла, вы разрешите syslogd не сбрасывать буферы на диск каждый раз (см. строку 11). Можно попросить сообщение отобразиться на консоль любого подключенного пользователя (root является фаворитом), определив в качестве действия имя учетной записи, как в строке 12.

Здесь также применяется символ подстановки (*); действие в строке 13 означает ‘написать всем подключенным пользователям’. Во времена, когда системный администратор постоянно сидел в текстовой консоли (если такое вообще было), это имело значение, но настольные компьютеры работают в графическом режиме, а за серверами особо не присматривают. Вы можете заставить syslogd перенаправлять сообщения на удаленную машину, добавив знак @ перед именем машины, указанным в качестве действия; пример приведен в строке 5, но мы подробно рассмотрим его попозже.

Наконец, можно велеть syslogd записывать сообщения в именованный канал, поставив символ канала (|) перед его именем; пример – строка 14 (взятая из стандартного syslog.conf в Ubuntu).

Поэкспериментируем

В порядке иллюстрации, настроим syslogd так, чтобы он посылал все сообщения от источника local6 в файл /var/log/daemon. Для внесения изменений необходимо быть суперпользователем. Добавьте в файл syslog.conf строчку:

local6.notice   /var/log/demolog

Далее, из командной строки, пошлите syslogd сигнал SIGHUP, что- бы он перечитал файл.

# pkill -HUP syslogd

Для отправки сообщения в syslogd из командной строки служит команда logger. Вот типичный пример ее использования (опция -p указывает на источник и уровень сообщения):

# logger -p mail.info “Тестовое сообщение от источника mail”

Чтобы послать сообщение с созданным нами приоритетом local6.notice, выполните

# logger -p local6.notice “Это тест”

Теперь просмотрите файл /var/log/demolog. Там должна быть примерно такая строка:

Dec 27 10:38:38 frodo chris: Это тест

Вы увидите, что syslogd предварил сообщение некоторой информацией: в данном случае это отметка времени, имя машины и UID процесса, пославшего сообщение. Попробуйте записать сообщения от источника local6 с различными уровнями и проверить, какие уровни записываются.

Если посылать одно и тоже сообщение syslogd много раз подряд, то syslogd будет сохранять их раз в минуту и добавлять отметку вроде ‘last message repeated 22 times’ [«последнее сообщение повторялось 22 раза»] в конце каждого интервала времени. Это не дает демонам распоясаться и затопить файлы журналов потоком однотипных сообщений.

Персональные инструменты
купить
подписаться
Яндекс.Метрика