systemd-journald и syslog: хранение, ротация и форвардинг логов в Linux

В современных дистрибутивах Linux роль «первого приемника» логов чаще всего выполняет systemd-journald. Он собирает сообщения ядра, сервисов systemd, stdout/stderr демонов, а также (опционально) события из /dev/log. Параллельно во многих инфраструктурах до сих пор живёт классическая модель syslog (rsyslog/syslog-ng), где логи пишутся в текстовые файлы в /var/log и ротируются через logrotate.

Из-за этого регулярно всплывают типовые вопросы: почему /var/log/messages пустой, куда делся auth.log, почему внезапно закончился диск, как настроить retention, чем ограничивать journal, и нужно ли форвардить события в syslog. Ниже — практическая схема настройки systemd-journald и связки с syslog с упором на предсказуемое хранение и контроль объёма.

Как journald и syslog делят работу

systemd-journald пишет события в бинарный журнал и даёт доступ к нему через journalctl. В отличие от классических текстовых логов, journal:

• хранит структурированные поля (unit, pid, uid, cgroup, executable и т.д.);
• умеет быстрый поиск/фильтрацию без grep по гигабайтам файлов;
• имеет встроенную ротацию и политики хранения без logrotate;
• может хранить данные в памяти или на диске.

Syslog-демоны (rsyslog/syslog-ng) полезны, когда вам нужно:

• сохранять логи в привычных файлах в /var/log ради совместимости со старым ПО и привычными pipeline;
• маршрутизировать сообщения по facilities/severity, шаблонам и правилам;
• настроить централизованную доставку логов по политике компании;
• обслуживать приложения, которые пишут напрямую в syslog.

Практическое правило: journald почти всегда оставляют как «источник истины» на хосте, а syslog подключают, когда нужны текстовые файлы/маршрутизация или это требование процессов.

Где хранятся логи journald: Storage=volatile и Storage=persistent

Ключевой параметр — Storage= в /etc/systemd/journald.conf (или drop-in в /etc/systemd/journald.conf.d/). Он определяет, будет ли журнал сохраняться на диск.

• Storage=volatile — хранение в /run/log/journal (обычно tmpfs), после перезагрузки исчезает.
• Storage=persistent — хранение на диске в /var/log/journal.
• Storage=auto — если существует /var/log/journal, то persistent, иначе volatile.

На части систем по умолчанию журнал оказывается volatile (часто на минимальных образах или контейнерах). Это экономит место, но плохо подходит для расследований: перезагрузка — и «история» пропала.

Включить постоянное хранение проще всего через drop-in (так безопаснее при обновлениях и проще поддерживать конфигурационным менеджером):

sudo mkdir -p /etc/systemd/journald.conf.d
sudo mkdir -p /var/log/journal
sudo systemd-tmpfiles --create --prefix /var/log/journal
sudo tee /etc/systemd/journald.conf.d/10-storage.conf > /dev/null << 'EOF'
[Journal]
Storage=persistent
EOF
sudo systemctl restart systemd-journald

Проверка, что журнал реально на диске и сколько он занимает:

journalctl --disk-usage

Если вы держите сайты на виртуальном хостинге или на VDS, персистентный journald обычно стоит включать хотя бы для базовой диагностики инцидентов (перезапуски, падения, ssh-ошибки), но обязательно вместе с лимитами по объёму — об этом дальше.

Ограничение роста и retention: SystemMaxUse, SystemKeepFree и MaxRetentionSec

Распространённая ошибка — оставить journal «как есть» и надеяться, что он сам ограничится. На практике неконтролируемый рост журнала легко становится причиной заполнения диска, особенно на небольших серверах.

За политику хранения отвечают несколько параметров, но чаще всего достаточно правильно задать два:

• SystemMaxUse — верхний лимит дискового пространства, которое journald может занять (для system-wide журнала).
• SystemKeepFree — сколько места journald должен оставить свободным на файловой системе.

Они работают вместе: journald старается соблюдать оба ограничения, удаляя старые сегменты журнала. Базовый продакшен-шаблон: «потолок по объёму» плюс «подушка свободного места». Например:

sudo tee /etc/systemd/journald.conf.d/20-retention.conf > /dev/null << 'EOF'
[Journal]
SystemMaxUse=2G
SystemKeepFree=1G
EOF
sudo systemctl restart systemd-journald

Ориентиры по значениям:

• маленький сервер (20–40 ГБ диск): SystemMaxUse=512M–1G, SystemKeepFree=1G;
• средний (80–160 ГБ): SystemMaxUse=2G–5G, SystemKeepFree=2G;
• нагруженный приложенческий узел: отталкивайтесь от реального потока событий и требований к хранению.

Если retention задан именно «в днях», добавляйте временное ограничение:

sudo tee /etc/systemd/journald.conf.d/30-retention-time.conf > /dev/null << 'EOF'
[Journal]
MaxRetentionSec=14day
EOF
sudo systemctl restart systemd-journald

Если вам важно «не более N дней», используйте MaxRetentionSec, но всё равно оставляйте ограничение по объёму: всплеск логов при инциденте способен съесть диск быстрее, чем сработает временной retention.

Ещё два параметра, которые иногда полезны для «подпиливания» поведения:

• SystemMaxFileSize — ограничение размера одного файла журнала;
• MaxFileSec — максимальный «возраст» файла перед ротацией.

Облачный VDS-сервер в России

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

journalctl в повседневной диагностике: хвост, время, юниты, приоритеты

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

Смотреть «хвост» и следить в реальном времени

journalctl -n 200
journalctl -f

Фильтрация по systemd unit

journalctl -u nginx.service -n 200
journalctl -u php-fpm.service --since "today"

Текущая загрузка и предыдущая

journalctl -b
journalctl -b -1

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

Практично начинать с ошибок и предупреждений:

journalctl -p err -b
journalctl -p warning --since "1 hour ago"

Посмотреть поля и «структуру» события

Чтобы понять, чем journald «обогащает» записи:

journalctl -u ssh.service -o verbose -n 5

Для выгрузки в тикет/разбор инцидента удобен JSON:

journalctl -u nginx.service -o json-pretty -n 20

Если вы собираете логи на отдельный хост, полезно настроить приём journal по сети. У нас есть отдельная инструкция: как настроить systemd-journal-remote для централизованного сбора journald.

ForwardToSyslog: когда включать и как не получить дубли

Параметр ForwardToSyslog в journald отвечает за пересылку сообщений из journald в syslog-сокет. Это удобно, если вы хотите, чтобы rsyslog/syslog-ng продолжал писать привычные файлы, но источником стал journald.

Типовые сценарии:

• journald → syslog → /var/log/*: journald собирает всё, syslog получает поток и пишет в файлы.
• приложения → syslog напрямую: часть логов идёт в rsyslog минуя journald (возможны расхождения).
• дубли: одно и то же событие попадает в syslog дважды из-за неверной связки.

Включение форвардинга:

sudo tee /etc/systemd/journald.conf.d/40-forward.conf > /dev/null << 'EOF'
[Journal]
ForwardToSyslog=yes
EOF
sudo systemctl restart systemd-journald

Перед тем как включать, проверьте три вещи:

• какой syslog-демон установлен и запущен (rsyslog/syslog-ng);
• как он получает сообщения: из /dev/log, через чтение journal напрямую, или из обоих источников;
• не включён ли одновременно модуль чтения journal в rsyslog (например imjournal) — вместе с ForwardToSyslog это часто даёт дублирование.

Нормальная цель ForwardToSyslog — совместимость и файловые логи. Если нужен только просмотр/фильтрация на хосте, часто достаточно одного journald.

Проверка текущих лимитов и быстрая «санитарная уборка»

Сначала оцените текущий объём:

journalctl --disk-usage

Дальше полезно посмотреть, какие настройки реально применены (а не только что «лежит в файле»):

systemctl show systemd-journald --property=FragmentPath
systemd-analyze cat-config systemd/journald.conf

Если журнал уже раздулся, можно безопасно уменьшить объём вакуумом.

Ограничить по размеру (удалит старое):

sudo journalctl --vacuum-size=1G

Ограничить по времени:

sudo journalctl --vacuum-time=14d

После вакуума обязательно зафиксируйте ограничения в конфиге (SystemMaxUse, SystemKeepFree), иначе рост повторится.

Виртуальный хостинг для сайтов

Универсальное решение для создания и размещения сайтов любой сложности в Интернете от 95₽ / мес

Подробнее

Практические политики retention для разных ролей серверов

Веб-сервер/приложение

Часто важнее хранить последние 7–14 дней и гарантировать свободное место под базу, кэш и деплои. Рекомендация: лимит по объёму + keep-free, а «длинную историю» уносить централизованно (если требуется процессами).

База данных

Базы данных могут генерировать бурст логов при проблемах с диском, WAL или репликацией. Ставьте более жёсткий SystemMaxUse и следите, чтобы journald не конкурировал с БД за место на том же разделе.

Bastion/jump и сервера администрирования

Здесь особенно важны логи ssh и sudo: делайте журнал персистентным и задавайте понятный retention. Для мониторинга подозрительных входов может пригодиться связка PAM и journald: алерты на SSH-логины через PAM и journald.

Типовые проблемы и быстрые диагностики

«После перезагрузки логов нет»

Проверьте Storage= и наличие /var/log/journal. При Storage=volatile история не сохраняется по определению.

«Диск забит, а в /var/log ничего огромного»

Часто виноват journal:

journalctl --disk-usage
sudo du -sh /var/log/journal 2>/dev/null

Если объём большой — внедряйте SystemMaxUse/SystemKeepFree и применяйте vacuum.

«Логи дублируются в /var/log»

Почти всегда это конфликт источников: одновременно включены и чтение journal в rsyslog, и ForwardToSyslog. Выбирайте один маршрут доставки в syslog и фиксируйте его конфигурацией.

«journalctl показывает, а файлы в /var/log пустые»

Это нормально, если syslog-демон не установлен/не запущен или не настроен на запись соответствующих сообщений. В мире systemd journald сам по себе не обязан создавать традиционные файлы.

Мини-чеклист: базовая безопасная настройка journald

1. Решите, нужен ли персистентный журнал: если да — Storage=persistent и каталог /var/log/journal.
2. Задайте ограничения: SystemMaxUse и SystemKeepFree почти всегда обязательны.
3. Если retention задан «в днях» — добавьте MaxRetentionSec, но не отменяйте лимит по объёму.
4. Если нужны текстовые файлы/маршрутизация — подключайте syslog осознанно и исключайте дубли при ForwardToSyslog.
5. Регулярно контролируйте journalctl --disk-usage (хотя бы через мониторинг).

При аккуратной настройке journald становится предсказуемым и удобным источником логов: он не «съедает» диск, хранит историю столько, сколько нужно, и при необходимости отдаёт события в syslog-цепочку. Главное — один раз зафиксировать политику retention и маршрут доставки, а не оставлять продакшен на поведении «по умолчанию».