Шпаргалка journalctl. Как искать в журнале, ошибки и процессы

systemd journal – это инструмент для сбора системных данных и данных приложений. Благодаря централизованному подходу к журналированию, а также благодаря автоматической записи подробных метаданных, удалось добиться большой гибкости и удобства. С помощью journalctl можно просматривать журналы, получая необходимую информацию для анализа работы и отладки различных системных компонентов. Как и что можно выудить при помощи этой команды далее в этой статье.

Просмотр информации о загрузках системы.

Все загрузки системы можно посмотреть при помощи команды:

# journalctl --list-boots

Она выводит табличку состоящую из четырёх колонок. В первой колонке указывается порядковый номер загрузки, во второй – её ID, в третьей – дата и время загрузки, в четвертой – дата выключения. Чтобы просмотреть журнал для конкретной загрузки, можно использовать как порядковый номер, так и ID загрузки:

# journalctl -b -7
# journalctl -b 7cd26278848344a79c1cdc56e4be051f

Команда выводит все содержимое журнала. Как фильтровать вывод journalctl далее в этой статье.

Фильтрация по дате и времени

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

• дата в формате YYYY-MM-DD HH:MM:SS;
• слова «yesterday», «today», «tomorrow», «now».

Например, если нам нужно просмотреть логи начиная с 17 часов 04 минут 20 апреля 2017 года, то для этого потребуется будет выполнить команду:

# journalctl --since "2017-04-20 17:04:00"

Если с опцией since не будет указано никакой даты, на консоль будут выведены логи начиная с текущей даты. Если дата указана, но при этом не указано время, будет применено значение времени по умолчанию – «00:00:00». При указании времени секунды указывать не обязательно (в этом случае применяется значение по умолчанию – «00»).

При построении запросов можно использовать такие человеко-понятные конструкции:

# journalctl --since "10 hours ago"
# journalctl --since yesterday
# journalctl --since "50 minute ago" --until "5 minute ago"
# journalctl --since 09:00 --until now

Фильтрация по приложениям и службам

Для просмотра логов конкретного приложения или службы используется опция -u. Можно указывать конкретный юнит, журнал сообщений которого нам нужен. Например, для просмотра журнала сообщений от юнита nginx:

# journalctl -u nginx.service

Можно выбирать журнал сообщений сразу от нескольких юнитов – просто задать несколько опций -u. Частичку .service в имени юнитов можно не писать.

# journalctl -u nginx.service -u php-fpm.service
# journalctl -u nginx -u php-fpm

Результат в обоих случаях будет идентичный. Одновременно с фильтрацией по юнитам можно использовать фильтрацию по дате и времени.

Фильтрация по процессам, пользователям и группам

Для вывода журнала сообщений какого-либо процесса используется опция _PID с указанием идентификатора процесса. Например:

# journalctl _PID=1071

Перечень всех PID, от которых есть сообщения в журнале можно получить командой:

# journalctl -F _PID

Аналогично для пользователей

# journalctl _UID=1001
# journalctl -F _UID

И для пользовательских групп

# journalctl _GID=11
# journalctl -F _GID

Фильтрация по пути

Просмотреть журналы какого-либо процесса также можно, указав путь к нему, например:

# journalctl /usr/bin/mysqld
# journalctl _EXE=/usr/bin/mysqld

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

Для просмотра журнала сообщений ядра используется опция -k или dmesg:

# journalctl -k
# journalctl --dmesg

Эта команда покажет весь журнал сообщений ядра для текущей загрузки. Чтобы просмотреть журнал сообщений ядра для предыдущих загрузок, нужно воспользоваться опцией -b и указать один из идентификаторов загрузки (порядковый номер в списке или ID):

# journalctl -k -b -4
# journalctl --dmesg -b 7cd26278848344a79c1cdc56e4be051f

Фильтрация сообщений по уровню ошибки

Во время диагностики и устранения неполадок в системе возникает необходимость просмотреть журнал и выяснить, есть ли в нём сообщения о критических ошибках. Специально для этого в journalctl предусмотрена возможность фильтрации по уровню ошибки. Для этого используется опция -p после которой указывается код уровня ошибок:

• 0: emerg (система неработоспособна);
• 1: alert (требуется немедленное вмешательство);
• 2: crit (критическое состояние);
• 3: err (ошибка);
• 4: warning (предупреждение);
• 5: notice (всё нормально, но следует обратить внимание);
• 6: info (информационное сообщение);
• 7: debug (отложенная печать).

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

# journalctl -p err -b -1

Которая выведет что-то типа этого:

Май 29 13:08:52 styx kernel: sp5100_tco: I/O address 0x0cd6 already in use
Май 29 13:09:04 styx nmbd[558]: [2017/05/29 13:09:03.865625,  0] ../lib/util/become_daemon.c:124(daemon_ready)
Май 29 13:09:04 styx nmbd[558]:   STATUS=daemon 'nmbd' finished starting up and ready to serve connections
Май 29 13:09:06 styx smbd[596]: [2017/05/29 13:09:06.324661,  0] ../lib/util/become_daemon.c:124(daemon_ready)
Май 29 13:09:06 styx smbd[596]:   STATUS=daemon 'smbd' finished starting up and ready to serve connections
Май 29 13:09:27 styx nmbd[558]: [2017/05/29 13:09:27.332214,  0] ../source3/nmbd/nmbd_become_lmb.c:397(become_local_master_stage2)
Май 29 13:09:27 styx nmbd[558]:   *****
Май 29 13:09:27 styx nmbd[558]:   
Май 29 13:09:27 styx nmbd[558]:   Samba name server STYX is now a local master browser for workgroup MYLINUX on subnet 192.168.0.82
Май 29 13:09:27 styx nmbd[558]:   
Май 29 13:09:27 styx nmbd[558]:   *****
Май 29 23:21:29 styx nmbd[558]: [2017/05/29 23:21:29.422115,  0] ../source3/nmbd/nmbd.c:58(terminate)
Май 29 23:21:29 styx nmbd[558]:   Got SIGTERM: going down...
Май 29 23:21:32 styx systemd[1]: Failed unmounting /usr.
Май 29 23:21:32 styx systemd[1]: Failed unmounting /var.

Можно фильтры комбинировать друг с другом. Например отфильтровать ошибки nmbd:

# journalctl -p err -b -1 -u nmbd

или ошибки процесса с PID 596:

# journalctl -p err -b -1 _PID=596

Продвинутые запросы или комбинация параметров

Уже неоднократно приводились примеры где в запросах указывалось несколько параметров. Указание нескольких различных полей дает эффект логического И. Например:

# journalctl -p warning -u nginx -u php-fpm

В результате, будут выведены записи с уровнем ошибок warning только от процессов nginx и php-fpm. Однако можно строить и более сложные логические выражения! При помощи + (плюс) мы можем явно задать логическое ИЛИ, применяя его к разным полям и даже И-выражениям. Например:

# journalctl -p info UNIT=nginx.service + -p info UNIT=php-fpm.service

Данный запрос выведет сообщения от nginx с уровнем ошибок err и сообщения от php-fpm с уровнем ошибок warning.

Приоритет логических операций стандартный: сначала выполняются операции И, и только потом – операции ИЛИ. Используемая в journalctl система записи выражений аналогична принятой в классической алгебре: операция И, имеющая более высокий приоритет, не указывается знаком операции, а обозначается просто последовательной записью величин.

Однако такие сложные выражения работают когда вы строите запросы по полям метаданных. Более детальная информация об этом в руководстве.

Управление форматами вывода

О форматах вывода и просмотре информации о недавних событиях я писал в статье Стандартный вывод и аналог tail

Управление журналами

О хранилище журналов и ротации я писал в статье Где находятся журналы и сколько они занимают

В заключение

То о чем не написал, найдется в man journalctl.