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

Содержание

Изначально journald хранит логи только в оперативной памяти, что делает их недоступными после перезагрузки системы. В этой статье разберём, как включить постоянное хранение журналов, настроить автоматическую ротацию и сжатие, а также эффективно фильтровать записи при просмотре. Такие настройки особенно полезны при работе с VPS, где важно сохранять полную историю событий для диагностики и безопасности.

Введение

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

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

Аренда VPS/VDS — от ₽219/месяц

Почему выбирают VPS от AdminVPS:

✓ Дешевле физического сервера

✓ Более гибкий и мощный, чем обычный хостинг

✓ Бесплатная защита от DDoS и техподдержка 24/7

✓ Масштабируется под любые задачи

Виртуальный сервер VPS/VDS — ваш личный сервер для сайтов, магазинов, ботов и других проектов.

Что такое journald

Демон journald выполняет сбор записей из различных источников, включая сообщения ядра, системные службы, пользовательские процессы и аппаратные события. Все записи хранятся в бинарном формате с сохранением большого набора метаданных, таких как временные метки, идентификаторы процессов (PID), идентификаторы пользователей (UID), имена системных юнитов и другие параметры.

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

Включение персистентного хранения журналов

По умолчанию journald хранит логи только в оперативной памяти (в директории /run/log/journal), что приводит к их полной потере после перезагрузки системы. Такое поведение ограничивает возможности диагностики и анализа событий.

Активация постоянного хранилища на диске (в директории /var/log/journal) позволяет сохранять логи между перезагрузками системы. journald автоматически переключится на использование дискового хранилища, как только обнаружит корректно настроенную директорию.

Шаги по настройке

Создание целевой директории для постоянного хранилища:

sudo mkdir -p /var/log/journal

Настройка корректных прав доступа к директории. Важно установить групповую принадлежность journal и setgid-bit так, чтобы вновь создаваемые файлы наследовали группу директории, а не первичную группу пользователя:

sudo chown root:systemd-journal /var/log/journal
sudo chmod 2755 /var/log/journal

Принудительная перезагрузка демона для применения изменений:

sudo systemctl restart systemd-journald

В некоторых может понадобиться перезапуск не только systemd-journald, но и всей системы.

Убедитесь, что journald теперь использует постоянное хранилище, проверив наличие журналов в новой директории:

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

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

Настройка сжатия и ротации логов

Основные параметры управления хранением и ротацией логов настраиваются в конфигурационном файле journald — /etc/systemd/journald.conf. Для применения изменений требуется перезагрузка демона.

Ключевые параметры конфигурации:

Compress=yes — включает сжатие старых файлов журнала с использованием алгоритма zstd.
SplitMode=uid — активирует создание отдельных файлов журнала для каждого UID, что может упрощать анализ и изоляцию логов разных пользователей и служб (не рекомендуется в системах с большим количеством пользователей и служб).
SystemMaxUse=10G — устанавливает максимальный общий объём дискового пространства, который могут занимать все файлы журнала. При достижении этого лимита старые записи автоматически удаляются.
SystemMaxFiles=100 — ограничивает максимальное количество отдельных файлов. Помогает предотвратить чрезмерную фрагментацию хранилища.
MaxRetentionSec=1month — определяет максимальный срок хранения записей в журнале, после которого они автоматически удаляются независимо от других настроек.

Пример конфигурации:

[Journal]
Storage=persistent
Compress=yes
SplitMode=uid
SystemMaxUse=10G
SystemMaxFiles=100
MaxRetentionSec=1month

После внесения изменений в конфигурационный файл, перезагрузите демон:

sudo systemctl restart systemd-journald

Дополнительные рекомендации:

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

journalctl --disk-usage

Для принудительной очистки старых записей можно использовать:

sudo journalctl --vacuum-size=8G

При настройке параметров учитывайте особенности вашей системы и требования к хранению логов.

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

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

Для просмотра записей, относящихся к конкретной systemd-службе, используйте флаг -u (или --unit):

journalctl -u nginx.service

Для фильтрации по пользовательским тегам приложений используйте фильтр TAG=значение:

journalctl TAG=myapp

Эта команда полезна для просмотра логов приложений, которые добавляют собственные теги в журнальные записи через системные вызовы syslog.

Также journalctl позволяет комбинировать различные критерии фильтрации:

journalctl -u ssh --since "2024-06-01" --until "2024-06-02" --priority err

Эта команда покажет все ошибки SSH-службы за указанный период.

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

Пример файла /etc/systemd/system/myapp.service:

[Unit]
Description=My Custom App
[Service]
ExecStart=/usr/bin/myapp
LogLevelMax=debug
LogTag=myapp
Environment=SYSLOG_IDENTIFIER=myapp

Ключевые параметры:

LogTag=myapp — устанавливает кастомный тег для всех сообщений службы,
Environment=SYSLOG_IDENTIFIER=myapp — дублирует LogTag для совместимости с syslog,
LogLevelMax=debug — устанавливает максимальный уровень детализации логов.

Дополнительные возможности фильтрации:

по приоритету:

journalctl -p err..alert

по исполняемому файлу:

journalctl /usr/bin/sshd

по временному интервалу:

journalctl --since "10 min ago"

в реальном времени:

journalctl -f -u myapp.service

После настройки тегов и применения изменений (через systemctl daemon-reload и перезапуск службы) фильтрация по кастомным тегам станет доступной, обеспечивая более структурированную работу с журналами приложений.

Читайте в блоге: