Centos журнал ошибок

Время на прочтение
6 мин

Количество просмотров 116K

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 для просмотра и анализа логов

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

# journalctl

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

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

# journalctl --utc

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

Система записывает события с различными уровнями важности, какие-то события могут быть предупреждением, которое можно проигнорировать, какие-то могут быть критическими ошибками. Если мы хотим просмотреть только ошибки, игнорируя другие сообщения, введем команду с указанием кода важности:
# 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 (или перезагрузиться).

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

# mkdir /var/log/journal
# systemd-tmpfiles --create --prefix /var/log/journal
# systemctl restart systemd-journald

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

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

# journalctl --list-boots

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

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

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

# journalctl -b 0

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

# journalctl -b -1

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

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

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

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

# journalctl --since "2020-12-18 06:00:00"

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

# journalctl --since "2020-12-17" --until "2020-12-18 10:00:00

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

# journalctl --since yesterday

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

# journalctl --since 09:00 --until "1 hour ago"

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

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

# journalctl -k

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

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

# journalctl -u NetworkManager.service

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

# systemctl list-units --type=service

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

# journalctl /usr/sbin/nginx --since today

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

# journalctl _PID=1

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

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

# journalctl -f

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

# journalctl -e

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

journalctl --file /var/log/journal/e02689e50bc240f0bb545dd5940ac213/system.journal -f

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

Например:

SYSTEMD_LESS=FRXMK journalctl

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

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

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

SystemMaxUse=50M

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

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

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

# journalctl --vacuum-size=100M

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

# journalctl --vacuum-time=7d

Заключение

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

Анализ логов является важной задачей системного администратора. Если что-то идет не так в системе Linux, ответ часто находится в логах. На CentOS 7 две разные системы логирования используются бок о бок, и важно знать, как и где найти информацию. Эта статья научит вас всему этому. Вы узнаете, как читать логи, настраивать rsyslogd и journald, а также как настроить свою систему на ротацию логов, чтобы предотвратить полное заполнение дисков службами, которые регистрируют события в этих самых логах.

Понимание логирования

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

• Прямая запись: некоторые сервисы записывают информацию напрямую в лог-файлы, даже некоторые важные сервисы, такие как веб-сервер Apache и файловый сервер Samba.
• rsyslogd: rsyslogd — это усовершенствование сервиса syslogd, который занимается централизованным управлением лог-файлов. Syslogd существует уже давно.
• journald: с введением systemd также был представлен сервис логирования journald. Этот сервис тесно интегрирован с systemd, что позволяет администраторам читать подробную информацию из journald, одновременно отслеживая состояние сервиса с помощью команды systemctl status.

Понимание ролей rsyslogd и journald

journald (который реализуется демоном systemd-journald) предоставляет усовершенствованную систему управления логами. journald собирает сообщения из ядра, всей процедуры загрузки и сервисов и записывает эти сообщения в журнал событий. Этот журнал событий хранится в двоичном формате, и его можно запросить с помощью команды journalctl.

Поскольку журнал, который пишет journald, не является постоянным между перезагрузками, сообщения также перенаправляются в службу rsyslogd. rsyslogd записывает сообщения в разные файлы в каталоге /var/log.

rsyslogd предлагает функции, которых нет в journald, такие как централизованное ведение журнала и фильтрация сообщений с использованием модулей. В текущем состоянии journald не является заменой rsyslogd; это просто еще один способ регистрации информации. journald тесно интегрирован с systemd и поэтому регистрирует всё, что делает ваш сервер. rsyslogd добавляет к нему некоторые сервисы. В частности, он заботится о записи данных журнала в определенные файлы (которые будут постоянными между перезагрузками) и позволяет настраивать удаленные журналы и серверы журналов.

Чтобы получить больше информации о том, что происходит на машине, администраторы должны использовать три подхода:

• Файлы в /var/log, которые пишутся rsyslogd, должны контролироваться.
• Команда journalctl может использоваться для получения более подробной информации из журнала.
• Для краткого обзора последних значимых событий, которые были зарегистрированы модулями systemd через journald, администраторы могут использовать команду systemctl status <unit>. Эта команда показывает состояние сервисов, а также последние пару строк, которые были логированы. В листинге 1 показан пример, в котором эта команда четко указывает, что пошло не так при запуске сервиса.

Листинг 1

[root@server1 ~]# systemctl status httpd
httpd.service - The Apache HTTP Server
Loaded: loaded (/usr/lib/systemd/system/httpd.service; disabled)
Active: failed (Result: exit-code) since Fri 2019-10-25 05:25:18
PDT; 2s ago
Process: 2893 ExecStop=/bin/kill -WINCH ${MAINPID} (code=exited,
status=0/SUCCESS)
Process: 2890 ExecStart=/usr/sbin/httpd $OPTIONS -DFOREGROUND
(code=exited, status=1/FAILURE)
Main PID: 2890 (code=exited, status=1/FAILURE)
Oct 25 05:25:18 server1.example.com httpd[2890]: (13)Permission
denied: AH00072: make_sock: could not bind to address [::]:443
Oct 25 05:25:18 server1.example.com httpd[2890]: (13)Permission
denied: AH00072: make_sock: could not bind to address 0.0.0.0:443
Oct 25 05:25:18 server1.example.com httpd[2890]: no listening sockets
available, shutting down
Oct 25 05:25:18 server1.example.com httpd[2890]: AH00015: Unable to
open logs
Oct 25 05:25:18 server1.example.com systemd[1]: httpd.service: main
process exited, code=exited, status=1/FAILURE
Oct 25 05:25:18 server1.example.com systemd[1]: Failed to start The
Apache HTTP Server.
Oct 25 05:25:18 server1.example.com systemd[1]: Unit httpd.service
entered failed state.

Чтение лог-файлов

Помимо сообщений, которые записываются journald и которые можно прочитать с помощью команды journalctl, в системе Linux вы также найдете различные лог-файлы в каталоге /var/log. Эти файлы могут быть прочитаны, например, с помощью less.

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

В таблице 1 представлен обзор некоторых стандартных файлов, созданных в этом каталоге.

Таблица 1

Понимание содержимого лог-файла

Как администратор, вы должны уметь интерпретировать содержимое лог-файлов. Например, в листинге 2 показан частичный контент из файла /var/log/messages.

Листинг 2

[root@kvm ~]# tail -n 20 /var/log/messages
Oct 31 22:05:56 kvm journal: g_array_unref: assertion 'array' failed
Oct 31 22:06:09 kvm dhclient[24837]: DHCPDISCOVER on em1 to 255.255.255.255 port 67 interval 15 (xid=0x278ccc34)
Oct 31 22:06:24 kvm dhclient[24837]: DHCPDISCOVER on em1 to 255.255.255.255 port 67 interval 16 (xid=0x278ccc34)
Oct 31 22:06:26 kvm NetworkManager[2577]: <warn>  [1572523586.5185] dhcp4 (em1):request timed out
Oct 31 22:06:26 kvm NetworkManager[2577]: <info>  [1572523586.5186] dhcp4 (em1):state changed unknown -> timeout
Oct 31 22:06:26 kvm NetworkManager[2577]: <info>  [1572523586.5270] dhcp4 (em1):canceled DHCP transaction, DHCP client pid 24837
Oct 31 22:06:26 kvm NetworkManager[2577]: <info>  [1572523586.5270] dhcp4 (em1):state changed timeout -> done
Oct 31 22:06:26 kvm NetworkManager[2577]: <info>  [1572523586.5274] device (em1): state change: ip-config -> failed (reason 'ip-config-unavailable', sys-iface-state: 'managed')
Oct 31 22:06:26 kvm NetworkManager[2577]: <warn>  [1572523586.5284] device (em1): Activation: failed for connection 'Wired connection 1'
Oct 31 22:06:26 kvm NetworkManager[2577]: <info>  [1572523586.5288] device (em1): state change: failed -> disconnected (reason 'none', sys-iface-state: 'managed')
Oct 31 22:06:26 kvm avahi-daemon[2499]: Withdrawing address record for fe80::6bbe:cb13:850c:d799 on em1.
Oct 31 22:06:41 kvm journal: g_array_unref: assertion 'array' failed
Oct 31 22:10:01 kvm systemd: Created slice User Slice of root.
Oct 31 22:10:01 kvm systemd: Started Session 413 of user root.
Oct 31 22:10:01 kvm systemd: Removed slice User Slice of root.
Oct 31 22:10:08 kvm systemd-logind: New session 414 of user admin.
Oct 31 22:10:08 kvm systemd: Started Session 414 of user admin.
Oct 31 22:10:08 kvm dbus[2512]: [system] Activating service name='org.freedesktop.problems' (using servicehelper)
Oct 31 22:10:08 kvm dbus[2512]: [system] Successfully activated service 'org.freedesktop.problems'
Oct 31 22:10:15 kvm su: (to root) admin on pts/11

Как видно из листинга 2, каждая записываемая строка имеет определенные элементы:

• Дата и время: каждое сообщение начинается с отметки времени. В целях фильтрации метка времени записывается как военное время.
• Хост: хост, с которого отправлено сообщение. Это важно, потому что rsyslogd также может быть настроен для обработки удаленных логов.
• Имя службы или процесса: имя сервиса или процесса, сгенерировавшего сообщение.
• Содержимое сообщения: содержимое сообщения, которое содержит точное сообщение, которое было зарегистрировано.

Чтобы прочитать содержимое лог-файла, вы можете использовать, например less, или вы можете в реальном времени наблюдать за тем, что там происходит с помощью команды tail -f. Например: tail -f /var/log/messages.

Команда logger

Большинство сервисов самостоятельно записывают информацию в лог-файлы. Команда logger позволяет пользователям записывать сообщения в rsyslog из командной строки. Использовать эту команду просто. Просто введите logger, и затем сообщение, которое вы хотите записать в логи. Таким образом, утилита logger предлагает удобное решение для написания сообщений из скриптов. Это позволит вам записывать скрипт в syslog, если что-то пойдёт не так.

При использовании logger вы также можете указать приоритет и что вы хотите логировать. Команда logger -p kern.err my_message записывает my_message в объект kern, например, используя приоритет error. Эта опция позволит проверить работу конкретных rsyslog объектов.

Настройка rsyslogd

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

Секции rsyslog.conf

Файл rsyslog.conf используется для указания того, что должно быть зарегистрировано и где это должно быть зарегистрировано. Для этого вы найдете различные разделы в файле конфигурации:

■ #### MODULES ####: rsyslogd является модульным. Модули включены для улучшения поддерживаемых функций в rsyslogd.

■ #### GLOBAL DIRECTIVES ####: Этот раздел используется для указания глобальных параметров, таких как место, где записываются вспомогательные файлы, или формат метки времени по умолчанию.

■ #### RULES ####: Это самая важная часть файла rsyslog.conf. Он содержит правила, которые определяют, какая информация должна быть залогирована и в каком месте.

Объекты, приоритеты, и места назначения

Чтобы указать, какая информация должна логироваться и в каком месте назначения, rsyslogd использует объект (Facility), приоритет (Priority) и место назначения (Destination):

■ Объект определяет категорию информации, которая логируется. Rsyslogd использует фиксированный список объектов, который не может быть расширен. Это связано с обратной совместимостью с устаревшей службой syslog.

■ Приоритет используется для определения серьезности сообщения, которое необходимо залогировать.
При указании приоритета по умолчанию с таким приоритетом логируются все сообщения, а так же все сообщения с приоритетом выше текущего.

■ Назначение определяет, куда должно быть записано сообщение. Типичными адресатами являются файлы, но модули rsyslog также могут использоваться в качестве места назначения для дальнейшей обработки через модуль rsyslogd.

В листинге 3 приведен пример раздела RULES в rsyslog.

Листинг 3

#### RULES ####

# 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                                                 :omusrmsg:*

# 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

В листинге 3 вы можете увидеть, как различные объекты и приоритеты используются для определения местоположений, в которые можно логировать информацию. Доступные объекты и приоритеты являются фиксированными и не могут быть добавлены. Таблица 2 показывает, какие объекты доступны, а таблица 3 показывает список всех приоритетов.

При указании назначения часто используется файл. Если имя файла начинается с дефиса (как -/var/log/maillog), сообщения не будут немедленно переданы в файл, а будут буферизированы для повышения эффективности записи. Файлы устройств также могут быть использованы, как /dev/console. Если используется устройство, сообщения записываются в режиме реального времени на консоль. На современных серверах это не имеет смысла, поскольку администраторы часто входят в систему удаленно и не видят, что происходит на консоли сервера.

Для расширения функциональности rsyslogd могут использоваться модули для дальнейшей обработки сообщений. Если это требуется, имя модуля может быть указано как :имя_модуля:.

Таблица 2

Объекты syslog были определены в 1980-х годах, и для обеспечения обратной совместимости никакие новые объекты не могут быть добавлены. В результате все еще существуют некоторые объекты, которые в основном больше не используются, а некоторые сервисы, которые стали актуальными на более позднем этапе, не имеют своего собственного объекта. Как решение, два конкретных типа объекта могут быть использованы. Объект daemon — это общий объект, который может использоваться любым демоном. И могут быть использованы объекты local0 — local7.

Если есть сервисы, которые не имеют своих собственных объектов rsyslogd, которым необходимо в любом случае записывать сообщения в определенный лог-файл, эти сервисы можно настроить для использования любого из объектов от local0 до local7. Затем вы должны настроить сервисы для использования этих объектов. Процедура, которой вы пользуетесь, зависит от используемого вами сервиса. Затем вам нужно добавить правило в файл rsyslog.conf, чтобы отправлять сообщения, поступающие через этот объект, в определенный флог-файл. Упражнение 2 показывает, как вы можете это сделать.

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

Таблица 3

Когда используется определенный приоритет, все сообщения с этим приоритетом и выше логируются в соответствии со спецификациями, используемыми в этом конкретном правиле. Если вам необходимо детально настроить логирование, когда сообщения с разными приоритетами отправляются в разные файлы, вы можете указать приоритет со знаком равенства (=) перед ним, как в следующем файле конфигурации, который будет отправлять все отладочные сообщения cron в файл с именем /var/log/cron.debug. Обратите внимание на использование дефиса (-) перед именем файла, который гарантирует, что сообщения буферизуются и не записываются немедленно на диск (что хорошо для производительности диска).

Рассмотрим следующую строку, где все сообщения cron только с приоритетом отладки записываются в определенный файл. Обратите внимание на — перед строкой, который буферизует записи, чтобы информация логировалась более эффективным способом:

cron.=debug                     -/var/log/cron.debug

Нет необходимости учить наизусть названия rsyslogd  объектов и приоритетов. Все они перечислены в man 5 rsyslog.conf.

Упражнение 2. Изменение правил в rsyslog.conf
В этом упражнении вы узнаете, как изменить rsyslog.conf. Вы настроите сервис Apache для логирования сообщений через syslog и создадите правило, которое записывает сообщения отладки в определенный файл.

1. По умолчанию сервис Apache не логируется через rsyslog, но ведет собственное логирование. Вы измените это. Для начала установите Apache командой yum install -y httpd.

2. После установки Apache откройте его файл конфигурации /etc/http/conf/httpd.conf и добавьте в него следующую строку:

ErrorLog    syslog:local1

3. Введите systemctl restart httpd.

4. Теперь создайте строку в файле rsyslog.conf, которая будет отправлять все сообщения, которые он получает для объекта local1 (который теперь используется сервисом httpd), в файл /var/log/httpd-error.log. Для этого включите следующую строку:

local1:error                    -/var/log/httpd-error.log

5. Скажите rsyslogd перезагрузить его конфигурацию, выполнив команду systemctl restart httpd.

6. Все сообщения об ошибках Apache теперь будут записываться в файл httpd-error.log.

7. В браузере Firefox перейдите по адресу http://localhost/nowhere. Так как страницы, к которой вы пытаетесь получить доступ, не существует, она будет записана в журнал ошибок Apache.

8. Теперь давайте создадим snap-in файл, который также записывает сообщения отладки в определенный файл. Для этого введите echo «*.debug /var/log/messages/messages-debug» > /etc/rsyslogd/debug.conf.

9. Снова перезапустите rsyslogd с помощью systemctl restart rsyslogd.

10. Выполните tail -f /var/log/messages-debug, чтобы открыть трассировку для вновь созданного файла.

11. Введите logger -p daemon.debug «Daemon Debug Message». Вы увидите сообщение отладки.

Ротация лог-файлов

Чтобы syslog сообщения не заполняли вашу систему, сообщения можно ротировать. Это означает, что когда будет достигнут определенный порог,
старый лог-файл закроется и откроется новый. Утилита logrotate периодически запускается через сервис crond, чтобы позаботиться о ротации лог-файлов.

Когда лог-файл ротируется, старый файл копируется в файл с датой ротации. Таким образом, если /var/log/messages ротируется 3 ноября 2019 года, то ротируемое имя файла будет /var/log/messages-20191103. По умолчанию в системе хранятся четыре старых лог-файлов. Файлы старше этого периода удаляются из системы автоматически.

ВНИМАНИЕ! Лог-файлы, которые были ротированы, нигде не хранятся; они просто исчезают. Если политика вашей компании требует от вас доступа к информации о событиях, которые произошли более 5 недель назад, вам следует принять меры. Вы можете либо создать резервную копию лог-файлов, либо настроить сервер логов, где logrotate хранит ротированные сообщения в течение значительно более длительного периода.

Настройки по умолчанию для ротации логов хранятся в файле /etc/logrotate.conf

[root@kvm ~]# cat /etc/logrotate.conf
# see "man logrotate" for details
# rotate log files weekly
weekly

# keep 4 weeks worth of backlogs
rotate 4

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

# use date as a suffix of the rotated file
dateext

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

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

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

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

# system-specific logs may be also be configured here.
[root@kvm ~]#

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

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

Работаем с journald

Сервис systemd-journald хранит лог-сообщения в журнале в двоичном виде, который хранится в файле /run/log/journal. Этот файл можно просмотреть с помощью команды journalctl.

Использование journalctl для поиска событий

Самый простой способ использовать journalctl — просто набрать команду. Он показывает последние события, которые были записаны в журнал с момента последнего запуска вашего сервера. Обратите внимание, что результат этой команды отображается в меньшем количестве страниц, и по умолчанию вы увидите начало журнала.

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

Вы также можете ввести journalctl и нажать кнопку G (заглавная буква) , чтобы перейти к концу журнала. Также обратите внимание, что в выводе journalctl работают параметры поиска / и ?. В листинге 4 показан частичный вывод journalctl.

Листинг 4

Nov 03 13:39:03 kvm NetworkManager[2577]: <info>  [1572752343.5648] device (em2): state change: config -> ip-config (reason 'none', sys
Nov 03 13:39:03 kvm NetworkManager[2577]: <info>  [1572752343.5652] dhcp4 (em2): activation: beginning transaction (timeout in 45 secon
Nov 03 13:39:03 kvm NetworkManager[2577]: <info>  [1572752343.5672] dhcp4 (em2): dhclient started with pid 23750
Nov 03 13:39:03 kvm avahi-daemon[2499]: Registering new address record for fe80::8cce:3bf7:7f8b:9335 on em2.*.
Nov 03 13:39:03 kvm dhclient[23750]: DHCPDISCOVER on em2 to 255.255.255.255 port 67 interval 7 (xid=0x48a6ece5)
Nov 03 13:39:10 kvm dhclient[23750]: DHCPDISCOVER on em2 to 255.255.255.255 port 67 interval 12 (xid=0x48a6ece5)
Nov 03 13:39:18 kvm gnome-shell[3798]: g_array_unref: assertion 'array' failed
Nov 03 13:39:22 kvm dhclient[23750]: DHCPDISCOVER on em2 to 255.255.255.255 port 67 interval 20 (xid=0x48a6ece5)
Nov 03 13:39:42 kvm dhclient[23750]: DHCPDISCOVER on em2 to 255.255.255.255 port 67 interval 18 (xid=0x48a6ece5)
Nov 03 13:39:48 kvm NetworkManager[2577]: <warn>  [1572752388.5190] dhcp4 (em2): request timed out
Nov 03 13:39:48 kvm NetworkManager[2577]: <info>  [1572752388.5191] dhcp4 (em2): state changed unknown -> timeout
Nov 03 13:39:48 kvm NetworkManager[2577]: <info>  [1572752388.5281] dhcp4 (em2): canceled DHCP transaction, DHCP client pid 23750
Nov 03 13:39:48 kvm NetworkManager[2577]: <info>  [1572752388.5281] dhcp4 (em2): state changed timeout -> done
Nov 03 13:39:48 kvm NetworkManager[2577]: <info>  [1572752388.5284] device (em2): state change: ip-config -> failed (reason 'ip-config-
Nov 03 13:39:48 kvm NetworkManager[2577]: <warn>  [1572752388.5291] device (em2): Activation: failed for connection 'Wired connection 2
Nov 03 13:39:48 kvm NetworkManager[2577]: <info>  [1572752388.5295] device (em2): state change: failed -> disconnected (reason 'none',
Nov 03 13:39:48 kvm avahi-daemon[2499]: Withdrawing address record for fe80::8cce:3bf7:7f8b:9335 on em2.
Nov 03 13:40:01 kvm systemd[1]: Created slice User Slice of root.
Nov 03 13:40:01 kvm systemd[1]: Started Session 867 of user root.
Nov 03 13:40:01 kvm CROND[23918]: (root) CMD (/usr/lib64/sa/sa1 1 1)
Nov 03 13:40:01 kvm systemd[1]: Removed slice User Slice of root.
Nov 03 13:40:03 kvm gnome-shell[3798]: g_array_unref: assertion 'array' failed
Nov 03 13:41:12 kvm dnsmasq-dhcp[3529]: DHCPREQUEST(virbr1) 192.168.122.208 52:54:00:01:b4:d3
Nov 03 13:41:12 kvm dnsmasq-dhcp[3529]: DHCPACK(virbr1) 192.168.122.208 52:54:00:01:b4:d3
Nov 03 13:43:16 kvm dnsmasq-dhcp[3529]: DHCPREQUEST(virbr1) 192.168.122.169 52:54:00:d2:7d:a4
Nov 03 13:43:16 kvm dnsmasq-dhcp[3529]: DHCPACK(virbr1) 192.168.122.169 52:54:00:d2:7d:a4
Nov 03 13:43:27 kvm dnsmasq-dhcp[3529]: DHCPREQUEST(virbr1) 192.168.122.145 52:54:00:66:3d:c4
Nov 03 13:43:27 kvm dnsmasq-dhcp[3529]: DHCPACK(virbr1) 192.168.122.145 52:54:00:66:3d:c4 server2
Nov 03 13:44:48 kvm NetworkManager[2577]: <info>  [1572752688.6056] policy: auto-activating connection 'Wired connection 2' (17698f02-4
Nov 03 13:44:48 kvm NetworkManager[2577]: <info>  [1572752688.6067] device (em2): Activation: starting connection 'Wired connection 2'
Nov 03 13:44:48 kvm NetworkManager[2577]: <info>  [1572752688.6068] device (em2): state change: disconnected -> prepare (reason 'none',
Nov 03 13:44:48 kvm NetworkManager[2577]: <info>  [1572752688.6073] device (em2): state change: prepare -> config (reason 'none', sys-i
Nov 03 13:44:48 kvm NetworkManager[2577]: <info>  [1572752688.6339] device (em2): state change: config -> ip-config (reason 'none', sys
Nov 03 13:44:48 kvm NetworkManager[2577]: <info>  [1572752688.6347] dhcp4 (em2): activation: beginning transaction (timeout in 45 secon
Nov 03 13:44:48 kvm NetworkManager[2577]: <info>  [1572752688.6396] dhcp4 (em2): dhclient started with pid 24344
Nov 03 13:44:48 kvm avahi-daemon[2499]: Registering new address record for fe80::8cce:3bf7:7f8b:9335 on em2.*.
Nov 03 13:44:48 kvm dhclient[24344]: DHCPDISCOVER on em2 to 255.255.255.255 port 67 interval 8 (xid=0x4c41d823)

Что делает journalctl гибкой командой, так это то, что ее многочисленные опции фильтрации позволяют вам показать именно то, что вам нужно. Упражнение 3 показывает некоторые из наиболее интересных вариантов.

Упражнение 3
В этом упражнении вы узнаете, как работать с различными оциями journalctl.

1. Введите journalctl. Вы увидите содержимое журнала с момента последнего запуска сервера, начиная с начала журнала. Содержимое отображается в меньшем количестве, поэтому вы можете использовать, например, less для просмотра файла.

2. Введите q, чтобы выйти из пейджера. Теперь введите journalctl —no-pager. Эта опция показывает содержимое журнала без использования пейджера.

3. Введите journalctl -f. Эта опция открывает режим просмотра в реальном времени, который позволяет видеть новые сообщения в режиме реального времени.

4. Введите journalctl и дважды нажмите клавишу Tab. Будут показаны конкретные опции, которые можно использовать для фильтрации. Выполните, например, journalctl _UID=0.

5. Введите journalctl -n 20. Опция -n 20 отображает последние 20 строк журнала (так же, как tail -n 20).

6. Теперь введите journalctl -p err. Эта команда показывает только ошибки.

7. Если вы хотите просмотреть сообщения журнала, записанные за определенный период времени, вы можете использовать команды —since и —until. Оба варианта принимают параметр времени в формате ГГГГ-ММ-ДД чч:мм:сс. Кроме того, вы можете использовать yesterday, today и tomorrow в качестве опций. Итак, введите journalctl —since yesterday, чтобы показать все сообщения, которые были написаны со вчерашнего дня.

8. journalctl позволяет комбинировать различные варианты. Итак, если вы хотите показать все сообщения с приоритом err, которые были написаны со вчерашнего дня, то используйте journalctl —since yesterday -p err.

9. Если вам нужно как можно больше подробностей, используйте journalctl -o verbose.

В предыдущем упражнении вы ввели journalctl -o verbose, чтобы показать подробный вывод.
В листинге 5 приведен пример подробного вывода. Вы можете увидеть, что вывод предоставляет подробную информацию для всех элементов, которые были логированы, в том числе PID, идентификатор связанный с учетной записью пользователя и группы и многое другое.

Листинг 5

[root@kvm ~]# journalctl -o verbose
-- Logs begin at Tue 2019-10-29 13:15:14 +10, end at Sun 2019-11-03 14:04:03 +10. --
Tue 2019-10-29 13:15:14.573354 +10 [s=4ef8b4f72a8f4b768f2ca65565a59ecc;i=1;b=eb2dcb353f4744b9933a2aa62af0ba23;m=104d0a;t=596040660742a;
    PRIORITY=6
    _TRANSPORT=driver
    MESSAGE=Runtime journal is using 8.0M (max allowed 2.3G, trying to leave 3.5G free of 23.5G available → current limit 2.3G).
    MESSAGE_ID=ec387f577b844b8fa948f33cad9a75e6
    _PID=184
    _UID=0
    _GID=0
    _COMM=systemd-journal
    _EXE=/usr/lib/systemd/systemd-journald
    _CMDLINE=/usr/lib/systemd/systemd-journald
    _CAP_EFFECTIVE=5402800cf
    _SYSTEMD_CGROUP=/system.slice/systemd-journald.service
    _SYSTEMD_UNIT=systemd-journald.service
    _SYSTEMD_SLICE=system.slice
    _BOOT_ID=eb2dcb353f4744b9933a2aa62af0ba23
    _MACHINE_ID=ee210f72c9ee465a83798398ca1e01f0
    _HOSTNAME=kvm
Tue 2019-10-29 13:15:14.573478 +10 [s=4ef8b4f72a8f4b768f2ca65565a59ecc;i=2;b=eb2dcb353f4744b9933a2aa62af0ba23;m=104d85;t=59604066074a6;
    PRIORITY=6
    _BOOT_ID=eb2dcb353f4744b9933a2aa62af0ba23
    _MACHINE_ID=ee210f72c9ee465a83798398ca1e01f0
    _HOSTNAME=kvm
    _SOURCE_MONOTONIC_TIMESTAMP=0
    _TRANSPORT=kernel
    SYSLOG_FACILITY=0
    SYSLOG_IDENTIFIER=kernel
    MESSAGE=microcode: microcode updated early to revision 0x1d, date = 2018-05-11
Tue 2019-10-29 13:15:14.573513 +10 [s=4ef8b4f72a8f4b768f2ca65565a59ecc;i=3;b=eb2dcb353f4744b9933a2aa62af0ba23;m=104da8;t=59604066074c9;
    PRIORITY=6
    _BOOT_ID=eb2dcb353f4744b9933a2aa62af0ba23
    _MACHINE_ID=ee210f72c9ee465a83798398ca1e01f0
    _HOSTNAME=kvm
    _SOURCE_MONOTONIC_TIMESTAMP=0
    _TRANSPORT=kernel
    SYSLOG_FACILITY=0

Сохранение журнала systemd

По умолчанию журнал хранится в файле /run/log/journal. Весь каталог /run используется только для информации о текущем состоянии процесса, что означает, что журнал очищается при перезагрузке системы. Чтобы сделать журнал постоянным между перезагрузками системы, вы должны убедиться, что существует каталог /var/log/journal.

Даже если журнал записывается в постоянный файл в /var/log/journal, это не означает, что журнал сохраняется вечно. Журнал имеет встроенную ротацию логов, которая будет использоваться ежемесячно. Кроме того, максимальный размер журнала ограничен 10% размера файловой системы, и он также прекратит расти, если менее 15% файловой системы все еще свободно. Если это произойдет, самые старые сообщения из журнала автоматически удаляются, чтобы освободить место для новых сообщений. Чтобы изменить эти настройки, вы можете изменить файл /etc/systemd/journald.conf. Вы увидите, что в этом файле также можно установить некоторые другие параметры (Листинг 6).

Листинг 6

[Journal]
#Storage=auto
#Compress=yes
#Seal=yes
#SplitMode=login
#SyncIntervalSec=5m
#RateLimitInterval=30s
#RateLimitBurst=1000
#SystemMaxUse=
#SystemKeepFree=
#SystemMaxFileSize=
#RuntimeMaxUse=
#RuntimeKeepFree=
#RuntimeMaxFileSize=
#MaxRetentionSec=
#MaxFileSec=1month
#ForwardToSyslog=yes
#ForwardToKMsg=no
#ForwardToConsole=no
#TTYPath=/dev/console
#MaxLevelStore=debug
#MaxLevelSyslog=debug
#MaxLevelKMsg=notice
#MaxLevelConsole=info

Сделать журнал постоянным не сложно. Упражнение 4 показывает, как это сделать.

Упражнение 4
В этом упражнении вы узнаете, как сделать журнал journald постоянным.

1. Войдите под root и введите mkdir /var/log/journal.

2. Прежде чем journald сможет записать журнал в этот каталог, вы должны установить владельца. Введите chown root:systemd-journal /var/log/journal, а затем chmod 2755 /var/log/journal.

3. Затем вы можете либо перезагрузить систему (недостаточно перезапустить службу systemd-journald), либо воспользоваться командой killall -USR1 systemd-journald.

4. Журнал systemd теперь сохраняется при перезагрузках. Если вы хотите просмотреть сообщения журнала с момента последней перезагрузки, используйте journalctl -b.

Рекомендую прочитать «Логи в Linux часть 2. Расширенные функции логов».