От journald к Syslog: 4 способа пересылки логов systemd Journal

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

В то же время многие SIEM-платформы, коллекторы логов и системы мониторинга безопасности до сих пор полагаются на Syslog как на стандартный формат для централизованного сбора логов.

Это создает распространенную задачу для команд безопасности и инфраструктуры: как надежно пересылать логи journald с хостов Linux на удаленный приемник Syslog?

Важная деталь заключается в том, что сам по себе journald — это преимущественно локальная служба журналирования. Простое включение директивы ForwardToSyslog=yes не отправляет логи на удаленную SIEM. Локальный демон Syslog или выделенный коллектор логов все равно должен принять события и взять на себя их сетевую доставку.

В этом руководстве рассматриваются четыре подхода к пересылке логов journald в Syslog:

• Локальная передача с использованием ForwardToSyslog
• rsyslog с модулями imjournal и omfwd
• syslog-ng с источником systemd-journal()
• NXLog Agent с модулем ввода im_systemd

Мы также рассмотрим вопросы сохранения метаданных, надежной доставки, использования TLS, буферизации, ограничения скорости (rate limiting) и практические шаги по проверке работоспособности перед запуском конвейера journald-to-Syslog в продуктивную эксплуатацию.

Краткий ответ: как переслать journald в Syslog?

Существует два принципиально разных подхода.

Во-первых, journald может передавать сообщения локальному демону Syslog с помощью:

[Journal] ForwardToSyslog=yes

Однако это пересылает сообщения только на локальный сокет Syslog. Само по себе это не обеспечивает удаленную доставку.

Второй подход заключается в использовании коллектора, который считывает данные напрямую через API журнала и генерирует сообщения Syslog для удаленной системы назначения. Популярные варианты включают:

• rsyslog с модулем ввода imjournal
• syslog-ng с источником systemd-journal()
• NXLog Agent с модулем ввода im_systemd

Для продуктивных сред подход на основе коллектора обеспечивает значительно больший контроль над транспортом, фильтрацией, буферизацией, шифрованием, метаданными и обработкой сбоев.

В чем разница между journald и Syslog?

journald и традиционный Syslog различаются способами хранения, структурирования и транспортировки событий. Понимание этих различий важно при проектировании надежного конвейера пересылки.

Аспект	systemd journal	Syslog
Хранение	Бинарные индексированные файлы журналов	Традиционно текстовые построчные сообщения
Структура	Типизированные поля формата «ключ-значение», такие как SYSTEMD_UNIT, PID и UID	Произвольный текст; RFC 5424 также поддерживает структурированные данные
Сетевой транспорт	Нет встроенного сетевого транспорта Syslog	Передача по протоколам UDP/TCP и TLS
Доступ к чтению	Утилита journalctl и API журнала	Инструменты обработки текста и интерфейсы SIEM/коллекторов

Для команд SecOps самым важным различием являются метаданные.

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

Хорошая архитектура пересылки должна сохранять как можно больше этого контекста вместо того, чтобы сводить каждое событие к одной текстовой строке.

Почему сам по себе journald не отправляет логи на удаленную SIEM

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

ForwardToSyslog

Параметр ForwardToSyslog=yes копирует сообщения на локальный сокет:

/run/systemd/journal/syslog

Локальный демон Syslog должен прослушивать этот сокет и брать на себя ответственность за последующую обработку и сетевую доставку.

Если ни один процесс не считывает данные из сокета, включение ForwardToSyslog ничего не отправляет за пределы хоста.

ForwardToSocket

journald также может пересылать записи на другой сокет, но при этом используется формат systemd Journal Export Format, а не стандартный Syslog.

Это делает такой подход неприменимым, если принимающая система ожидает стандартный Syslog RFC 3164 или RFC 5424.

Поэтому для централизованного мониторинга безопасности более гибкой архитектурой обычно является использование выделенного коллектора логов.

4 способа пересылки journald в Syslog

Метод 1: Локальная пересылка с помощью ForwardToSyslog

Это самый простой подход, когда на хосте Linux уже установлен демон Syslog и требуется только, чтобы journald передавал события локально.

Создайте конфигурационный файл drop-in для journald:

# /etc/systemd/journald.conf.d/forward.conf [Journal] ForwardToSyslog=yes

Перезапустите journald:

$ sudo systemctl restart systemd-journald

Существует несколько важных ограничений.

• Целевым назначением является локальный сокет Syslog, а не удаленная SIEM.
• Эта настройка не заменяет коллектор Syslog.
• Специфичные для журнала метаданные могут быть утеряны при преобразовании в традиционное сообщение Syslog.
• Локальный демон Syslog должен быть отдельно настроен для удаленной доставки.

Лучше всего подходит для: простых хостов Linux, где существующий демон Syslog выполняет всю последующую обработку и отправку.

Метод 2: rsyslog с использованием imjournal и omfwd

rsyslog может считывать journald напрямую с помощью модуля ввода imjournal и пересылать полученные сообщения с помощью omfwd.

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

# /etc/rsyslog.d/10-journal-forward.conf module(load="imjournal" StateFile="/var/lib/rsyslog/imjournal.state" Ratelimit.Interval="60" Ratelimit.Burst="60000") if $inputname == "imjournal" then { action(type="omfwd" Target="siem.example.com" Port="514" Protocol="tcp" Template="RSYSLOG_SyslogProtocol23Format" TCP_Framing="octet-counted" queue.type="LinkedList" queue.filename="q_journal_fwd" queue.maxDiskSpace="1g" queue.saveOnShutdown="on" action.resumeRetryCount="-1") }

Перезапустите rsyslog после применения конфигурации:

$ sudo systemctl restart rsyslog

Следите за ограничениями скорости в imjournal

Одно из важнейших операционных соображений — это ограничение скорости (rate limit), применяемое модулем imjournal.

Высоконагруженный хост Linux может генерировать огромное количество записей журнала, особенно при использовании контейнеров или интенсивных приложений. Если настроенный лимит превышен, rsyslog может начать отбрасывать сообщения.

По этой причине настраивайте параметры burst и interval в соответствии с реальным объемом событий на хосте, а не полагайтесь на значения по умолчанию.

Используйте энергонезависимое состояние (StateFile)

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

Выбирайте правильный фрейминг TCP

При отправке Syslog по протоколу TCP для сообщений, которые могут содержать многострочный контент, предпочтительнее использовать фрейминг с подсчетом октетов (octet-counted). Отправитель и получатель должны использовать совместимый фрейминг.

Для зашифрованной доставки rsyslog можно дополнительно настроить с использованием соответствующего драйвера сетевого потока TLS и сертификатов.

Метод 3: syslog-ng с источником systemd-journal()

syslog-ng предоставляет выделенный источник systemd-journal() для чтения событий journald и их пересылки на удаленный приемник.

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

# /etc/syslog-ng/conf.d/journal-forward.conf source s_journal { systemd-journal(prefix(".SDATA.journald.")); }; destination d_siem { syslog("siem.example.com" transport("tls") port(6514) tls( ca-file("/etc/syslog-ng/certs/ca.pem") key-file("/etc/syslog-ng/certs/client-key.pem") cert-file("/etc/syslog-ng/certs/client-cert.pem") ) disk-buffer( capacity-bytes(1073741824) reliable(yes) ) ); }; log { source(s_journal); destination(d_siem); };

Перезапустите службу:

$ sudo systemctl restart syslog-ng

Параметр prefix(".SDATA.journald.") особенно полезен, так как позволяет сопоставлять поля журнала со структурированными данными RFC 5424, а не терять их при конвертации.

Тем не менее, перед стандартизацией этой архитектуры на крупном парке серверов проверьте совместимость используемой версии syslog-ng и операционной системы. Доступность источника и его поведение могут различаться в зависимости от релизов и дистрибутивов.

Метод 4: NXLog Agent с модулем ввода Systemd

NXLog Agent обеспечивает нативный сбор данных из journald через модуль ввода im_systemd. Этот подход особенно удобен, когда системы Linux и Windows входят в единое пространство мониторинга безопасности.

Модуль считывает записи журнала systemd и предоставляет их метаданные в виде полей событий. Эти поля можно фильтровать, преобразовывать, обогащать, сериализовать или конвертировать в Syslog.

Минимальная конфигурация для пересылки событий журнала в формате BSD Syslog по протоколу TCP выглядит следующим образом:

<Extension syslog> Module xm_syslog </Extension> <Input journal> Module im_systemd </Input> <Output siem> Module om_tcp Host siem.example.com:514 Exec to_syslog_bsd(); </Output> <Route journal_to_siem> Path journal => siem </Route>

Конфигурация для продуктивной среды: RFC 5424, TLS и постоянная буферизация

Для продуктивных сред конвейер пересылки можно расширить выводом в формате RFC 5424, шифрованием TLS и постоянными очередями:

define CERTDIR /opt/nxlog/var/lib/nxlog/cert <Extension syslog> Module xm_syslog </Extension> <Extension json> Module xm_json </Extension> <Input journal> Module im_systemd ReadFromLast TRUE Exec if $SeverityValue >= 7 drop(); </Input> <Output siem_tls> Module om_ssl Host siem.example.com:6514 CAFile %CERTDIR%/ca.pem CertFile %CERTDIR%/agent-cert.pem CertKeyFile %CERTDIR%/agent-key.pem OutputType Syslog_TLS PersistLogqueue TRUE <Exec> $Message = to_json(); to_syslog_ietf(); </Exec> </Output> <Route journal_to_siem> Path journal => siem_tls </Route>

Почему NXLog Agent удобен для SecOps

Сохранение метаданных журнала. NXLog Agent предоставляет поля журнала как поля событий, позволяя сохранять полезный контекст, такой как юнит systemd, данные пользователя, процесса и загрузки.

Поддержка формата RFC 5424. Процедура to_syslog_ietf() преобразует событие в формат IETF Syslog и может использовать поля событий в качестве структурированных данных.

Постоянная буферизация защищает от сбоев целевых систем. При включенном PersistLogqueue TRUE очереди событий могут сохраняться на диске, благодаря чему временный сбой SIEM или сети не приведет к потере телеметрии.

Фильтрация на стороне источника. Например, события уровня отладки (debug) можно отфильтровать до того, как они израсходуют пропускную способность сети и лимиты забора данных в SIEM.

Единый уровень сбора для разных операционных систем. NXLog Agent может собирать журналы событий Windows, логи Linux, файлы, сетевые источники и другие типы событий с использованием единой модели конфигурации.

Для крупных инфраструктур платформа NXLog Platform обеспечивает централизованное конфигурирование агентов и мониторинг, исключая необходимость ручного управления отдельными файлами настроек на каждом хосте.

Какой метод выбрать?

Возможность	ForwardToSyslog	rsyslog	syslog-ng	NXLog Agent
Удаленная доставка	Нет, только локальный сокет	Да	Да	Да
Вывод в формате RFC 5424	Зависит от локального демона	Да	Да	Да
Передача по TLS	Н/Д	Да, при соответствующей настройке сетевого драйвера	Да	Да
Метаданные журнала	Ограниченно	Частично, в зависимости от шаблонов	Да, через структурированные данные	Да, через поля событий и структурированные данные
Постоянная буферизация	Нет	Да	Да	Да
Централизованное управление агентами	Нет	Нет	Нет	Да, с помощью NXLog Platform
Кроссплатформенный сбор	Нет	Ориентирован преимущественно на Unix/Linux	Кроссплатформенный	Да

Для одиночного сервера Linux, где уже используется rsyslog или syslog-ng, любой из этих демонов обеспечит рабочий конвейер journald-to-Syslog.

Для более крупных и гетерогенных сред NXLog Agent предлагает более универсальный уровень сбора: нативный забор из журнала, обработку структурированных событий, постоянную буферизацию, шифрованную доставку и поддержку нескольких операционных систем в рамках единой архитектуры агента.

Усиление защиты конвейера journald-to-Syslog

Выбор коллектора — это лишь часть задачи. Сам journald может отбрасывать сообщения до того, как агент пересылки их получит.

Для сред, где критически важна полнота логов, явно настройте энергонезависимое хранение и проверьте ограничения скорости journald:

# /etc/systemd/journald.conf.d/hardening.conf [Journal] Storage=persistent RateLimitIntervalSec=30s RateLimitBurst=50000

Мониторинг ограничений скорости journald

Если приложение превышает настроенный порог (burst), journald может отбросить избыточные сообщения. Никакой нижестоящий коллектор не сможет восстановить события, которые не попали в журнал.

Отслеживайте на хосте сообщения о подавлении записей журнала и настраивайте лимиты с учетом самых нагруженных легитимных процессов.

Используйте TCP или TLS для критически важных логов

Протокол UDP Syslog не дает гарантий доставки. Для телеметрии безопасности предпочтительнее использовать TCP или TLS, если это поддерживается принимающей инфраструктурой.

При использовании TCP убедитесь, что отправитель и получатель согласовали формат фрейминга сообщений. Для зашифрованного транспорта используйте TLS с корректно настроенными сертификатами.

Буферизируйте события на стороне отправителя

Обслуживание SIEM, сетевые сбои и отключения коллекторов — неизбежные операционные сценарии. Дисковая буферизация на стороне отправителя превращает постоянную потерю телеметрии в временную задержку доставки.

Варианты включают дисковые очереди rsyslog, дисковые буферы syslog-ng и постоянные очереди логов NXLog Agent.

Фильтруйте некритичный шум перед передачей

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

Как проверить пересылку journald в Syslog

Всегда проверяйте весь сквозной путь, не ограничиваясь проверкой того, что служба коллектора просто запущенна.

Начните с генерации тестового события с уникальным идентификатором:

# Сгенерируйте тестовое событие $ logger -t fwd-test -p auth.notice "journald to syslog pipeline check $(date +%s)" # Убедитесь, что событие появилось в journald $ journalctl -t fwd-test -n 3 --no-pager

Затем убедитесь, что трафик уходит с хоста.

# Обычный TCP Syslog $ sudo tcpdump -A -c 5 host siem.example.com and port 514 # TLS Syslog $ sudo tcpdump -c 5 host siem.example.com and port 6514

Наконец, найдите это событие на принимающей стороне — в SIEM или на коллекторе Syslog.

Если событие присутствует в journald, но не доходит до приемника, проверьте конвейер по шагам:

1. Запущена ли служба коллектора?
2. Есть ли у коллектора права на чтение журнала?
3. Не привели ли ограничения скорости (rate limiting) к отбрасыванию событий?
4. Корректно ли настроен указатель/состояние журнала (cursor)?
5. Правильно ли настроен маршрут пересылки?
6. Доступен ли сетевой маршрут до приемника?
7. Принимает ли получатель выбранный формат Syslog и фрейминг?
8. Для TLS: правильно ли настроены сертификаты и доверенные цепочки?

Многострочные сообщения, которые приходят усеченными или объединенными, часто указывают на несоответствие настроек фрейминга. Некорректные метки времени могут свидетельствовать о разнице между выводом в локальном времени RFC 3164 и ожиданием приемником времени в UTC или формате RFC 5424.

Часто задаваемые вопросы: пересылка journald в Syslog

Поддерживает ли journald удаленную пересылку в Syslog самостоятельно?

Не так, как это делают специализированные коллекторы Syslog. Директива ForwardToSyslog=yes лишь передает сообщения на локальный сокет Syslog. Для удаленной доставки требуется отдельный демон или агент.

Что лучше использовать для пересылки journald: rsyslog или syslog-ng?

Оба инструмента могут читать journald напрямую и пересылать сообщения на удаленные коллекторы. Выбор зависит от используемых у вас инструментов Linux, требований к обработке метаданных, буферизации, транспорту и принятой операционной модели.

В чем преимущество NXLog Agent?

NXLog Agent сочетает нативный сбор из journald с обработкой событий, конвертацией в Syslog, передачей по TLS и постоянной буферизацией. Он также позволяет собирать логи с других операционных систем и источников, что упрощает архитектуру в гетерогенных средах.

Сохраняются ли все метаданные журнала при пересылке journald в Syslog?

Не автоматически. Традиционные сообщения Syslog имеют более ограниченную структуру. Такие коллекторы, как syslog-ng и NXLog Agent, могут сопоставлять поля журнала со структурированными данными, а также использовать формат JSON, если принимающая платформа поддерживает богатые структуры данных.

Почему важна буферизация?

Без буферизации на стороне отправителя временные сбои SIEM, сети или коллектора приводят к безвозвратным потерям телеметрии безопасности. Постоянные очереди на диске позволяют коллектору удерживать события и отправлять их после восстановления связи.

Заключение: построение надежного конвейера journald-to-Syslog

systemd journald и Syslog служат разным целям. journald обеспечивает структурированное индексированное локальное журналирование, в то время как Syslog остается стандартом для централизованного сбора и интеграции с SIEM.

Самая простая интеграция — это ForwardToSyslog, но она обеспечивает лишь локальную передачу. rsyslog и syslog-ng предлагают проверенные варианты для организаций, где эти технологии уже стандартизированы.

Для гетерогенных сред, где логи Linux и Windows должны управляться через единый уровень сбора, NXLog Agent обеспечивает нативный забор из systemd journal, обработку структурированных событий, вывод в Syslog, доставку по TLS и постоянную буферизацию.

Компания Softprom является официальным партнером NXLog и помогает организациям проектировать отказоустойчивые архитектуры сбора логов, настраивать NXLog Agent и интегрировать телеметрию Linux и Windows с платформами SIEM и мониторинга безопасности.

Свяжитесь с Softprom, чтобы обсудить ваши требования к сбору логов и подбрать оптимальную архитектуру NXLog для вашей среды.