systemd-journal-remote: централизуем логи без rsyslog

Когда речь заходит о централизованных логах на Linux, многие по привычке тянутся к rsyslog или целым стекам на базе текстовых файлов. Но если у вас современная система с systemd, логично рассмотреть нативный путь: приёмник systemd-journal-remote и отправитель systemd-journal-upload. В итоге вы получаете бинарный журнал с метаданными, сквозной формат, поиск через journalctl и простую доставку по HTTP(S). В этой статье настроим решение «сервер‑клиенты», включим TLS, поговорим про ротацию и разберём типичную отладку.

Зачем централизовать логи через systemd

Бинарный журнал journald хранит больше контекста, чем обычные текстовые файлы: поля _PID, _UID, _SYSTEMD_UNIT, _MACHINE_ID, _HOSTNAME, сведения о капабилити и даже привязку к cgroup. Централизация через journal-remote позволяет собрать эти логи с множества машин в одном месте без преобразования в текст и без дополнительных агентов. Ключевые плюсы:

• Единый формат от источника до приёмника, без парсеров.
• Сохранение всех метаданных journald, удобный поиск journalctl.
• Простая доставка по HTTP(S), возможность включить TLS.
• Пуш‑модель через journal-upload — работает за NAT и в закрытых сетях.

Ограничения тоже есть: это не аналитический стек и не хранилище для «бесконечных» ретеншенов. Но если нужны быстрые централизованные логи для админских задач, инцидентов, аудита и поиска по полям journald — решение прекрасно подходит.

Архитектура: что за что отвечает

Компонентов два:

• systemd-journal-remote — сервис на сервере-приёмнике. Слушает TCP‑порт, принимает записи журнала и складывает их в каталог (обычно /var/log/journal/remote), формируя файлы по машинам.
• systemd-journal-upload — агент на каждой отправляющей машине. Читает локальный journald и пушит записи на удалённый HTTP(S) endpoint приёмника.

По умолчанию systemd-journal-remote в большинстве дистрибутивов слушает порт 19532 (HTTP). Для TLS указываем сертификаты, и клиенты подключаются по https на тот же порт. Конкретный порт вашей сборки можно посмотреть командой для сокета (ниже).

Важно: в экосистеме systemd есть ещё systemd-journal-gatewayd (HTTP‑просмотр локального журнала), он обычно слушает 19531. Не путайте его с journal-remote.

Подготовка сервера-приёмника

Если вы разворачиваете отдельный узел под приём логов, удобно выделить его на изолированном VPS. Можно начать с среднего тарифа и масштабировать по диску и CPU по мере роста числа клиентов — подойдёт VDS.

На сервере нужна установленная утилита systemd-journal-remote (в некоторых дистрибутивах идёт отдельным пакетом). Примеры установки:

# Debian/Ubuntu
apt update
apt install systemd-journal-remote

# RHEL/CentOS/AlmaLinux/Rocky
dnf install systemd-journal-remote

# Fedora
dnf install systemd-journal-remote

Включаем сокет активации и сразу запускаем:

systemctl enable --now systemd-journal-remote.socket
systemctl status systemd-journal-remote.socket
systemctl status systemd-journal-remote.service

Проверим порт (по умолчанию ожидаем 19532):

systemctl cat systemd-journal-remote.socket
ss -ltn sport = :19532

Каталог хранения на приёмнике зачастую создаётся автоматически: /var/log/journal/remote. Если нужно, создайте и задайте права:

install -d -m 2755 -o root -g systemd-journal /var/log/journal/remote

Включаем TLS (односторонняя проверка сервера)

Быстрый вариант: делаем серверный сертификат и ключ, а на клиентах доверяем этому сертификату (или соответствующему CA). Для тестов сойдёт самоподписанный, в продакшене лучше использовать нормальный CA и автоматизацию выпуска. При необходимости пригодятся SSL-сертификаты.

# Пример самоподписанного сертификата сервера
openssl req -new -x509 -days 365 -nodes -newkey rsa:2048 -keyout /etc/ssl/private/journal-remote.key -out /etc/ssl/certs/journal-remote.crt -subj "/CN=logs.example.internal"

Пропишем параметры в /etc/systemd/journal-remote.conf:

[Remote]
Seal=true
SplitMode=host
ServerKeyFile=/etc/ssl/private/journal-remote.key
ServerCertificateFile=/etc/ssl/certs/journal-remote.crt
# Если используете собственный CA, укажите его корневой сертификат:
# TrustedCertificateFile=/etc/ssl/certs/ca-journal.crt

Перезапускаем сервис:

systemctl restart systemd-journal-remote.service
systemctl status systemd-journal-remote.service

Разрешите доступ к порту на фаерволе. Например, с nftables или firewalld — правила базовые: открыть входящий TCP на выбранном порту (чаще 19532) только из нужных подсетей.

Ограничение места и ротация на приёмнике

Файлы хранятся в формате journald и ротируются независимо от локального journald. Для каталога remote лимиты обычно задают в конфигурации journal-remote. Типичные параметры: SystemMaxUse, SystemKeepFree, MaxFileSec и пр. Добавьте оверрайд:

# /etc/systemd/journal-remote.conf
[Remote]
SystemMaxUse=50G
SystemKeepFree=10G
MaxFileSec=1month

После изменения перезапустите сервис. Следите за свободным местом: бинарные журналы удобны в поиске, но при большом количестве узлов диски наполняются быстро.

Настройка клиентов-отправителей

На каждой машине-источнике ставим бинарь journal-upload (идёт в пакете systemd-journal-remote или аналогичном). Примеры установки такие же, как для сервера. Далее создаём конфиг:

# /etc/systemd/journal-upload.conf
[Upload]
URL=https://logs.example.internal:19532
# Если сервер использует самоподписанный сертификат — укажите доверенный CA или сам сертификат сервера:
TrustedCertificateFile=/etc/ssl/certs/journal-remote.crt

Запускаем агент и включаем автозапуск:

systemctl enable --now systemd-journal-upload.service
systemctl status systemd-journal-upload.service

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

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

На сервере смотрим последние записи из удалённого хранилища:

journalctl -D /var/log/journal/remote -n 50

Удобно фильтровать по метаданным:

# По имени хоста источника
journalctl -D /var/log/journal/remote _HOSTNAME=app1 -n 100

# По systemd‑юниту
journalctl -D /var/log/journal/remote _SYSTEMD_UNIT=nginx.service -n 100

# По machine-id (уникален для OS-инсталляции)
journalctl -D /var/log/journal/remote _MACHINE_ID=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx -n 100

На клиенте загляните в логи сервиса отправки, если что-то не едет:

journalctl -u systemd-journal-upload -b -n 200

Продвинутый TLS: взаимная аутентификация клиентов (mTLS)

Для сред с повышенными требованиями включают взаимную проверку: сервер доверяет только клиентам с сертификатами от вашего CA, а клиенты проверяют сервер по тому же или другому CA. Базовые шаги:

• Создайте корневой CA и подпишите им сертификаты сервера и клиентов. У каждого клиента — свой ключ и сертификат.
• На сервере укажите свой ServerKeyFile/ServerCertificateFile и TrustedCertificateFile, соответствующий CA, которому вы доверяете для клиентских сертификатов.
• На клиентах укажите TrustedCertificateFile с CA, которым подписан сервер. При необходимости задайте клиентский ключ/сертификат для предъявления серверу (см. опции TLS для journal-upload в вашей версии systemd).

После включения mTLS убедитесь, что время синхронизировано (смещение часов ломает проверку сертификатов), а CN/SAN сертификатов соответствует тому, как клиенты обращаются к серверу. Если хотите автоматизировать выпуск сертификатов и настройку HSTS, посмотрите разбор по теме: настройка Let's Encrypt и HSTS.

Тонкая настройка и эксплуатация

Rate limit и потеря записей

Если на клиентах появляются предупреждения о дропах, проверьте лимиты в /etc/systemd/journald.conf: RateLimitIntervalSec и RateLimitBurst. Для шумных сервисов их иногда увеличивают. Также проверьте нагрузку на приёмнике: CPU, диск, сеть.

Очереди и возобновление

journal-upload отслеживает курсор и при кратковременных разрывах соединения продолжает с последней позиции. Состояние обычно хранится в каталоге данных сервиса (например, в /var/lib). Это не полноценный буфер на дни простоя, но для сетевых «флапов» хватает.

Безопасность и изоляция сервиса

Стандартные unit‑файлы уже неплохо изолированы, но можно усилить оверрайдом. Пример для приёмника: разрешаем запись только туда, где это нужно, и ограничиваем доступ к остальной системе.

systemctl edit systemd-journal-remote.service

[Service]
ProtectSystem=strict
ProtectHome=yes
PrivateTmp=yes
ReadWritePaths=/var/log/journal/remote /etc/ssl/private /etc/ssl/certs
NoNewPrivileges=yes
RestrictAddressFamilies=AF_INET AF_INET6 AF_UNIX
RestrictSUIDSGID=yes
LockPersonality=yes
MemoryDenyWriteExecute=yes

После сохранения — перезапуск и проверка статуса. Аналогичные меры можно применить и к systemd-journal-upload на клиентах.

Разметка хранителя: по узлам или по времени

Опция SplitMode в journal-remote.conf определяет, как дробить файлы: чаще используют SplitMode=host, тогда у каждого хоста свои файлы. Это упрощает поиск и удаление данных по одному источнику.

Поиск и экспорт

Сердце работы — journalctl. Полезные приёмы:

# Последние ошибки по nginx с этого утра (ISO-формат времени)
journalctl -D /var/log/journal/remote _SYSTEMD_UNIT=nginx.service -p err --since "today 06:00" -o short-iso -n 200

# Запрос по нескольким полям: юнит + PID
journalctl -D /var/log/journal/remote _SYSTEMD_UNIT=php-fpm.service _PID=1234 -n 50

# Экспорт в текст с JSON-метаданными
a) в кратком виде: -o short-precise
b) в JSON: -o json
c) JSON с удобными строками: -o json-pretty

Помните, что бинарный формат эффективен для хранения и поиска. Если нужен текст для сторонних утилит, используйте вывод journalctl с нужным форматером. По теме мониторинга входов по SSH на базе journald есть отдельный разбор: уведомления о логинах по SSH через PAM и journald.

Частые ошибки и их диагностика

Пара реальных кейсов из практики:

• «certificate verify failed» на клиентах — не доверен CA или CN/SAN не совпадает с именем узла в URL. Исправляем цепочку доверия, переписываем URL на корректное имя или перевыпускаем сертификат.
• Клиент «молчит» — проверьте фаерволл, порт и, банально, DNS. Команда ss -ltn на сервере и nc -vz с клиента быстро находят проблему с портом.
• Высокая задержка доставки — посмотрите на диск приёмника: бинарные журналы любят быстрые SSD. При множестве клиентов выделите отдельный том под /var/log/journal/remote.
• Часть записей пропадает — на клиентах проверьте RateLimit* и нет ли переполнения локального журнала при длительном даунтайме сети. На сервере проверьте лимиты SystemMaxUse/SystemKeepFree.

Когда это лучше rsyslog (и когда нет)

Если ваши сервисы уже логируют в journald (а при systemd это обычно так), использование journal-upload и journal-remote даёт более бесшовную доставку, чем выкачивание текстовых файлов. Метаданные сохраняются, поиск становится проще, а настройка минимальна. С другой стороны, если у вас уже выстроены пайплайны на текстовых логах, сложные парсеры и трансформации, привычный rsyslog или другие сборщики могут оказаться удобнее.

Планирование ресурсов и эксплуатационные советы

Рассчитывая объём диска на приёмнике, учтите количество источников, среднюю интенсивность логов и желаемый ретеншен. Начните с нескольких десятков гигабайт, включите SystemKeepFree, мониторьте заполнение и корректируйте. По CPU ориентируйтесь на число одновременных клиентов и форматирование при поиске. Сеть обычно не становится узким местом — данные идут инкрементально и сжатые.

Не забывайте о бэкапах приёмника, если журналы представляют ценность для расследований. Бинарные файлы journald копируются как есть, восстанавливаются и читаются командой journalctl -D.

Итоги

systemd-journal-remote и journal-upload — недооценённая связка для централизованных логов: нативный формат journald, простая настройка, понятная доставка по HTTP(S) и отличная совместимость с существующими сервисами под systemd. Для небольших и средних инфраструктур это быстрый способ навести порядок с логами без отдельного зоопарка агентов и парсеров. Запускайте пилот: один приёмник, пара клиентов, включите TLS и посмотрите, как упростится ваша работа с инцидентами и аудитом.