journalctl
journald
journald — это компонент системы инициализации Systemd, отвечающий за сбор и хранение журналов (логов) системы и служб. Он является частью механизма логирования, обеспечивая централизованный способ управления и доступа к записям логов на системах, использующих Systemd.
Основные характеристики journald
- Централизованное логирование: journald собирает логи от различных системных служб и приложений, позволяя хранить их в одном месте.
- Структурированные логи: Записи в журналах имеют структурированный формат, что облегчает их анализ и фильтрацию. Каждая запись содержит метаданные, такие как временные метки, идентификаторы процессов и уровни важности.
- Поддержка различных источников: journald может собирать логи не только от Systemd-юнитов, но и от других приложений, использующих стандартные выходные потоки (stdout и stderr).
- Фильтрация и поиск: journald предоставляет мощные инструменты для фильтрации и поиска по записям журнала, что упрощает диагностику и мониторинг.
- Поддержка ротации: Система автоматической ротации позволяет управлять объемом хранимых логов, удаляя старые записи, чтобы освободить место.
- Журналирование в реальном времени: journald поддерживает вывод логов в реальном времени, что позволяет администраторам следить за происходящими событиями на сервере.
Архитектура
journald принимает сообщения через специальный протокол. Есть библиотека для отправки туда логов (и большинство языко-специфичных фреймворков логгирования её поддерживают, на одном уровне с syslog, stderr, elastic и т.д.). В отличие от многих других систем (logstash, graylog) journald не умеет бегать за файлами на файловой системе и "забирать" их.
Полученные данные хранятся частично в оперативной памяти, и могут сохраняться в постоянное хранилище на диске с настраиваемым уровнем надёжности. Файлы на диске - бинарные, индексированные, что существенно упрощает систематизацию и поиск, journald сам их ротирует.
Преимуществ централизованного логирования событий в бинарном формате достаточно много, например системные логи можно транслировать в различные форматы, такие как простой текст, или в JSON, при необходимости. Так же довольно просто можно отследить лог вплоть до одиночного события используя фильтры даты и времени.
В системе может быть больше одного journald, что позволяет разделить "обычную ОС" и "логи важного приложения". Реализуется это через концепцию journal namespaces и шаблонов systemd.
Настройка хранения журналов
По умолчанию journald перезаписывает свои журналы логов при каждой перезагрузке, и вызов journalctl выведет журнал логов начиная с текущей загрузки системы.
В случае если на сервере имеется директория /run/log/journal/ и она не пуста, если директории /var/log/journal не существует и если команда journalctl --list-boots показывает только один пункт из списка, то скорее всего в этом случае journald настроен на временное хранение логов до ребута.
Когда в конфигурационном файле /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
Что бы логи не разрослись, имеет смысл настроить их ротацию, для этого у journalctl доступны параметры --vacuum-size и --vacuum-time.
# общий размер логов
journalctl --disk-usage
# Ограничим размер логов объёмом в 1Гб
journalctl --vacuum-size=1G
# При необходимости, ограничим время хранения логов
journalctl --vacuum-time=1years
Если наши логи занимали 2Гб, при ограничении размера до 1Гб, система удалит самые старые логи. Аналогично и со временем хранения журналов. Дополнительную настройку лимитов можно выполнить в конфигурационном файле /etc/systemd/journald.conf.
Просмотр журналов загрузки
Если journald был настроен на постоянное хранение журналов, мы можем просматривать журналы логов по каждой отдельной загрузке
Первый номер показывает номер журнала, который можно использовать для просмотра журнала определенной сессии. Второй номер boot ID так же можно использовать для просмотра отдельного журнала. Здесь мы получаем порядковый номер загрузки (0 — текущая, -1 — предыдущая и т. д.), следующие две даты, промежуток времени в течении которого в него записывались логи, это удобно если вы хотите найти логи за определенный период.
# Используя порядковый номер или ID мы можем обращаться к конкретному логу с помощью ключа -b
journalctl -b 20994413abfc41c89defcaaeb1130d62
journalctl -b -3
Обратившись к логу, мы получаем всё его содержимое. Неплохо было бы отфильтровать только нужные для нас данные.
Просмотр логов
Использование journalctl для просмотра и анализа логов
Она выведет все записи из всех журналов, включая ошибки и предупреждения, начиная с того момента, когда система начала загружаться. Старые записи событий будут наверху, более новые — внизу, вы можете использовать PageUp и PageDown чтобы перемещаться по списку, Enter — чтобы пролистывать журнал построчно и Q — чтобы выйти.
По умолчанию journalctl выводит время событий согласно настроенного в вашей системе часового пояса, также journalctl позволяет просмотреть логи с временем UTC (в этом стандарте времени сохраняются события внутри файлов journald), для этого можно использовать команду:
Фильтрация событий по важности
Система записывает события с различными уровнями важности, какие-то события могут быть предупреждением, которое можно проигнорировать, какие-то могут быть критическими ошибками. Если мы хотим просмотреть только ошибки, игнорируя другие сообщения, введем команду с указанием кода важности:
Для уровней важности, приняты следующие обозначения:
- 0: emergency (неработоспособность системы)
- 1: alerts (предупреждения, требующие немедленного вмешательства)
- 2: critical (критическое состояние)
- 3: errors (ошибки)
- 4: warning (предупреждения)
- 5: notice (уведомления)
- 6: info (информационные сообщения)
- 7: debug (отладочные сообщения)
Когда вы указываете код важности, journalctl выведет все сообщения с этим кодом и выше. Например если мы укажем опцию -p 2, journalctl покажет все сообщения с уровнями 2, 1 и 0.
Фильтрация по дате и времени
-
Journalctl позволяет использовать такие служебные слова как
yesterday,today,tomorrow, илиnow. -
Также можно использовать опции
--since(с начала какого периода выводить журнал) и--until(окончание периода)
# С определенной даты и времени
journalctl --since "2025-12-31 06:00:00"
# С определенной даты и по определенное дату и время
journalctl --since "2024-12-10" --until "2025-01-02 10:00:00"
# Со вчерашнего дня
journalctl --since yesterday
# С 9 утра и до момента, час назад
journalctl --since 09:00 --until "1 hour ago"
Фильтрация по приложениям и службам
Для просмотра логов конкретного приложения или службы используется опция -u
Фильтрация по процессам, пользователям и группам
Информацию из журнала можно выбрать по id пользователя или группы в системе, либо по номеру процесса.
# Для того, чтобы узнать у каких ID есть логи можно использовать команду:
journalctl -F _PID
journalctl -F _UID
journalctl -F _GID
journalctl -F _GUID
# Узнать все, что записала программа 404
journalctl _PID=404
# Узнать все, что записал пользователь 505
journalctl _UID=505
# Узнать все, что записала группа 606
journalctl _GID=606
Фильтрация по пути
Просмотреть логи для какого-либо процесса также можно, указав путь к нему
Иногда таким способом можно получить более подробную информацию (например, просмотреть записи для всех дочерних процессов).
Другие фильтры
С командной journalctl можно использовать и другие фильтры.
Просмотр сообщений ядра
Для просмотра сообщений ядра используется опция -k или −−dmesg
# Приведённая команда покажет все сообщения ядра для текущей загрузки.
journalctl -k
journalctl --dmesg
# Чтобы просмотреть сообщения ядра для предыдущих сессий, нужно воспользоваться опцией -b
# и указать один из идентификаторов сессии (порядковый номер в списке или ID)
journalctl -k -b -1
Запись логов в стандартный вывод
По умолчанию journalctl использует для вывода сообщений логов внешнюю утилиту less. В этом случае к ним невозможно применять стандартные утилиты для обработки текстовых данных (например, grep). Эта проблема легко решается: достаточно воспользоваться опцией −−no-pager, и все сообщения будут записываться в стандартный вывод:
После этого их можно будет передать другим утилитам для дальнейшей обработки или сохранить в текстовом файле.
Дополнительные опции просмотра
- Отобразить только несколько последних строк лога:
- Следить за появлением новых сообщений в реальном времени (аналог tail -f):
- Открыть журнал «перемотав» его к последней записи:
journalctl -e - Указание конкретного журнала за которым следует следить:
Выбор формата вывода
C помощью опции -o можно преобразовывать данные логов в различные форматы, что облегчает их парсинг и дальнейшую обработку:
Помимо JSON данные логов могут быть преобразованы в следующие форматы:
- cat — только сообщения из логов без служебных полей;
- export — бинарный формат, подходит для экспорта или резервного копирования логов;
- short — формат вывода syslog;
- short-iso — формат вывода syslog с метками времени в формате ISO 8601;
- short-monotonic — формат вывода syslog c метками монотонного времени (monotonic timestamp);
- short-precise — формат вывода syslog с метками точного времени (время событий указывается с точностью до микросекунд);
- verbose — максимально подробный формат представления данных (включает даже те поля, которые в других форматах не отображаются).