LXF91:Дневники демонов
|
|
|
Содержание |
Ведение журналов Syslog и его окрестности. Записки демонов
Учитесь правильно читать файлы журналов: они дают ценные данные о вашей системе. Д-р Крис Браун начинает серию руководств из двух частей с рассказа о syslogd
Не будем врать: файлы журналов, вероятно, скучнейшие из всех в Linux-системе. Они однообразны и нудны, и просматривать их – все равно что перематывать бесконечные видеозаписи службы безопасности в поисках чего-нибудь интересного. Вдобавок сообщения в журнале часто пишутся в расчете на разработчика, а не конечного пользователя, и понять их трудно. Логично спросить: зачем вообще смотреть файлы журналов? Никуда не денешься: файлы журналов рассказывают о сервисах системы (демонах) и других программах, которые не имеют видимого пользователю интерфейса и не могут сами рассказать о своих действиях и ошибках. Файлы журналов – это записки демонов.
Например:
- Файлы журналов сообщат, насколько загружен сервер. Допустим, вам нужно выставить счет за его использование или понять, хорошо ли сервер работает как средство маркетинга или доставки данных. Журналы web-сервера особенно важны, и существует довольно много инструментов, позволяющих выдавать статистику на основе файлов журналов сервера Apache.
- Файлы журналов помогут выявить ошибки в настройках (например, неправильные настройки авторизации) или отсутствие файлов (например, ошибки типа ‘404 файл не найден’).
- Файлы журналов прояснят, почему сервис не желает правильно запускаться. Это особенно ценно при первом запуске приложения после изменений в настройке. Мудрые администраторы запускают tail -f на файле журнала (тогда можно просматривать файл по мере его роста) в одном окне терминала, а в другом запускают сервер.
- Файлы журналов расскажут, что кто-то норовит вломиться в вашу систему. Фактически, о любой машине, имеющей внешний видимый 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.
- Метамодернизм в позднем творчестве В.Г. Сорокина
- ЛитРПГ - последняя отрыжка постмодерна
- "Ричард III и семиотика"
- 3D-визуализация обложки Ridero создаем обложку книги при работе над самиздатом.
- Архитектура метамодерна - говоря о современном искусстве, невозможно не поговорить об архитектуре. В данной статье будет отмечено несколько интересных принципов, характерных для построек "новой волны", столь притягательных и скандальных.
- Литература
- Метамодерн
- Рокер-Прометей против изначального зла в «Песне про советскую милицию» Вени Дркина, Автор: Нина Ищенко, к.ф.н, член Союза Писателей ЛНР - перепубликация из журнала "Топос".
- Как избавиться от комаров? Лучшие типы ловушек.
- Что делать если роблокс вылетает на windows
- Что делать, если ребенок смотрит порно?
- Почему собака прыгает на людей при встрече?
- Какое масло лить в Задний дифференциал (мост) Visco diff 38434AA050
- О чем может рассказать хвост вашей кошки?
- Верветки
- Отчетность бюджетных учреждений при закупках по Закону № 223-ФЗ
- Срок исковой давности как правильно рассчитать
- Дмитрий Патрушев минсельхоз будет ли преемником Путина
- Кто такой Владислав Поздняков? Что такое "Мужское Государство" и почему его признали экстремистским в России?
- Как правильно выбрать машинное масло в Димитровграде?
- Как стать богатым и знаменитым в России?
- Почему фильм "Пипец" (Kick-Ass) стал популярен по всему миру?
- Как стать мудрецом?
- Как правильно установить FreeBSD
- Как стать таким как Путин?
- Где лучше жить - в Димитровграде или в Ульяновске?
- Почему город Димитровград так называется?
- Что такое метамодерн?
- ВАЖНО! Временное ограничение движения автотранспортных средств в Димитровграде
- Тарифы на электроэнергию для майнеров предложено повысить
Наконец, если надо, чтобы селектор включал несколько источников одного уровня, отделите имена источников запятой (,) как показано в строке 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 парой слов
