Системные логи
Знакомство с syslogd

Демон syslogd обеспечиваетпродуманный клиент-серверный механиз записи сообщений от програм, запущенных в системе.Сервис syslog получает сообщения от демонов или программ, разделяя эти сообщения по приоритету и типу, в это же время записывая их согласно с правилами настроенными администратором.
Чтение логов

Давайте сразу перескочим к просмотру содержимого записанных syslog файлов. Позже мы сможем венуться к настройке syslog. Согласно стандарту иерархии фаловой системы (FHS, смотри вторую часть данного руководства) файлы логов расположены в /var/log. Здесь мы используем команду tail, чтобы просмотреть последние десять сообщений из файла:

# cd /var/log
# tail messages
Jan 12 20:17:39 bilbo init: Entering runlevel: 3
Jan 12 20:17:40 bilbo /usr/sbin/named[337]: starting BIND 9.1.3
Jan 12 20:17:40 bilbo /usr/sbin/named[337]: using 1 CPU
Jan 12 20:17:41 bilbo /usr/sbin/named[350]: loading configuration from '/etc/bind/named.conf'
Jan 12 20:17:41 bilbo /usr/sbin/named[350]: no IPv6 interfaces found
Jan 12 20:17:41 bilbo /usr/sbin/named[350]: listening on IPv4 interface lo, 127.0.0.1#53
Jan 12 20:17:41 bilbo /usr/sbin/named[350]: listening on IPv4 interface eth0, 10.0.0.1#53
Jan 12 20:17:41 bilbo /usr/sbin/named[350]: running
Jan 12 20:41:58 bilbo gnome-name-server[11288]: starting
Jan 12 20:41:58 bilbo gnome-name-server[11288]: name server starting

Вы можете помнить, что команда tail отображает последние строки из файла. В этом случает мы можем видеть, что сервер имён named был недавно запущен в системе, которая называется bilbo. Если мы развернули IPv6, мы могли бы заметить, что named не обнаружил интерфейса IPv6, что означало бы наличие проблемы. Дополнительно мы можем увидеть, что пользователь надавно запустил GNOME, что видно из присутствия gnome-name-server.

Tailing log files
Опытный системный администраор может использовать tail -f для следующего вывода лог файла, как это показано:

# tail -f /var/log/messages

Например в случае дебаггинга нашей теоретической проблемы с IPv6, запущенная выше команда в одном терминале, когда отстанавливается и запускается named, будет сразу отображать сообщения от этого демона. Это может быть полезной техникой при дебаггинге. Некоторые администраторы каждый раз оставляют запущенным tail -f в терминале, чтобы поглядывать на события в системе.
Фильтруем логи

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

# grep named /var/log/messages

Обзор логов

Следующие перечисленные лог файлы обычно могут быть найдены в /var/log и сохраняться с помощью syslog:

messages: Информационные и сообщения об ошибках от основных системных программ и демонов
secure: Сообщение об аутентификации и ошибках, созраняемые отдельно от messages для большей безопасности
maillog: Почтовые сообщение и ошибки
cron: Сообщение и ошибки от Cron
spooler: UUCP и новостные сообщения и ошибки

syslog.conf

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

facility: определяет подсистему, которая вызывает сообщение. Возможные значения для facility: auth, authpriv, cron, daemon, kern, lpr, mail, news, syslog, user, uucp и local0 through local7.

priority (приоритет) - определяет минимальный вес сообщения, в том смысле, что под это правило будут попадать сообщения с указанным или большим приоритетом. Допустимы следующие ключи: debug, info, notice, warning, err, crit, alert и emerg.

action: поле action может содержать люьое имя файла, консоли (такое как /dev/console), удаленную машину с префиксом @ , список пользователей через запятую, или отправлять сообщения всем залогининым пользователям. Наиболее популчрное значение action - это просто имя файла.
Перезагрузка и дополнительная информация

Надеюсь, этот обзор кофига поможет вам почувствовать себя увереннее при работе с системой syslog. Прежде чем вносить какие-либо изменения, стоит почитать syslog.conf(5) страницу руководства для более подробной информации. Также, syslogd(8) страница даст множество более подробной информации.

Стоит отметить, что необходимо оповещать демон syslog об изменениях в конфиге прежде чем они приступят в силу. Лучше это сделать отсылкой сигнала SIGHUP, который проще всего послать командой killall:

# killall -HUP syslogd

Примечание по безопасности. Стоит остерегаться автоматического создания лог-файлов программой syslog при их отсутствии, т.к. независимо от текущих настроек прав доступа в umask, файлы будут созданы читаемыми для всех (world-readable). Если вы беспокоитесь о безопасности, нужно установить разрешения(посредством chmod) на чтение-запись только суперпользователю. Кроме того, программа logrotate(описанная далее) может быть сконфигурирована для создания новых лог-файлов с подходящими правами доступа. Демон syslog всегда сохраняет текущие атрибуты существующего log-файла, так что не стоит об этом беспокоиться если файл уже был однажды создан.

logrotate. Лог-файлы в /var/log со временем растут и потенциально могут переполнить файловую систему. Целесообразно воспользоваться программой навроде logrotate чтобы управлять автоматическим архивированием логов. Logrotate обычно запускается как ежедневная задача планировщика cron, и может быть сконфигурирована чтобы чередовать, сжимать, удалять или посылать по почте log-файлы.

Например, по умолчанию logrotate может чередовать логи еженедельно, сохраняя 4 недели бэклогов (добавляя номер последовательности к имени файла), сжимая их (бэклоги) для сохранения места. Кроме того, программа может быть сконфигурирована чтобы посылать сигнал SIGHUP демону syslogd, так что-бы он заметил непустые лог-файлы и надлежащим образом к ним присоединился.

Для более подробной информации по logrotate, см. logrotate(8) страницу руководства, которая содержит описание программы и синтаксис конфигурационного файла.
Дополнение -- klogd

Прежде чем закончить рассмотрение syslog, хотелось-бы затронуть некоторые дополнительные вопросы для претенциозных читателей. Эти советы могут уберечь вас от некоторых бед, при попытке понять темы, связанные с syslog.

Во-первых демон syslog на самом деле - часть пакета syslogd, который также содержит второй демон klogd. Именно klogd отвечает за получение информационных сообщений и сообщений об ошибках из ядра, и передает их в syslogd для категоризации и журналирования. Сообщения, которые получает klogd точно такие-же как при выводе утилитой dmesg кольцевого буфера ядра. В то время как klogd передает сообщения в syslogd так, чтобы они не потерялись при перезаписи новых записей в кольце поверх старых (в следующем "витке" указателя буфера).
Дополнительные темы -- альтернативные логгеры.

Во вторых, существуют альтернативы стандартному пакету sysklogd. Они пытаются быть эффективнее, простыми в настройке, и возможно - более функциональными чем sysklogd. Syslog-ng и Metalog похоже самые популярные альтернативы; Их можно исследовать если syslogd покажется недостаточно мощным средством для ваших потребностей.

В третьих, в сценариях можно вести лог сообщений используя команду logger. Подробнее см. logger(1) в руководстве.

Внимание! Этот перевод, возможно, ещё не готов.
Его статус: перевод редактируется

Переведено на Нотабеноиде
http://notabenoid.org/book/24016/79543

Переводчики: Bomber, dk14