journald или rsyslog: настраиваем персистентность, rate‑limit и форвардинг

В Linux‑инфраструктуре сегодня почти везде соседствуют два главных игрока: systemd-journald и rsyslog. Первый собирает логи ядра и сервисов, хранит их в бинарных файлах с индексами и умеет ограничивать бурст сообщений. Второй — зрелый, гибкий и расширяемый «конструктор» маршрутизации, трансформации и форвардинга логов в файлы и по сети (UDP/TCP/TLS). Правильный выбор и связка этих инструментов позволяют одинаково уверенно жить как на одиночных серверах, так и в распределённых кластерах.

Эта статья — практический конспект, где без воды настраиваем персистентность для journald, включаем rate‑limit и сравниваем с подходами rsyslog. Затем показываем безопасный и устойчивый форвардинг: локальный (journald → rsyslog) и сетевой (rsyslog → удалённый коллектор; journald → journal‑remote/upload). Завершим чек‑листом и сценариями тестирования, чтобы всё заработало с первого раза и без дублей в логах.

Когда использовать journald, а когда rsyslog

journald — компонент systemd, собирающий логи с единым структурированным контекстом (unit, PID, cgroup, приоритет, capabilities, аудит и т. д.). Он быстрый, индексированный и умеет сам ограничивать бурсты. Также journalctl даёт мощный интерактивный поиск и фильтрацию по unit/uid/PID/boot и времени. Однако сетевой форвардинг у него не «из коробки» — для этого есть отдельные сервисы systemd-journal-remote и systemd-journal-upload.

rsyslog — гибкий маршрутизатор и процессор логов со множеством модулей. Он пишет в файлы, фильтрует по facility/severity, работает по UDP/TCP/TLS, масштабируется с очередями и дисковыми «спулами», умеет шаблоны, парсинг и доставку в БД, очереди сообщений и внешние хранилища. Он нативно говорит на языках syslog‑мира и отлично подходит в роли центрального узла при форвардинге.

Коротко: если нужен быстрый локальный сбор с удобным просмотром — начинайте с journald. Если требуется богатая маршрутизация, сетевые протоколы и интеграции — подключайте rsyslog. На практике оба инструмента часто работают вместе: journald — точки сбора, rsyslog — маршрутизация и доставка.

Персистентность journald

По умолчанию некоторые дистрибутивы хранят журналы только в оперативной памяти (runtime). После ребута вы теряете историю. Чтобы включить персистентность на диск, достаточно прописать режим и задать лимиты.

Шаг 1. Включаем хранение на диск

sudo mkdir -p /var/log/journal
sudo chown root:systemd-journal /var/log/journal
sudo chmod 2755 /var/log/journal
sudo cp /etc/systemd/journald.conf /etc/systemd/journald.conf.backup
sudo editor /etc/systemd/journald.conf

В секции [Journal] укажите:

[Journal]
Storage=persistent
SystemMaxUse=2G
SystemMaxFileSize=256M
RuntimeMaxUse=512M
MaxRetentionSec=30day
Compress=yes
Seal=yes

Пояснения:

• Storage=persistent — хранить на диске в /var/log/journal.
• SystemMaxUse и SystemMaxFileSize ограничивают общий размер и размер одного файла.
• RuntimeMaxUse ограничивает объём in‑memory журнала (актуально дополнительно к дисковому).
• MaxRetentionSec — время хранения (можно задавать в днях/часах).
• Compress и Seal — сжатие и криптографическая целостность сегментов.

sudo systemctl restart systemd-journald
journalctl --disk-usage

journalctl --disk-usage покажет текущий реальный объём на диске. Для принудительной уборки используйте journalctl --vacuum-time=30d или --vacuum-size=1G.

Rate‑limit в journald

По умолчанию journald ограничивает бурст: RateLimitIntervalSec=30s и RateLimitBurst=1000. Это спасает от лог‑шторма при падениях или болтливых демонах. Поведение настраивается в /etc/systemd/journald.conf:

[Journal]
RateLimitIntervalSec=10s
RateLimitBurst=2000

Если вам принципиально не нужны лимиты (например, на стенде), можно отключить, установив RateLimitIntervalSec=0. На продакшене лучше сохранять разумные значения, особенно на узлах с высокой плотностью сервисов.

Форвардинг из journald

Есть два подхода:

• Локально в rsyslog через ForwardToSyslog=yes. journald отправляет копии, а rsyslog уже маршрутизирует.
• Непосредственно в удалённый журнал через связку systemd-journal-upload → systemd-journal-remote.

Локально в rsyslog. В journald.conf включите:

[Journal]
ForwardToSyslog=yes

И перезапустите systemd-journald. На стороне rsyslog используйте модуль imjournal, чтобы забирать из системного журнала без дубликатов (подробнее — ниже).

Удалённо через journal‑remote (вариант для сегрегированных сред, где хочется сохранять формат и метаданные journald):

• На приёмнике: systemd-journal-remote поднимает HTTP(S) endpoint.
• На отправителе: systemd-journal-upload «заливает» ленты на приёмник.

# приёмник
sudo systemctl enable --now systemd-journal-remote
# по умолчанию слушает порт 19532 (HTTP)

# отправитель (клиент)
sudo systemctl enable --now systemd-journal-upload
# укажите URL приёмника в /etc/systemd/journal-upload.conf:
# [Upload]
# URL=https://log-receiver.example:19532

На продакшене используйте TLS с валидными сертификатами и ограничьте доступ фаерволом. Преимущество этого пути — сохранение всех полей journald и надёжная доставка даже при временных сбоях сети.

Персистентность и устойчивость в rsyslog

rsyslog сам по себе пишет в файлы, но ключ к устойчивости — в очередях (action queues) и дисковых спулах. Это позволяет не терять записи при отключении удалённого приёмника и аккуратно выгребать накопившееся после восстановления связи. Если строите центральный узел, удобно поднять его на изолированном VDS с выделенными ресурсами и диском под спулы.

Базовый скелет конфигурации

Рекомендуется современный синтаксис RainerScript. Ниже — каркас с чтением из journald, записью в локальный файл и подготовкой к форвардингу.

# /etc/rsyslog.d/10-inputs.conf
module(load="imjournal" StateFile="imjournal.state" RateLimit.Interval="0")
# альтернативно: module(load="imuxsock" SysSock.RateLimit.Interval="0")

# /etc/rsyslog.d/20-formats.conf
template(name="plain" type="string" string="%timegenerated% %hostname% %syslogtag%%msg%\n")

# /etc/rsyslog.d/30-local-logs.conf
if ($syslogseverity-text == "err" or $syslogseverity-text == "crit") then {
  action(type="omfile" file="/var/log/syslog.err" template="plain")
  stop
}
action(type="omfile" file="/var/log/syslog" template="plain")

Смысл блоков:

• imjournal берёт сообщения из journald, что устраняет дубли по сравнению с одновременным ForwardToSyslog и imuxsock.
• Шаблон plain приводит запись к привычному плоскому формату.
• Пример маршрута выделяет ошибки в отдельный файл и прекращает дальнейшую обработку (stop).

Очереди действий (action queues) и дисковый спул

Чтобы переживать отказы сети и всплески нагрузки без потери логов, используйте связку очередей и дискового спула:

# /etc/rsyslog.d/40-forward.conf
module(load="omfwd")

# Пример TCP форвардинга (две цели), с очередями и дисковым спулом
action(
  type="omfwd"
  target="log-collector-1.internal"
  port="6514"
  protocol="tcp"
  template="plain"
  action.resumeRetryCount="-1"
  queue.type="LinkedList"
  queue.filename="fwdq"
  queue.maxdiskspace="1g"
  queue.saveonshutdown="on"
  queue.dequeuebatchsize="100"
  queue.dequeueSlowdown="5"
)
action(
  type="omfwd"
  target="log-collector-2.internal"
  port="6514"
  protocol="tcp"
  template="plain"
  action.resumeRetryCount="-1"
  queue.type="LinkedList"
  queue.filename="fwdq2"
  queue.maxdiskspace="1g"
  queue.saveonshutdown="on"
  queue.dequeuebatchsize="100"
  queue.dequeueSlowdown="5"
)

Пояснения:

• action.resumeRetryCount=-1 — бесконечные попытки при недоступности цели.
• queue.type=LinkedList — надёжная очередь в памяти с возможностью пролива на диск.
• queue.filename и queue.maxdiskspace — параметры дискового спула.
• queue.dequeueSlowdown смягчает рывки потребления сети и CPU.

Для TLS‑доставки добавьте модуль криптографии и укажите сертификаты доверия, чтобы шифровать трафик и проверять приёмник.

# /etc/rsyslog.d/05-tls.conf
module(load="imtcp")
module(load="gtls")
global(
  DefaultNetstreamDriver="gtls"
  DefaultNetstreamDriverCAFile="/etc/ssl/certs/ca-bundle.crt"
)
# приём TCP TLS на стороне сервера:
# input(type="imtcp" port="6514" StreamDriver="gtls" StreamDriverMode="1" StreamDriverAuthMode="x509/name")

На стороне отправителя используйте тот же omfwd с protocol="tcp" — TLS определяется через глобальный DefaultNetstreamDriver и CA. Для публично доверенной цепочки заранее оформите и проверьте SSL-сертификаты. Для балансировки TCP/UDP‑потоков можно поставить Nginx в режиме stream — см. «Балансировка TCP/UDP в Nginx stream» (подробное руководство).

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

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

Подробнее

Rate‑limit в rsyslog

Ограничивать лавину сообщений логичнее на входе, чтобы не перегружать последующие этапы. Варианты:

• imjournal: параметр RateLimit.Interval и RateLimit.Burst. По умолчанию он синхронизируется с настройками journald, но вы можете задать свои.
• imuxsock (сокет syslog): SysSock.RateLimit.Interval и SysSock.RateLimit.Burst.
• imudp (приём UDP): ratelimit.interval и ratelimit.burst прямо в конфигурации входа.

# Примеры тонкой настройки
module(load="imjournal" RateLimit.Interval="10" RateLimit.Burst="2000")
module(load="imuxsock" SysSock.RateLimit.Interval="5" SysSock.RateLimit.Burst="500")
input(type="imudp" port="514" ratelimit.interval="5" ratelimit.burst="2000")

Если важнее замедлить отправку, а не отбрасывать, используйте параметры очередей действия — например, queue.dequeueSlowdown и queue.dequeuebatchsize. Это дозирует поток без потерь.

Избегаем дублей: типовые ловушки

Частая проблема — дублирующиеся записи. Причины типичны:

• Одновременно включены ForwardToSyslog=yes в journald и вход imuxsock в rsyslog, а также imjournal. Получается тройной источник.
• Одни и те же сообщения читаются из разных источников: сокет и журнал.

Безопасные схемы:

• Схема А (рекомендуется): отключить ForwardToSyslog и читать только через imjournal. Так вы получаете один консистентный источник и все метаданные от journald.
• Схема Б: включить ForwardToSyslog, но не грузить imjournal. Тогда rsyslog получит поток через сокет.

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

Проверки и отладка

Не трогаем продакшен без быстрой проверки на стенде. Минимальные шаги:

• Проверка rsyslog: sudo rsyslogd -N1 — валидируйте конфиг перед systemctl restart rsyslog.
• Проверка journald: journalctl --disk-usage, journalctl -f, journalctl -u ИМЯ_ЮНИТА, journalctl -b -1 (предыдущая загрузка).
• Генерация теста: logger -p user.info "ping", logger -p daemon.err "boom", смотрим, куда ушло по правилам маршрутизации.
• Сеть: для UDP/TCP‑приёмников используйте ss -lntup и убедитесь, что порт слушается, фаервол пропускает, а маршруты активны. При необходимости фиксируйте пакетный трафик средствами мониторинга.

Практические профили настроек

Одиночный сервер (минимум усилий)

Включите Storage=persistent, задайте разумные лимиты по размеру и ретенции, оставьте дефолтные rate‑limits. В rsyslog читайте через imjournal, запишите в пару файлов с разделением по важности. Форвардинг можно не включать.

Небольшой пул серверов

Оставьте journald персистентным, читайте им через imjournal, в rsyslog включите форвардинг в центральный узел по TCP, добавьте дисковый спул и бесконечные ретраи. На приёмнике поднимите imtcp с TLS и разложите логи по файлам/правилам. Rate‑limit на входах imudp/imuxsock включите умеренный, чтобы защититься от бурстов.

Высоконагруженный кластер

Усилите rate‑limit в journald и на входах rsyslog. Разделите очереди и правила по типам сообщений (разные queue.filename), ограничьте queue.maxdiskspace, добавьте мониторинг заполнения диска. На сетевом уровне используйте TCP+TLS и планируйте ротацию и ретенцию исходя из пропускной способности и SLA по восстановлению.

FAQ: короткие ответы на насущные вопросы

• journald бинарный, как выгрузить в текст? journalctl -o short-iso -u nginx > nginx.log или -о json для структурированного вывода.
• Можно ли полностью отключить rsyslog? Да, если достаточно journald и вы не используете классические syslog‑приёмники/протоколы. Но для сетевой маршрутизации удобнее rsyslog.
• Почему пропадают сообщения? Проверьте rate‑limit в journald и входных модулях, а также переполнение очередей/дисковых спулов. Смотрите логи самого rsyslog.
• Как избежать дублей? Выберите один вход: imjournal без ForwardToSyslog ИЛИ ForwardToSyslog без imjournal.

Чек‑лист внедрения

• Включена персистентность journald и заданы лимиты по объёму и времени.
• Определена схема без дублей: либо imjournal, либо ForwardToSyslog.
• В rsyslog настроены очереди действий и дисковый спул.
• Rate‑limit выставлен на входах (imjournal/imuxsock/imudp) в соответствии с профилем нагрузки.
• Форвардинг использует TCP/TLS, проверены сертификаты и фаервол.
• Конфиг валиден: rsyslogd -N1, тесты через logger проходят, назначения файлов/правил подтверждены.
• Мониторинг следит за диском, очередями и доступностью приёмника.

Если подойти системно — задать персистентность, чётко определить единственный вход для rsyslog, включить очереди и разумно настроить rate‑limit — связка journald+rsyslog становится надёжной основой логирования и форвардинга. Вы получаете предсказуемую доставку, отсутствие дублей, контролируемый объём логов и готовность к масштабированию.