Від journald до Syslog: 4 способи пересилання журналів systemd

Сучасні дистрибутиви 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 для вашого середовища.