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

Материал из Linuxformat.

Ведение журналов 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 раза»] в конце каждого интервала времени. Это не дает демонам распоясаться и затопить файлы журналов потоком однотипных сообщений.

Централизация журналов

По умолчанию, syslogd прослушивает Unix-сокет /dev/log, то есть доступен только процессам на локальной машине. Однако он также может прослушивать и UDP-сокет, и, как мы уже видели, одним из действий syslog является перенаправление сообщения в syslogd на удаленной машине. Это позволяет централизовать подсистему журналирования в вашей сети, выделив одну машину полностью под работу с журналами, чтобы другие просто пересылали ей свои сообщения. У такого подхода есть несколько преимуществ. Первое, сбор журналов на одной машине упрощает их анализ. Второе, это более безопасно. Если журналы хранятся на машине локально, коварный нарушитель может отредактировать их и замести свои следы; а если журналы хранятся на другой машине, то до нее надо еще добраться.

Однако с точки зрения безопасности удаленное журналирование имеет и недостаток: уязвимость к атакам на отказ в обслуживании от тех, кто просто посылает лавину сообщений в syslogd, пока не забьет весь диск. Поэтому имеет смысл установить на узле, ведущем журнал, брандмауэр и принимать пакеты на порт syslog (UDP-порт 514) только из своей локальной сети.

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

Взгляд разработчика

Прежде чем покинем syslog, взглянем на журналирование с точки зрения разработчика демона (не путать с заклинателями демонов). Сообщения в syslogd легко посылать из программы на С.

#include <syslog.h>
 #include <fcntl.h>
 int main()
 {
    openlog(“mydaemon”, LOG_PID, LOG_LOCAL6);
    if (open(“/etc/xyzzy”, O_RDONLY) < 0) {
      syslog(LOG_NOTICE, “xyzzy: %m”);
    }
    return 0;
 }

Первый аргумент openlog – это идентификатор, который будет появляться во всех сообщениях (обычно имя демона); аргумент LOG_PID велит включать в сообщение идентификатор процесса демона, а последний аргумент указывает, что сообщения будут поступать от источника local6. (Эти символические константы определены в файле syslog.h.) Вызов syslog() посылает сообщение: первый аргумент – это уровень, а второй аргумент – строка в формате printf, определяющая оставшийся текст сообщения. В примере показан особый код формата – %m, он генерирует текст, описывающий последнюю ошибку – в данном случае, отказ вызова open() строкой выше. По выполнении программы, в нашем демо-журнале появится результирующая строка:

Dec 27 19:40:55 frodo mydaemon[22572]: xyzzy: No such file or directory

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

Путь Apache

Syslog – не единственный способ ведения журналов. Некоторые сервисы – в частности, Samba и Apache – делают все сами. Где находятся эти журналы и что именно в них пишется, определяется в собственном файле настройки сервиса. «Место жительства» файла настройки Apache варьируется от дистрибутива к дистрибутиву; в Fedora, например, это /etc/httpd/conf/htppd.conf.

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

ErrorLog /var/log/Apache/errorlog

Вы можете также попросить Apache вести журнал через syslogd, например:

ErrorLog syslog:local2

где local2 – источник, от имени которого будет вестись журнал syslog.

Директива LogLevel поможет вам управлять уровнем подробностей в журнале ошибок. Например,

LogLevel crit

– инструкция для журналирования сообщений уровня crit и выше. Список доступных уровней идентичен списку syslogd. Будьте осторожны при журналировании сервера предприятия: слишком подробное описание моментально заполнит ваш диск!

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

TransferLog /var/log/Apache/transferlog

На самом деле, Apache часто настраивается на ведение нескольких журналов передачи (по одному на виртуальный узел), но мы здесь ограничимся ситуациями попроще. Можно также направить ваш журнал в другую программу. Чаще всего это программа Rotatelogs, она периодически закрывает журнал и начинает новый. (Rotatelogs включе на в состав Apache. Не путайте ее с утилитой более общего назначения logrotate, которой мы займемся в следующий раз.) Директива, позволя ющая передать журнал в вашу программу через канал, выглядит так:

TransferLog “| rotatelogs”

Apache пишет журналы передач в формате, известном как «общий формат журналов» (common log format). Он широко поддерживается большинством web-серверов, инструментами анализа файлов журналов и рассмотрен во врезке «Разбор общего формата журналов», выше.

Еще один журнал, иногда оказывающийся полезным для диагностики – журнал X-сервера, обычно /var/log/Xorg.0.log. Этот файл переписывается каждый раз при перезапуске X-сервера. 0 в имени файла – это номер дисплея X-сервера, и если у вас в системе несколько мониторов, вы можете найти дополнительные файлы, относящиеся к разным дисплеям.

Наконец, существует собственный «поток сознания» ядра – сообщения, которые оно создает при загрузке. Они даже не записываются в файл (многие из них генерируются на ранней стадии процесса загрузки, до того, как станет доступна файловая система), а хранятся в памяти ядра – «кольцевом буфере [ring buffer]», который отображает команда dmesg. Некоторые дистрибутивы скидывают вывод dmesg в файл на поздних стадиях загрузки системы; например, Red Hat и Fedora пишут его в /var/log/dmesg. Большая часть этих сообщений создается модулями ядра при попытке определения и инициализации ассоциированного с ними оборудования, и они загадочны даже по стандартам Linux. Их внимательное изучение при случае поможет определить, распознается ли ваше оборудование, но для большей части сообщений dmesg есть два выхода: игнорировать их или отправить гуру для удаленной диагностики.

В следующий раз мы рассмотрим некоторые типичные журналы; а пока –

LXF91 14:41:54 from chris: конец руководства
LXF91 14:42:44 from chris: последнее сообщение повторилось 42 раза

Врезки

Шаг за шагом: Удаленное журналирование

1. Обновим файл настройки

Давайте сделаем так, чтобы сообщения приоритета local6.notice журналировались удаленно. Вам потребуется две Linux-системы (назовем их «машина A» и «машина B») и плитка шоколада. На машине A добавим запись в /etc/syslog.conf:

local6.notice @loghost

2. Добавим удаленный IP адрес

Все еще на машине А, добавим в /etc/hosts что-то наподобие

192.168.0.14 loghost

Подставьте сюда IP-адрес машины B.

3. Запустим pkill

Теперь прикажите syslogd перечитать файл настройки с помощью команды

# pkill -HUP syslogd

4. Настроим syslogd

На машине B надо удостовериться, что syslogd запущен с опцией -r так, чтобы он прослушивал UDP-порт. На системе с Fedora, например, потребуется отредактировать /etc/sysconfig/syslog, включив строку:

SYSLOGD_OPTIONS=”-m 0 -r”

5. Перезапустим демон

На машине B перезапустите syslogd. В Fedora или Red Hat это можно сделать командой

# service syslog restart

В Ubuntu, где нет sysconfig, понадобится отредактировать скрипт загрузки /etc/init.d/syslogd и добавить флаг -r в определение переменной Syslogd. Затем нужно ввести команду

# /etc/init.d/sysklogd restart

для перезапуска демона.

6. Проверим сокет

На машине B запустите команду netstat -au и проверьте, что на порте syslog открыт активный UDP-сокет.

7. Зададим местоположение

Далее отредактируйте /etc/syslog.conf, определив, куда должны идти сообщения от local6.notice. Например, добавьте строку

local6.notice /var/log/demolog

Все еще на машине B, прикажите syslogd перечитать файл, как вы сделали это на машине А в шаге 3.

8. Проверим соединение

Теперь все установлено. Проверьте настройку, запустив на машине А:

# logger -p local6.notice “Тестирование удаленного журналирования”

9. Убедимся, что оно работает

На машине В проверьте файл /var/log/demolog и убедитесь, что сообщение прибыло. Если да, поздравляем: удаленное журналирование готово! Если вы еще потихоньку не съели свой шоколад, можете сделать это сейчас. Нам он больше не понадобится. Заметим: если удаленное журналирование отказывается работать, проверьте, пропускает ли брандмауэр трафик syslogd на каждой из машин. В установках Linux по умолчанию он, скорее всего, заблокирован.

Разбор общего формата журналов

Syslog.conf парой слов