Journald. Шпаргалка по работе с journalctl.

Здесь будет много примеров команд для journalctl, так что возможно эту заметку удобнее будет читать с ПК или хотя бы с планшета, а не с телефона.

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

Постоянное хранение логов и их ротация.
Просмотр информации о логах.
Выборка по имени юнита.
Выборка по номеру PID, UID, GID, по пути к бинарнику.
Использование временных отрезков.
Фильтрация по приоритету сообщений.
Стандартный вывод для сообщений и аналог tail.

Для начала, давайте убедимся что логи journald у нас не очищаются с каждой перезагрузкой сервера. В случае если на сервере имеется директория /run/log/journal/ и она не пуста, если директории /var/log/journal не существует и если команда journalctl --list-boots показывает только один пункт из списка, то скорее всего в этом случае journald настроен на временное хранение логов до ребута. Исправить эту ситуацию можно следующим образом…

1. Включаем постоянное хранение логов в конфиге /etc/systemd/journald.conf:

[Journal]
Storage=persistent

2. Создаём директорию для журналов и вводим её в работу:

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

Теперь наши логи будут храниться на диске и мы сможем обращаться к ним даже после перезагрузки.

3. Что бы логи не разрослись, имеет смысл настроить их ротацию, для этого у journalctl доступны параметры --vacuum-size и --vacuum-time.

Просмотрим общий размер логов:

journalctl --disk-usage

Ограничим размер логов объёмом в 1Гб:

journalctl --vacuum-size=1G

При необходимости, ограничим время хранения логов:

journalctl --vacuum-time=1years

Если наши логи занимали 2Гб, при ограничении размера до 1Гб, система удалит самые старые логи. Аналогично и со временем хранения журналов. Дополнительную настройку лимитов можно выполнить в конфигурационном файле /etc/systemd/journald.conf.

Просмотр информации о логах.

Перейдём непосредственно к работе с логами. Команда, которая показывает нам список всех загрузок системы:

journalctl --list-boots

Здесь мы получаем порядковый номер загрузки (0 — текущая, -1 — предыдущая и т. д.), ID загрузки и информацию о времени. Используя порядковый номер или ID мы можем обращаться к конкретному логу с помощью ключа -b

journalctl -b 20994413abfc41c89defcaaeb1130d62
journalctl -b -3

Обратившись к логу, мы получаем всё его содержимое. Неплохо было бы отфильтровать только нужные для нас данные.

Выборка по имени юнита.

Мы можем указывать конкретный юнит, сообщения которого из лога нам нужны. Например, мы хотим получить все сообщения от юнита httpd:

journalctl -u httpd.service

Либо получить сообщения из лога сразу от двух юнитов httpd и mysql:

journalctl -u httpd.service -u mysql.service

.service в имени юнитов можно не дописывать. Команда ниже даст аналогичный предыдущей результат:

journalctl -u httpd -u mysql

Выборка по номеру PID, UID, GID, по пути к бинарнику.

Информацию из журнала можно выбрать по id пользователя или группы в системе, либо по номеру процесса. Для начала посмотрим у каких PID, UID и GID в журнале есть записи, сделать это можно командой journalctl -F

journalctl -F _UID
journalctl -F _PID
journalctl -F _GID

Допустим на нужно получить всё что в журнал записала программа с PID 2093:

journalctl _PID=2093

Либо у нас в системе есть пользователь с UID 1395 и мы хотим посмотреть что есть в журналах от него:

journalctl _UID=1395

Аналогично и для группы, например GID 99:

journalctl _GID=99

Сообщения от ядра мы можем показать отдельной командой:

journalctl -k
journalctl --dmesg
journalctl -k -b -3
journalctl --dmesg -b 20994413abfc41c89defcaaeb1130d62

Сообщения из журнала от конкретного бинарника мы так же можем получить отдельно. Например, сообщения от /usr/sbin/pure-ftpd:

journalctl /usr/sbin/pure-ftpd
journalctl _EXE=/usr/sbin/pure-ftpd

Использование временных отрезков.

Иногда, в ходе исследования какой-либо проблемы, необходимо получить логи только за определённый промежуток времени. Для этого в journalctl предусмотрены ключи --since и --until. В качестве значений для этих ключей могут использоваться:

— Формат YYYY-MM-DD HH:MM:SS

journalctl --since "2017-05-05 00:01" --until "2017-05-06 01:40"

— Слова «yesterday», «today», «tomorrow», «now»:

journalctl --since "yesterday" --until "2017-05-06 01:40"

— Удобочитаемые выражения вида:

journalctl --since "10 hours ago"
journalctl --since "1 minute ago"
journalctl --since "50 minute ago" --until "5 minute ago"

Фильтрация по приоритету сообщений.

Journald использует аналогичные syslog уровни сообщений. При фильтрации мы можем использовать либо имя приоритета, либо соответствующее имени число (далее от большего к меньшему):

0: emerg
1: alert
2: crit
3: err
4: warning
5: notice
6: info
7: debug

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

journalctl -p err -b -1

Ошибки, которые NetworkManager оставлял в логе до перезагрузки можно увидеть командой:

journalctl -p err -b -1 -u NetworkManager

Стандартный вывод для сообщений и аналог tail.

По умолчанию, journalctl выводит сообщения с помощью утилиты less. Это не всегда бывает удобно. Например, если мы хотим использовать grep для дополнительной фильтрации, имеет смысл направить сообщения от journalctl сразу на стандартный вывод. Для этого предусмотрен отдельный параметр:

journalclt --no-pager

Так же, pager можно задать переменной:

export SYSTEMD_PAGER=cat

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

journalctl -n 50
journalctl -f
journalctl -f -u NetworkManager

Вместо заключения. Journald — это местами не привычный (для тех кто привык grep’ать вывод cat по текстовым файлам), но удобный инструмент для работы с логами в системе. Уже сегодня, он используется почти во всех современных дистрибутивах, а значит обязателен для ознакомления каждому администратору. О дополнительных удобствах, которые предлагает systemd и journald, но которые пока что доступны только в передовых дистрибутивах (Fedora, Arch) поговорим в отдельной заметке.