Журналы Linux: journalctl, rsyslog и logrotate

Что делают journald, journalctl, rsyslog и logrotate

Один и тот же факт иногда попадает в оба места: служба пишет в stdout или stderr, запись видна в journal, а rsyslog дополнительно получает syslog-сообщение и сохраняет его в текстовый файл. Обратное тоже возможно: приложение открывает собственный файл напрямую, поэтому его сообщений в journal нет. Имена unit, наличие rsyslog, набор файлов в /var/log, пути конфигурации и способ запуска logrotate зависят от дистрибутива Linux, выпуска, пакетов и локальной конфигурации.

Шаг 1. Определите, куда пишет нужная служба

systemctl status ИМЯ.service

journalctl -u ИМЯ.service -b

rsyslogd -N1

Шаг 2. Просмотр логов systemd через journalctl

Для диагностики не читайте весь журнал без отбора: ограничьте его загрузкой, unit, временем и приоритетом. Набор опций и отдельные детали их поведения зависят от версии systemd, поэтому для целевой ОС сверяйтесь с man journalctl и документацией поставщика.

Если служба не запускается, первично зафиксируйте systemctl status ИМЯ.service и journalctl -u ИМЯ.service -b до повторных попыток запуска. Разбор причин failed-unit, зависимостей, кодов завершения и восстановления — отдельная процедура в статье «Служба systemd не запускается: диагностика ошибок и восстановление».

Шаг 3. Проверьте, переживает ли journal перезагрузку

В journald.conf параметр Storage= определяет место хранения. volatile использует временный каталог /run/log/journal, содержимое которого обычно теряется при перезагрузке. persistent предпочитает постоянное хранилище в /var/log/journal, но до доступности /var или при недоступности постоянного каталога journald может использовать /run/log/journal. В режиме auto постоянное хранение применяется, когда доступен каталог /var/log/journal; при none journal не сохраняет записи, хотя их пересылка в другие приёмники может продолжаться. После появления постоянного хранилища записи из временного journal переносятся туда при штатном выполнении flush.

journalctl --list-boots

sudo test -d /var/log/journal && echo persistent-directory-present || echo persistent-directory-absent

Шаг 4. Ограничьте объём journal средствами journald

Лимиты persistent- и runtime-журналов задаются раздельно. Обычно параметры размещают в journald.conf или поддерживаемом drop-in-файле; точный путь и приоритет конфигурации сверяйте с документацией выпуска.

Не воспринимайте эти значения как абсолютно точную границу байт. Для освобождения места journald удаляет прежде всего архивные файлы; активный файл обрабатывается отдельно. Поэтому фактический объём может временно превышать лимит — например, до ротации активного файла. Условия SystemMaxUse= и SystemKeepFree= также взаимодействуют: применяемое ограничение зависит от доступного пространства при запуске journald и текущего состояния файловой системы.

journalctl --disk-usage

В версиях systemd, где они документированы, journalctl --rotate переводит активные файлы journal в архивные, а --vacuum-size=, --vacuum-time= и --vacuum-files= удаляют старые архивы по выбранному критерию. Проверяйте наличие и синтаксис этих опций через man journalctl в целевой ОС. Для немедленного применения очистки обычно важен порядок: сначала ротация активного файла, затем vacuum; без архивных файлов освобождать может быть нечего.

Шаг 5. Настройте ротацию текстового лога через logrotate

Правило logrotate содержит путь к одному или нескольким текстовым логам, условия ротации, число архивов и при необходимости действия после ротации. Основной файл, каталог включаемых правил и механизм периодического запуска различаются: в одних пакетных вариантах это cron, в других — systemd timer или иной пакетный механизм. Проверьте установленные файлы пакета и состояние соответствующего механизма в документации своей ОС; диагностика cron и timers рассматривается отдельно в статье «Cron и systemd timers: задачи по расписанию и диагностика сбоев».

/var/log/example-app/app.log {
    weekly
    maxsize 100M
    rotate 8
    compress
    delaycompress
    missingok
    notifempty
    create 0640 appuser appgroup
    sharedscripts
    postrotate
        # Здесь должна быть только документированная команда
        # переоткрытия лога или reload целевого приложения.
        # Например, команда из документации приложения.
    endscript
}

Пример намеренно не содержит универсальной команды reload. Некоторые приложения умеют переоткрывать лог по сигналу, некоторые — по собственной команде управления, другие требуют документированного reload или restart. Применяйте только способ, указанный в документации целевого приложения или демона. copytruncate не является универсальной заменой: между копированием и обнулением возможна потеря или дублирование строк, а приложение может иметь другой штатный механизм.

Шаг 6. Проверьте правило без изменений и проведите реальную ротацию

sudo logrotate -d /ПУТЬ/К/ПРАВИЛУ

Перед изменением политики хранения

• Оцените свободное место на файловой системе, где находятся journal и текстовые логи, отдельно от общего свободного места сервера.
• Определите требуемый срок хранения: он зависит от расследований инцидентов, аудита, частоты ошибок и объёма записей, а не только от доступного диска.
• Сохраните изменяемые journald.conf, drop-in-файлы, правила logrotate и конфигурацию rsyslog до правки.
• Для journal проверьте journalctl --disk-usage, доступность предыдущих загрузок и действующие настройки хранения.
• Для текстовых файлов зафиксируйте владельца, права, размер, механизм переоткрытия и текущие архивы.
• После изменения проверяйте результат штатными средствами именно вашего дистрибутива: фактический объём, новые записи, статус демона и выполнение планировщика logrotate.