Linux Fundamentals, Part 4 / Основы Linux от основателя Gentoo. Часть 4: System logs

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

Bomber 04.12.11 в 11:21

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

Bomber 04.12.11 в 11:26

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

Bomber 04.12.11 в 11:30

# 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

Bomber 04.12.11 в 11:30

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

Bomber 04.12.11 в 11:37

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

Bomber 04.12.11 в 11:39

# tail -f /var/log/messages

Bomber 04.12.11 в 11:39

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

Bomber 04.12.11 в 11:44

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

Bomber 04.12.11 в 11:46

# grep named /var/log/messages

Bomber 04.12.11 в 11:46

Обзор логов

Bomber 04.12.11 в 11:46

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

Bomber 04.12.11 в 11:48

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

Bomber 04.12.11 в 11:50

syslog.conf

Bomber 04.12.11 в 11:51

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

Bomber 04.12.11 в 13:16

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

Bomber 04.12.11 в 13:18

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

Bomber 04.12.11 в 13:21

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

Bomber 04.12.11 в 13:25

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

dk14 04.12.11 в 14:12

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

dk14 04.12.11 в 14:15

# killall -HUP syslogd

dk14 04.12.11 в 13:53

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

dk14 04.12.11 в 14:33

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

dk14 04.12.11 в 15:10

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

dk14 04.12.11 в 15:15

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

dk14 04.12.11 в 13:55

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

dk14 04.12.11 в 13:41

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

dk14 04.12.11 в 13:52

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

dk14 04.12.11 в 13:34

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

dk14 04.12.11 в 13:29