Учебное пособие для экзамена LPI 102, тема 111: Задачи администрирования

Страница 4 из 10  Опции документа Обсудить Выскажите мнение об этом учебном пособии Помогите нам улучшить содержание

Системные журналы

Этот раздел охватывает материал по теме 1.111.3 экзамена 102 Администрирование Linux для начинающих (LPIC-1). Рейтинг темы 3.

Из этого раздела вы узнаете, как конфигурировать и использовать системные журналы, включая решение следующих задач:

• Управление типом и уровнем журналируемой информации
• Автоматическая ротация и архивирование журналов
• Просмотр журналов с целью выявления повышенной активности
• Мониторинг журналов
• Обнаружение в журналах сообщений о проблемах

Управление типом и уровнем журналируемой информации

Функция системного журналирования в системе Linux обеспечивает системное журналирование и перехват сообщений ядра. Журналирование может осуществляться на локальной системе или пересылаться на удаленную систему, кроме того, в конфигурационном файле /etc/syslog.conf возможна тонкая регулировка уровня журналирования. Журналирование осуществляется при помощи демона syslogd, который обычно получает входную информацию при помощи сокета /dev/log, как показано в листинге 20.

                    
ian@pinguino:~$ ls -l /dev/log
srw-rw-rw- 1 root root 0 2007-07-05 15:42 /dev/log

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

Конфигурационный файл syslog.conf

Файл syslog.conf является главным конфигурационным файлом для демона syslogd. Журналирование базируется на сочетании facility (категория) и priority (приоритет). Существуют следующие категории: auth (или security), authpriv, cron, daemon, ftp, kern, lpr, mail, mark, news, syslog, user, uucp, а также с local0 по local7. Ключевое слово auth должно использоваться вместо security, а ключевое слово mark предназначено для внутреннего использования.

Приоритеты (в порядке возрастания):

1. debug
2. info
3. notice
4. warning (или warn)
5. err (или error)
6. crit
7. alert
8. emerg (или panic)

Ключевые слова, помещенные в скобки (warn, error и panic), сейчас признаны устаревшими.

Правила журналирования определяются записями в syslog.conf. Каждое правило имеет поле селектор и поле действие, которые разделены одним или более пробелами или символами табуляции. Поле селектор устанавливает категории и приоритеты, которые используют правило, а поле действие устанавливает журналируемое действие для категории и приоритетов. По умолчанию выбирается действие для определенного уровня и для всех более высоких уровней, хотя можно ограничить журналирование определенным уровнем. Каждый селектор состоит из категории и приоритета, разделенных точкой. Для данного действия могут быть определены несколько категорий, разделенных запятыми. Для данного действия могут быть определены несколько пар категория/приоритет, разделенных точкой с запятой. В листинге 21 показан пример несложного syslog.conf.

                    
# Log all kernel messages to the console.
# Logging much else clutters up the screen.
#kern.*                                                 /dev/console

# Log anything (except mail) of level info or higher.
# Don't log private authentication messages!
*.info;mail.none;authpriv.none;cron.none                /var/log/messages

# The authpriv file has restricted access.
authpriv.*                                              /var/log/secure

# Log all the mail messages in one place.
mail.*                                                  -/var/log/maillog

# Log cron stuff
cron.*                                                  /var/log/cron

# Everybody gets emergency messages
*.emerg                                                 *

# Save news errors of level crit and higher in a special file.
uucp,news.crit                                          /var/log/spooler

# Save boot messages also to boot.log
local7.*                                                /var/log/boot.log

Примечания:

• Как и во многих конфигурационных файлах, строки, начинающиеся с #, и пустые строки игнорируются.
• Символ * может использоваться для указания всех категорий или всех приоритетов.
• Специальное ключевое слово none указывает, что журналирование для этой категории не должно быть выполнено для этого действия.
• Дефис перед именем файла (как -/var/log/maillog в этом примере) указывает, что после каждой записи журнал не должен синхронизироваться. В случае аварии системы вы можете потерять информацию, но отключение синхронизации позволит повысить производительность.

В общем, действия упоминаются как "log-файлы", хотя они и не должны действительно быть файлами. В таблице 9 дается описание возможных типов log-файлов.

Можно поставить перед приоритетом знак !, чтобы показать, что действие не должно применяться, начиная с этого уровня и выше. Подобным образом, перед приоритетом можно поставить знак =, чтобы показать, что правило применяется только к этому уровню, или !=, чтобы показать, что правило применяется ко всем уровням, кроме этого. В листинге 22 показано несколько примеров, а страница руководства man для syslog.conf содержит множество других примеров.

                    
# Store all kernel messages in /var/log/kernel.
# Send critical and higher ones to remote host pinguino and to the console
# Finally, Send info, notice and warning messages to /var/log/kernel-info
#
kern.*                       /var/log/kernel
kern.crit                    @pinguino
kern.crit                    /dev/console
kern.info;kern.!err          /var/log/kernel-info

# Store all mail messages except info priority in /var/log/mail. 
mail.*;mail.!=info           /var/log/mail

В начало

Автоматическая ротация и архивирование журналов

При всем многообразии журналов вы должны иметь возможность контролировать их размер. Это делается при помощи команды logrotate, которая обычно выполняется демоном cron. Работа демона cron описана в этом пособии ниже в разделе Планирование задач. Главная цель команды logrotate состоит в том, чтобы периодически создавать резервные копии журналов и начинать новые журналы. Сохраняется несколько поколений журналов, и, когда завершается срок жизни журнала последнего поколения, он может быть заархивирован. Результат может быть отправлен по почте, например, ответственному за ведение архивов.

Для определения порядка ротации и архивирования журналов используется конфигурационный файл /etc/logrotate.conf. Для разных журналов можно задать разную периодичность, например, ежедневно, еженедельно или ежемесячно, кроме того, можно регулировать количество накапливаемых поколений, а также указать, будут ли копии архивов отправляться ответственному за ведение архивов и, если будут, когда. В листинге 23 показан пример файла /etc/logrotate.conf.

                    
# rotate log files weekly
weekly

# keep 4 weeks worth of backlogs
rotate 4

# create new (empty) log files after rotating old ones
create

# uncomment this if you want your log files compressed
#compress

# packages drop log rotation information into this directory
include /etc/logrotate.d

# no packages own wtmp, or btmp -- we'll rotate them here
/var/log/wtmp {
    missingok
    monthly
    create 0664 root utmp
    rotate 1
}

/var/log/btmp {
    missingok
    monthly
    create 0664 root utmp
    rotate 1
}

# system-specific logs may be configured here

Глобальные опции размещаются в начале файла logrotate.conf. Они используются по умолчанию, если где-то в другом месте не задано ничего более определенного. В нашем примере ротация журналов происходит еженедельно и резервные копии сохраняются в течение четырех недель. Как только производится ротация журнала, на месте старого журнала автоматически создается новый. Обратите внимание, что файл logrotate.conf может содержать спецификации из других файлов. Так, в него включаются все файлы из /etc/logrotate.d.

В этом примере также содержатся специальные правила для /var/log/wtmp и /var/log/btmp, ротация которых происходит ежемесячно. Если файлы отсутствуют, сообщение об ошибке не выдается. Создается новый файл и сохраняется только одна резервная копия.

В этом примере по достижении резервной копией последнего поколения она удаляется, поскольку не определено, что следует с ней делать.

Примечание: В файлы /var/log/wtmp и /var/log/btmp записываются удачные и неудачные попытки регистрации в системе соответственно. В отличие от большинства журналов, эти файлы не являются чисто текстовыми. Просмотреть их содержимое можно при помощи команд last или lastb. Подробную информацию от этих командах см. в их страницах руководства man.

Резервные копии журналов могут также создаваться, когда журналы достигают определенного размера, и могут быть созданы скрипты из наборов команд для выполнения до или после операции резервного копирования. В листинге 24 показан более сложный пример.

                    
       /var/log/messages {
           rotate 5
           mail logsave@pinguino
           size 100k
            postrotate
               /usr/bin/killall -HUP syslogd
           endscript
       }

В этом примере ротация /var/log/messages производится по достижении им размера 100 КБ. Накапливается пять резервных копий, и когда истекает срок жизни самой старой резервной копии, она отсылается по почте на адрес logsave@pinguino. Командное слово postrotate включает скрипт, перезапускающий демон syslogd после завершения ротации путем отправки сигнала HUP. Командное слово endscript необходимо для завершения скрипта, а также в случае, если имеется скрипт prerotate. Более полную информацию см. в страницах руководства man для logrotate.

В начало

Изучение и мониторинг журналов с целью выявления повышенной активности

Записи в журналах обычно содержат метку времени, имя хоста, на котором выполняется описываемый процесс, и имя процесса. В листинге 25 показано несколько строк из файла /var/log/messages, содержащих записи для gconfd, ntpd, init и yum.

                    
Jul  5 15:28:24 lyrebird gconfd (root-2832): Exiting
Jul  5 15:31:06 lyrebird ntpd[2063]: synchronized to 87.98.219.90, stratum 2
Jul  5 15:31:06 lyrebird ntpd[2063]: kernel time sync status change 0001
Jul  5 15:31:24 lyrebird init: Trying to re-exec init
Jul  5 15:31:24 lyrebird yum: Updated: libselinux.i386 2.0.14-2.fc7
Jul  5 15:31:24 lyrebird yum: Updated: libsemanage.i386 2.0.3-4.fc7
Jul  5 15:31:25 lyrebird yum: Updated: cups-libs.i386 1.2.11-2.fc7
Jul  5 15:31:25 lyrebird yum: Updated: libXfont.i386 1.2.9-2.fc7
Jul  5 15:31:27 lyrebird yum: Updated: NetworkManager.i386 0.6.5-7.fc7
Jul  5 15:31:27 lyrebird yum: Updated: NetworkManager-glib.i386 0.6.5-7.fc7

Просматривать журналы можно при помощи программы постраничного вывода, например, less, искать определенные записи (например, сообщения ядра от хоста lyrebird) можно при помощи команды grep, как показано в листинге 26.

                    
[root@lyrebird ~]# less /var/log/messages
[root@lyrebird ~]# grep "lyrebird kernel" /var/log/messages | tail -n 9
Jul  5 15:26:46 lyrebird kernel: Bluetooth: HCI socket layer initialized
Jul  5 15:26:46 lyrebird kernel: Bluetooth: L2CAP ver 2.8
Jul  5 15:26:46 lyrebird kernel: Bluetooth: L2CAP socket layer initialized
Jul  5 15:26:46 lyrebird kernel: Bluetooth: RFCOMM socket layer initialized
Jul  5 15:26:46 lyrebird kernel: Bluetooth: RFCOMM TTY layer initialized
Jul  5 15:26:46 lyrebird kernel: Bluetooth: RFCOMM ver 1.8
Jul  5 15:26:46 lyrebird kernel: Bluetooth: HIDP (Human Interface Emulation) ver 1.2
Jul  5 15:26:59 lyrebird kernel: [drm] Initialized drm 1.1.0 20060810
Jul  5 15:26:59 lyrebird kernel: [drm] Initialized i915 1.6.0 20060119 on minor 0

В начало

Мониторинг журналов

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

                    
[root@lyrebird ~]# tail -n 1 -f /var/log/messages
Jul  6 15:16:26 lyrebird syslogd 1.4.2: restart.
Jul  6 15:16:26 lyrebird kernel: klogd 1.4.2, log source = /proc/kmsg started.
Jul  6 15:19:35 lyrebird yum: Updated: samba-common.i386 3.0.25b-2.fc7
Jul  6 15:19:35 lyrebird yum: Updated: procps.i386 3.2.7-14.fc7
Jul  6 15:19:36 lyrebird yum: Updated: samba-client.i386 3.0.25b-2.fc7
Jul  6 15:19:37 lyrebird yum: Updated: libsmbclient.i386 3.0.25b-2.fc7
Jul  6 15:19:46 lyrebird gconfd (ian-3267): Received signal 15, shutting down cleanly
Jul  6 15:19:46 lyrebird gconfd (ian-3267): Exiting
Jul  6 15:19:57 lyrebird yum: Updated: bluez-gnome.i386 0.8-1.fc7

В начало

Обнаружение в журналах сообщений о проблемах

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

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

В начало

	Страница 4 из 10