How Is rsyslog Used Alongside journald in Modern Linux Environments?

Rsyslog is still widely useful because it speaks the standard syslog protocol and works across very different equipment: Linux and BSD systems, firewalls, routers, switches, hypervisors, and appliances. In larger environments it often acts as a reliable collection and routing layer rather than the final place where people search logs.

For example, rsyslog might receive logs over TCP, UDP, TLS, or RELP, write a local spool or archive, filter out noise, and forward selected events to a SIEM. Redundant collectors can also be deployed behind a virtual IP or failover mechanism. This is especially useful across network boundaries or in compliance-heavy environments where logs need controlled retention and reliable delivery.

The main metadata tradeoff is that traditional syslog gives you facility and severity, while journald adds trusted systemd and process fields, and applications may add their own structured JSON fields. Reading directly from journald can preserve more of that information, but a syslog socket or another forwarder may be faster and simpler.

It is also worth checking for duplicate messages when using multiple paths. If journald forwards to the syslog socket and rsyslog also reads the journal directly, the same event can arrive twice unless the configuration is designed carefully. Pick one primary path for each source, test under load, and make sure queues, rate limits, timestamps, permissions, and failure behavior are understood.

There isn’t one universal architecture. Some organizations use journald for local collection and forward directly with a modern agent, while others keep rsyslog as the standard transport layer. A typical server setup might be stdout or stderr into journald, then journald into rsyslog, followed by filtering and forwarding to centralized storage or analytics.

Rsyslog can also collect file-based logs with imfile, which is useful for applications that write their own files. It is often used to keep only important events, route different facilities to different destinations, and maintain local queues or archives if the central service is temporarily unavailable. Tools such as Fluent Bit, Vector, Alloy, or OpenTelemetry may be preferred when teams need more advanced parsing and cloud-native pipelines, but that does not make rsyslog obsolete.

In compliance and long-retention environments, the important part is usually not which collector is fashionable but whether the pipeline is dependable and auditable. Logs may be separated by purpose: security events go to a SIEM, operational messages go to searchable storage, and certain records go to an archive.

Rsyslog is good at this kind of routing, filtering, queueing, and protocol conversion. It can write files for another indexer to process, forward only selected messages, and send events to multiple destinations. Storage planning matters a lot when keeping logs for years, so compression, rotation, disk monitoring, and a strategy for outages are just as important as the input module.

A common modern pattern is applications writing to stdout or stderr, systemd collecting those messages in journald, and rsyslog reading or forwarding them to a central destination. Rsyslog can send logs to a traditional log server, a SIEM, Graylog, Elastic-compatible systems, or another processing agent.

imuxsock is mainly for messages arriving through the traditional local syslog socket, including older software that uses syslog() or /dev/log. imjournal reads through the journald API and can preserve more journal metadata, such as the systemd unit, process ID, user ID, and command name, although it generally has more overhead. The right choice depends on whether richer metadata or maximum simplicity and throughput matters most.