From journald to Syslog: 4 Ways to Forward systemd Journal Logs

Modern Linux distributions use systemd journald as their primary local logging system. Unlike traditional Syslog, journald stores events in binary, indexed journal files and preserves a rich set of structured metadata.

At the same time, many SIEM platforms, log collectors, and security monitoring systems still rely on Syslog as a standard format for centralized log ingestion.

That creates a common requirement for security and infrastructure teams: how do you reliably forward journald logs from Linux hosts to a remote Syslog receiver?

The important detail is that journald itself is primarily a local logging service. Simply enabling ForwardToSyslog=yes does not send logs to a remote SIEM. A local Syslog daemon or dedicated log collector still has to receive the events and handle network delivery.

This guide explains four approaches to forwarding journald logs to Syslog:

• Local hand-off using ForwardToSyslog
• rsyslog with imjournal and omfwd
• syslog-ng with the systemd-journal() source
• NXLog Agent with the im_systemd input module

We will also cover metadata preservation, reliable delivery, TLS, buffering, rate limiting, and practical verification steps before putting a journald-to-Syslog pipeline into production.

Quick Answer: How Do You Forward journald to Syslog?

There are two fundamentally different approaches.

First, journald can hand messages to a local Syslog daemon using:

[Journal] ForwardToSyslog=yes

However, this only forwards messages to the local Syslog socket. It does not provide remote delivery by itself.

The second approach is to use a collector that reads the journal API directly and generates Syslog messages for a remote destination. Common options include:

• rsyslog with the imjournal input module
• syslog-ng with the systemd-journal() source
• NXLog Agent with the im_systemd input module

For production environments, the collector-based approach provides considerably more control over transport, filtering, buffering, encryption, metadata, and failure handling.

What Is the Difference Between journald and Syslog?

journald and traditional Syslog differ in how they store, structure, and transport events. Understanding these differences is important when designing a reliable forwarding pipeline.

Aspect	systemd journal	Syslog
Storage	Binary, indexed journal files	Traditionally plain-text, line-oriented messages
Structure	Typed key-value journal fields such as SYSTEMD_UNIT, PID, and UID	Free-text messages; RFC 5424 also supports structured data
Network transport	No native Syslog network transport	UDP/TCP and TLS-based transport
Read access	journalctl and the journal API	Text processing tools and SIEM/collector interfaces

For SecOps teams, the most important difference is metadata.

A journald event can contain significantly more information than a traditional Syslog line, including the systemd unit, process ID, user ID, boot ID, security context, executable path, and other fields.

A good forwarding architecture should preserve as much of this context as possible instead of reducing every event to a single message string.

Why journald Alone Does Not Send Logs to a Remote SIEM

systemd journald is designed primarily as a local logging service. It provides mechanisms for handing events to other components, but those mechanisms do not turn journald into a general-purpose remote Syslog client.

ForwardToSyslog

ForwardToSyslog=yes copies messages to the local socket:

/run/systemd/journal/syslog

A local Syslog daemon must listen on that socket and take responsibility for subsequent processing and network delivery.

If no process consumes the socket, enabling ForwardToSyslog does not send anything off the host.

ForwardToSocket

journald can also forward entries to another socket, but the format is the systemd Journal Export Format rather than standard Syslog.

This makes it unsuitable when the receiving system specifically expects RFC 3164 or RFC 5424 Syslog.

For centralized security monitoring, a dedicated log collector is therefore usually the more flexible architecture.

4 Ways to Forward journald to Syslog

Method 1: Local Forwarding with ForwardToSyslog

This is the simplest approach when a Syslog daemon is already installed on the Linux host and you only need journald to hand events over locally.

Create a journald drop-in configuration:

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

Restart journald:

$ sudo systemctl restart systemd-journald

There are several important limitations.

• The destination is the local Syslog socket, not a remote SIEM.
• The setting is not a replacement for a Syslog collector.
• Journal-specific metadata may not survive the conversion into a traditional Syslog message.
• The local Syslog daemon must be configured separately for remote delivery.

Best suited for: simple Linux hosts where an existing Syslog daemon handles all subsequent processing and forwarding.

Method 2: rsyslog with imjournal and omfwd

rsyslog can read journald directly using the imjournal input module and forward the resulting messages using omfwd.

A production-oriented example is:

# /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") }

Restart rsyslog after applying the configuration:

$ sudo systemctl restart rsyslog

Watch the imjournal rate limit

One of the most important operational considerations is the rate limit applied by imjournal.

A busy Linux host can generate a large number of journal entries, especially when containers or high-volume applications are involved. If the configured rate limit is exceeded, rsyslog can begin dropping messages.

For this reason, configure both the burst and interval according to the actual event volume of the host rather than relying on defaults.

Use persistent state

The StateFile stores the collector's position in the journal. It should therefore reside on persistent storage and be included in the host's operational and backup considerations.

Choose the correct TCP framing

When sending Syslog over TCP, octet-counted framing is generally preferable for messages that may contain multiline content. The sender and receiver must use compatible framing.

For encrypted delivery, rsyslog can additionally be configured with an appropriate TLS network stream driver and certificates.

Method 3: syslog-ng with the systemd-journal() Source

syslog-ng provides a dedicated systemd-journal() source for reading journald events and forwarding them to a remote destination.

For example:

# /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); };

Restart the service:

$ sudo systemctl restart syslog-ng

The prefix(".SDATA.journald.") setting is particularly useful because journal fields can be mapped into RFC 5424 structured data rather than being discarded during conversion.

However, validate the supported syslog-ng version and operating system combination before standardizing this architecture across a large fleet. Source availability and behavior can vary between releases and distributions.

Method 4: NXLog Agent with the Systemd Input Module

NXLog Agent provides native journald collection through the im_systemd input module. This approach is particularly useful when Linux and Windows systems are part of the same security monitoring environment.

The module reads systemd journal entries and exposes their metadata as event fields. These fields can then be filtered, transformed, enriched, serialized, or converted into Syslog.

A minimal configuration for forwarding journal events as BSD Syslog over TCP is:

<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>

Production configuration: RFC 5424, TLS and persistent buffering

For production environments, the forwarding pipeline can be extended with RFC 5424 output, TLS encryption and persistent queues:

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>

Why NXLog Agent is useful for SecOps

Journal metadata can be preserved. NXLog Agent exposes journal fields as event fields, allowing organizations to retain useful context such as the systemd unit, user, process and boot information.

RFC 5424 output is supported. The to_syslog_ietf() procedure converts the event into IETF Syslog format and can use event fields as structured data.

Persistent buffering protects against destination outages. With PersistLogqueue TRUE, queued events can be persisted to disk so that a temporary SIEM or network outage does not automatically become a permanent telemetry gap.

Filtering can happen at the source. For example, debug-level events can be filtered before they consume network bandwidth and SIEM ingestion capacity.

The same collection layer can cover multiple operating systems. NXLog Agent can collect Windows Event Logs, Linux journals, files, network sources and other event types using the same configuration model.

For larger environments, NXLog Platform provides centralized agent configuration and monitoring, reducing the need to manage individual configuration files manually across the fleet.

Which Method Should You Use?

Capability	ForwardToSyslog	rsyslog	syslog-ng	NXLog Agent
Remote delivery	No, local socket only	Yes	Yes	Yes
RFC 5424 output	Depends on local daemon	Yes	Yes	Yes
TLS transport	N/A	Yes, with appropriate network driver configuration	Yes	Yes
Journal metadata	Limited	Partially, depending on templates	Yes, through structured data	Yes, through event fields and structured data
Persistent buffering	No	Yes	Yes	Yes
Centralized fleet management	No	No	No	Yes, with NXLog Platform
Cross-platform collection	No	Primarily Unix/Linux focused	Cross-platform	Yes

For a single Linux server that already uses rsyslog or syslog-ng, either daemon can provide a practical journald-to-Syslog pipeline.

For larger and more heterogeneous environments, NXLog Agent provides a broader collection layer: native journal ingestion, structured event processing, persistent buffering, encrypted delivery, and support for multiple operating systems within the same agent architecture.

Hardening Your journald-to-Syslog Pipeline

Choosing a collector is only part of the problem. journald itself can discard messages before the forwarding agent ever receives them.

For environments where log completeness is important, explicitly configure persistent storage and review journald rate limits:

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

Monitor journald rate limiting

If an application exceeds the configured burst, journald can discard excess messages. A downstream collector cannot recover events that never entered the journal.

Monitor the host for journal suppression messages and size the limits according to the busiest legitimate workloads.

Prefer TCP or TLS for critical logs

UDP Syslog provides no delivery guarantee. For security telemetry, TCP or TLS is generally more appropriate when the receiving infrastructure supports it.

When using TCP, ensure the sender and receiver agree on message framing. For encrypted transport, use TLS with properly managed certificates.

Buffer events at the sender

SIEM maintenance, network interruptions and collector failures are inevitable operational scenarios. Sender-side disk buffering turns many of these events from permanent telemetry gaps into temporary delivery delays.

Options include rsyslog disk-assisted queues, syslog-ng disk buffers, and persistent NXLog Agent log queues.

Filter unnecessary noise before transmission

Filtering low-value events at the source can reduce network traffic and SIEM ingestion costs while keeping the original journal available locally for troubleshooting and forensic analysis.

How to Verify journald-to-Syslog Forwarding

Always test the complete path rather than assuming that a running collector means that the pipeline works.

Start by generating a unique test event:

# Generate a test event $ logger -t fwd-test -p auth.notice "journald to syslog pipeline check $(date +%s)" # Confirm the event exists in journald $ journalctl -t fwd-test -n 3 --no-pager

Next, verify that traffic is leaving the host.

# Plain 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

Finally, search for the event on the receiving SIEM or Syslog collector.

If the event exists in journald but never reaches the receiver, investigate the pipeline in sequence:

1. Is the collector service running?
2. Can the collector read the journal?
3. Has a rate limit caused events to be discarded?
4. Is the journal state/cursor configured correctly?
5. Is the forwarding route configured correctly?
6. Is the network path available?
7. Does the receiver accept the selected Syslog format and framing?
8. For TLS, are certificates and trust relationships configured correctly?

Multiline messages that arrive truncated or merged often indicate a framing mismatch. Incorrect timestamps can indicate a mismatch between local-time RFC 3164 output and a receiver expecting UTC or RFC 5424.

FAQ: Forwarding journald to Syslog

Does journald support remote Syslog forwarding by itself?

Not in the same way as a dedicated Syslog collector. ForwardToSyslog=yes hands messages to a local Syslog socket. A separate daemon or agent must perform remote delivery.

Should I use rsyslog or syslog-ng to forward journald?

Both can read journald directly and forward messages to remote collectors. The choice depends on your existing Linux tooling, required metadata handling, buffering, transport and operational model.

What is the advantage of NXLog Agent?

NXLog Agent combines native journald collection with event processing, Syslog conversion, TLS transport and persistent buffering. It can also collect logs from other operating systems and sources, which can simplify the architecture in heterogeneous environments.

Does forwarding journald to Syslog preserve all journal metadata?

Not automatically. Traditional Syslog messages have a more limited structure. Collectors such as syslog-ng and NXLog Agent can map journal fields into structured data, while JSON can be used when the receiving platform supports richer payloads.

Why is buffering important?

Without sender-side buffering, a temporary SIEM, network or collector outage can result in permanent gaps in security telemetry. Persistent disk-backed queues allow the collector to retain events and forward them when connectivity is restored.

Conclusion: Build a Reliable journald-to-Syslog Pipeline

systemd journald and Syslog serve different purposes. journald provides structured, indexed local logging, while Syslog remains widely used for centralized collection and SIEM integration.

The simplest integration is ForwardToSyslog, but it only provides a local hand-off. rsyslog and syslog-ng provide mature options for organizations already standardized on those technologies.

For heterogeneous environments where Linux and Windows logs need to be managed through a common collection layer, NXLog Agent provides native systemd journal ingestion, structured event processing, Syslog output, TLS delivery and persistent buffering.

Softprom is an official NXLog partner and can help organizations design resilient log collection architectures, configure NXLog Agent and integrate Linux and Windows telemetry with SIEM and security monitoring platforms.

Contact Softprom to discuss your log collection requirements and find the right NXLog architecture for your environment.