Event log in linux

Администрирование систем Linux. Журналирование событий

Глава 17. Журналирование событий

В данной главе обсуждаются три отдельных вопроса.

Во-первых, рассматривается механизм журналирования входов в систему: обсуждаются способы получения информации о том, кто, когда и с какого узла осуществил вход в систему. Также рассматриваются способы получения информации о том, кому не удалось осуществить вход в систему, кто не смог воспользоваться утилитой su или ssh .

Во-вторых, рассматривается процесс настройки демона syslog, а также его тестирования с помощью утилиты logger .

Последняя часть главы в основном посвящена механизму ротации фалов журналов , а также содержит пояснения относительно использования команд tail -f и watch для отслеживания изменений файлов журналов .

17.1. Журналирование входов в систему

С целью облегчения процесса отслеживания входов пользователей в систему Linux может записывать необходимые данные в файлы журналов /var/log/wtmp , /var/log/btmp , /var/run/utmp и /var/log/lastlog .

17.1.1. Файл журнала /var/run/utmp (who)

Используйте утилиту who для просмотра содержимого файла /var/run/utmp. Эта утилита выводит информацию о пользователях, осуществивших вход в систему и в данный момент работающих с ней. Обратите внимание на то, что файл utmp находится в директории /var/run, а не /var/log.

17.1.2. Файл журнала /var/log/wtmp (last)

Содержимое файла журнала /var/log/wtmp обновляется силами программы login . Используйте утилиту last для просмотра содержимого файла журнала /var/run/wtmp.

Утилита last также может использоваться и для получения информации о последних перезагрузках.

17.1.3. Файл журнала /var/log/lastlog (lastlog)

Используйте утилиту lastlog для просмотра содержимого файла /var/log/lastlog.

17.1.4. Файл журнала /var/log/btmp (lastb)

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

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

Информация о попытках ввода некорректных паролей при использовании утилит ssh, rlogin или su не сохраняется в файле /var/log/btmp. В нем сохраняется исключительно информация о попытках ввода некорректного пароля при работе с терминалами.

17.1.5. Журналирование входов в систему с использованием утилит su и ssh

В зависимости от дистрибутива в файловой системе вашего компьютера вы также можете обнаружить файл /var/log/secure , который заполнен сообщениями от вспомогательных модулей auth и/или authpriv демона syslog. Этот файл журнала должен содержать информацию о неудачных попытках входа в систему с использованием утилиты su и/или ssh. В некоторых дистрибутивах данная информация сохраняется в файле /var/log/auth.log , поэтому следует проверить конфигурацию демона syslog.

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

17.2. Демон журналирования событий syslogd

17.2.1. О демоне syslogd

Стандартный метод журналирования событий в Linux связан с использованием демона syslogd . Демон syslogd был разработан Eric Allman для использования совместно с агентом передачи почты sendmail, но вскоре стал одним из множества стандартных приложений Unix, архитектура которого гораздо позднее была описана в рамках стандарта RFC 3164. Демон принимает сообщения от множества приложений (и системных утилит) по протоколу UDP на порту 514 и может дописывать сообщения в файлы журнала, выводить их, показывать сообщения в терминалах и передавать данные журнала другим демонам syslogd, работающим на других машинах. Конфигурация демона syslogd осуществляется с помощью файла /etc/syslog.conf .

17.2.2. О демоне rsyslogd

Новый демон журналирования событий носит имя rsyslogd (reliable and extended syslogd — надежный и расширяемый syslogd) и использует файл конфигурации /etc/rsyslogd.conf . Обратная совместимость синтаксиса данного файла конфигурации сохранена.

В каждой строке файла конфигурации используется идентификатор системы (facility) для определения источника сообщения. Также она содержит описание приоритета (priority) для определения важности сообщения и описание действия (action) для принятия решения о том, что нужно сделать с данным сообщением.

Новый демон rsyslog предоставляет много дополнительных возможностей, набор которых может быть расширен с помощью модулей. Модули позволяют, например, осуществлять экспорт сообщений из журнала syslog в базу данных.

Обратитесь к страницам руководств для получения дополнительной информации (после того, как вы закончите чтение данной главы).

17.2.4. Идентификаторы систем (facilities)

На странице руководства, доступной после исполнения команды man rsyslog.conf , можно найти информацию о различных стандартных идентификаторах систем для классификации сообщений от определенных демонов, таких, как mail, lpr, news и kern(el). Идентификаторы систем local0 и local7 могут использоваться для классификации сообщений от системных утилит (или любых подключенных к сети устройств, которые поддерживают механизм сообщений демона syslogd). Ниже приведен список всех идентификаторов систем из файла конфигурации rsyslog.conf версии 1.3. Ключевое слово security является устаревшим.

17.2.5. Описания приоритетов (priorities)

Наиболее важное сообщение может иметь описание приоритета emerg , вслед за которыми идут описания приоритетов alert и crit . Сообщения с наиболее низкими приоритетами имеют описания приоритетов info и debug . При указании минимального приоритета для журналирования сообщений будет осуществляться журналирование сообщений и с более высоким приоритетом. Вы можете использовать префикс = перед описанием приоритета для получения только тех сообщений, которые соответствуют этому описанию. Также вы можете использовать описание приоритета .none для предотвращения выполнения определенного действия при приеме любого сообщения с определенным идентификатором системы.

Ниже приведен список приоритетов в порядке возрастания. Ключевые слова warn, error и panic являются устаревшими.

17.2.6. Действия (actions)

Стандартным действием является отправка сообщения пользователю, имя которого записано в качестве действия. Если в качестве действия приводится строка с префиксом / , демон rsyslogd будет отправлять сообщение в файл (который может быть как обычным файлом, так и файлом устройства принтера или терминала). Префикс @ позволяет осуществлять отправку сообщения другому серверу с исполняющимся на нем демоном syslogd. Ниже приведен список всех возможных действий.

root,user1 передача сообщений пользователям с именами из списка, разделенными с помощью запятой

В дополнение вы можете использовать префикс — перед описаниями действий для исключения принудительной записи данных в файл на диске после журналирования каждого из событий.

Ниже приведен пример фрагмента файла конфигурации /etc/rsyslog.conf для обработки нестандартных сообщений с идентификатором системы local4.

17.2.8. Перезапуск демона rsyslogd

Не забудьте перезапустить демон после модификации его файла конфигурации.

17.3. Утилита logger

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

Результаты тестирования демона журналирования событий с помощью утилиты logger.

17.4. Просмотр журналов событий

Вы можете использовать команду tail -f для просмотра последних строк файла журнала. Параметр -f позволяет динамически выводить строки, которые добавляются в файл журнала в реальном времени.

Также вы можете автоматически повторять вызовы утилит, размещая перед ними вызов утилиты watch . Примером может служить следующая команда:

Данный подход аналогичен описанному выше, ведь в результате вывод утилиты who обновляется на экране через каждые две секунды.

17.5. Ротация журналов событий

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

Ниже приведено содержимое стандартного файла конфигурации logrotate.conf из состава дистрибутива Red Hat.

17.6. Практическое задание: журналирование событий

1. Выведите содержимое файла журнала /var/run/utmp с помощью специально предназначенной для этой цели утилиты (без использования утилиты cat или текстового редактора vi).

2. Выведите аналогичным образом содержимое файла журнала /var/log/wtmp.

3. Используйте утилиты lastlog и lastb и сделайте вывод о различии этих утилит.

4. Исследуйте файл конфигурации демона журналирования событий syslogd с целью выяснения пути к к файлу журнала событий, который содержит информацию о неудачных попытках удаленного входа в систему с помощью клиента ssh.

5. Настройте демон журналирования событий syslogd таким образом, чтобы сообщения с идентификатором системы и приоритетом local4.error и сообщения с более высокими приоритетами и этим же идентификатором системы размещались в файле журнала /var/log/l4e.log, а сообщения с идентификатором системы и исключительным приоритетом local4.info — в файле журнала /var/log/l4i.log. Проверьте корректность настройки с помощью утилиты logger!

6. Настройте демон журналирования событий syslogd таким образом, чтобы в файле журнала /var/log/Mysu.log размещались все сообщения, сгенерированные утилитой su в ходе получения привилегий пользователя root. Проверьте корректность настройки!

7. Настройте отправку сообщений с идентификатором системы local5 на сервер вашего соседа, на котором исполняется демон syslogd. Проверьте корректность настройки.

8. Разработайте сценарий, который будет вызывать утилиту logger для отправки сообщений с идентификатором системы local4 демону журналирования событий через каждые 15 секунд (текст сообщений должен отличаться). Используйте команду tail -f для отслеживания изменений ваших локальных файлов журналов событий.

17.7. Корректная процедура выполнения практического задания: журналирование событий

1. Выведите содержимое файла журнала /var/run/utmp с помощью специально предназначенной для этой цели утилиты (без использования утилиты cat или текстового редактора vi).

2. Выведите аналогичным образом содержимое файла журнала /var/log/wtmp.

3. Используйте утилиты lastlog и lastb и сделайте вывод о различии этих утилит.

lastlog : выводит информацию о последних входах пользователей в систему

lastb : выводит информацию о неудачных попытках входа в систему

4. Исследуйте файл конфигурации демона журналирования событий syslogd с целью выяснения пути к к файлу журнала событий, который содержит информацию о неудачных попытках удаленного входа в систему с помощью клиента ssh.

Дистрибутивы Ubuntu 9.10 и Debian Lenny переведены на использование демона журналирования событий rsyslog.

5. Настройте демон журналирования событий syslogd таким образом, чтобы сообщения с идентификатором системы и приоритетом local4.error и сообщения с более высокими приоритетами и этим же идентификатором системы размещались в файле журнала /var/log/l4e.log, а сообщения с идентификатором системы и исключительным приоритетом local4.info — в файле журнала /var/log/l4i.log. Проверьте корректность настройки с помощью утилиты logger!

6. Настройте демон журналирования событий syslogd таким образом, чтобы в файле журнала /var/log/Mysu.log размещались все сообщения, сгенерированные утилитой su в ходе получения привилегий пользователя root. Проверьте корректность настройки!

Данная директива позволит записывать в файл журнала событий не только данные, касающиеся использования утилиты su .

7. Настройте отправку сообщений с идентификатором системы local5 на сервер вашего соседа, на котором исполняется демон syslogd. Проверьте корректность настройки.

В дистрибутиве RHEL5 следует отредактировать файл /etc/sysconfig/syslog для активации режима приема сообщений от удаленных узлов.

В дистрибутиве RHEL7 следует раскомментировать две следующие строки файла /etc/rsyslog.conf для ‘приема сообщений syslog с использованием протокола UDP’.

В Debian/Ubuntu следует отредактировать файл /etc/default/syslog или /etc/default/rsyslog .

На клиентском компьютере:

8. Разработайте сценарий, который будет вызывать утилиту logger для отправки сообщений с идентификатором системы local4 демону журналирования событий через каждые 15 секунд (текст сообщений должен отличаться). Используйте команду tail -f для отслеживания изменений ваших локальных файлов журналов событий.

Источник

Использование journalctl для просмотра и анализа логов: подробный гайд

Journalctl — отличный инструмент для анализа логов, обычно один из первых с которым знакомятся начинающие администраторы linux систем. Встроенные возможности ротации, богатые возможности фильтрации и возможность просматривать логи всех systemd unit-сервисов одним инструментом очень удобны и заметно облегчают работу системным администраторам.

Эта статья рассматривает основные возможности утилиты journalctl и различные варианты ее применения. С помощью journalctl можно просматривать логи системы, чтобы решить возникшие проблемы на рабочей станции или сервере использующие дистрибутив linux с демоном инициализации systemd, де-факто уже ставшим стандартом в современных Linux-системах, например: RHEL, CentOS, Fedora, Debian и многих других.

Существует мнение, что systemd не так уж и хорош — он нагружает систему и это все еще предмет для споров на сегодняшний день, но нельзя отрицать, что он предоставляет прекрасный набор инструментов для управления системой и поиска проблем. Представьте, что вам приходится иметь дело с проблемным сервером, который даже не загружается — в таком случае можно загрузиться с live-дистрибутива, смонтировать системный раздел и просмотреть логи systemd, чтобы понять, в чем проблема.

Systemd

Systemd состоит из трех основных компонентов:

• systemd — менеджер системы и сервисов
• systemctl — утилита для просмотра и управление статусом сервисов
• systemd-analyze — предоставляет статистику по процессу загрузки системы, проверяет корректность unit-файлов и так же имеет возможности отладки systemd

Journald

Journald — системный демон журналов systemd. Systemd спроектирован так, чтобы централизованно управлять системными логами от процессов, приложений и т.д. Все такие события обрабатываются демоном journald, он собирает логи со всей системы и сохраняет их в бинарных файлах.

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

Файлы логов journald могут собирать тысячи событий и они обновляются с каждым новым событием, поэтому если ваша Linux-система работает достаточно долго — размер файлов с логами может достигать несколько гигабайт и более. Поэтому анализ таких логов может происходить с задержками, в таком случае, при анализе логов можно фильтровать вывод, чтобы ускорить работу.

Файл конфигурации journald

Файл конфигурации можно найти по следующему пути: /etc/systemd/journald.conf, он содержит различные настройки journald, я бы не рекомендовал изменять этот файл, если вы точно не уверены в том, что делаете.

Каталог с журналом journald располагается /run/log/journal (в том случае, если не настроено постоянное хранение журналов, но об этом позже).

Файлы хранятся в бинарном формате, поэтому нормально их просмотреть с помощью cat или nano, как привыкли многие администраторы — не получится.

Использование journalctl для просмотра и анализа логов

Основная команда для просмотра:

Она выведет все записи из всех журналов, включая ошибки и предупреждения, начиная с того момента, когда система начала загружаться. Старые записи событий будут наверху, более новые — внизу, вы можете использовать PageUp и PageDown чтобы перемещаться по списку, Enter — чтобы пролистывать журнал построчно и Q — чтобы выйти.

По умолчанию journalctl выводит время событий согласно настроенного в вашей системе часового пояса, также journalctl позволяет просмотреть логи с временем UTC (в этом стандарте времени сохраняются события внутри файлов journald), для этого можно использовать команду:

Фильтрация событий по важности

Система записывает события с различными уровнями важности, какие-то события могут быть предупреждением, которое можно проигнорировать, какие-то могут быть критическими ошибками. Если мы хотим просмотреть только ошибки, игнорируя другие сообщения, введем команду с указанием кода важности:
# journalctl -p 0

Для уровней важности, приняты следующие обозначения:

• 0: emergency (неработоспособность системы)
• 1: alerts (предупреждения, требующие немедленного вмешательства)
• 2: critical (критическое состояние)
• 3: errors (ошибки)
• 4: warning (предупреждения)
• 5: notice (уведомления)
• 6: info (информационные сообщения)
• 7: debug (отладочные сообщения)

Когда вы указываете код важности, journalctl выведет все сообщения с этим кодом и выше. Например если мы укажем опцию -p 2, journalctl покажет все сообщения с уровнями 2, 1 и 0.

Настройка хранения журналов

По умолчанию journald перезаписывает свои журналы логов при каждой перезагрузке, и вызов journalctl выведет журнал логов начиная с текущей загрузки системы.

Если необходимо настроить постоянное сохранение логов, потребуется отдельно это настроить, т.к. разработчики отказались от постоянного хранения всех журналов, чтобы не дублировать rsyslog.

Когда в конфигурационном файле /etc/systemd/journald.conf параметру Storage= задано значение auto) и каталога /var/log/journal/ не существует, журнал будет записываться в /run/log/journal без сохранения между перезагрузками, если /var/log/journal/ существует, журналы будут сохраняться в нем, на постоянной основе, но если каталог будет удален, systemd не пересоздаст его автоматически и вместо этого будет вести журнал снова в /run/systemd/journal без сохранения. Каталог может быть пересоздан в таком случае, если добавить Storage=persistent в journald.conf и перезапустить systemd-journald.service (или перезагрузиться).

Создадим каталог для хранения журналов, установим необходимые атрибуты и перезапустим службу:

Просмотр журналов загрузки

Если journald был настроен на постоянное хранение журналов, мы можем просматривать журналы логов по каждой отдельной загрузке, следующая команда выведет список журналов:

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

Следующие две даты, промежуток времени в течении которого в него записывались логи, это удобно если вы хотите найти логи за определенный период.

Например, чтобы просмотреть журнал начиная с текущего старта системы, можно использовать команду:

А для того, чтобы просмотреть журнал предыдущей загрузки:

Просмотр журнала за определенный период времени

Journalctl позволяет использовать такие служебные слова как “yesterday” (вчера), “today” (сегодня), “tomorrow” (завтра), или “now” (сейчас).

Поэтому мы можем использовать опцию «—since» (с начала какого периода выводить журнал).

С определенной даты и времени:

С определенной даты и по определенное дату и время:

Со вчерашнего дня:

С 9 утра и до момента, час назад:

Просмотр сообщений ядра

Чтобы просмотреть сообщения от ядра Linux за текущую загрузку, используйте команду с ключом -k:

Просмотр журнала логов для определенного сервиса systemd или приложения

Вы можете отфильтровать логи по определенному сервису systemd. Например, что бы просмотреть логи от NetworkManager, можно использовать следующую команду:

Если нужно найти название сервиса, используйте команду:

Так же можно просмотреть лог приложения, указав его исполняемый файл, например чтобы просмотреть все сообщения от nginx за сегодня, мы можем использовать команду:

Или указав конкретный PID:

Дополнительные опции просмотра

Следить за появлением новых сообщений (аналог tail -f):

Открыть журнал «перемотав» его к последней записи:

Если в каталоге с журналами очень много данных, то фильтрация вывода journalctl может занять некоторое время, процесс можно значительно ускорить с помощью опции —file, указав journalctl только нужный нам журнал, за которым мы хотим следить:

По умолчанию journalctl отсекает части строк, которые не вписываются в экран по ширине, хотя иногда перенос строк может оказаться более предпочтительным. Управление этой возможностью производится посредством переменной окружения SYSTEMD_LESS, в которой содержатся опции, передаваемые в less (программу постраничного просмотра, используемую по умолчанию). По умолчанию переменная имеет значение FRSXMK, если убрать опцию S, строки не будут обрезаться.

Ограничение размера журнала

Если journald настроен что бы сохранять журналы после перезагрузки, то по умолчанию размер журнала ограничен 10% от объема файлового раздела и максимально может занять 4 Гб дискового пространства.

Максимальный объем журнала можно скорректировать, раскомментировав и отредактировав следующий параметр в файле конфигурации journald:

Удаление журналов

Удалить файлы архивных журналов, можно вручную с помощью rm или использовав journalctl.

Удалить журналы, оставив только последние 100 Мб:

Удалить журналы, оставив журналы только за последние 7 дней:

Заключение

Служба журналирования логов journald очень мощный и гибкий инструмент, и если вы знаете как его использовать, он может сделать вашу жизнь намного проще во время поиска причин проблем с системой или ее сервисами.

Источник