LoggingThe Ultimate Guide

your open-source resource for understanding, analyzing, and troubleshooting system logs

curated byloggly


Centralizing with Syslog

The syslog protocol is often useful for sending logs to external locations such as log management systems or legacy systems. However, since syslog is text-based and the systemd journal is in binary format, there is no simple one-to-one relationship between these two.

Using ForwardToSyslog

Syslog is still part of Linux distributions that incorporate systemd natively, and as we saw before, journal events can be forwarded to syslog with a simple configuration change. That means journal events can be sent over syslog, provided we have:

  • The systemd-journald service running in the source machine
  • The rsyslogd daemon running in the source machine
  • The forwardtosyslog parameter set to “yes” in /etc/systemd/journald.conf
  • The maxlevelsyslog parameter set to “debug” in /etc/systemd/journald.conf

Using imjournal

Also, rsyslog has an input module that can import structured journal data into the systemd journal. This module is called imjournal. There is another import module called imuxsock that imports journal data into the syslog. The difference between the two is that imuxsock imports unstructured journal data, whereas imjournal import structured event messages.

The first few lines of /etc/rsyslog.conf file of a vanilla CentOS 7 installation shows the module is already included:

More information about the module can be found here.

Reviewing Syslog Output

To see how journal events are recorded in syslog, the following command was run in an Ubuntu 15.04 system:

This showed three error messages from the current boot:

To check if these messages also exist in syslog, the following query looks at the /var/log/syslog file for the last error (shown in bold in the output block above):

The output below shows the message does exist in syslog (with the same time stamp):

In a CentOS 7 system, running the journalctl -b -p err command showed us these messages from the current boot:

Running a query against the /var/log/messages file (syslog) for the first error showed it existed there as well:

Note that the unit name related to the error comes after the date time stamp and the system name field. In this case, it’s the audispd service that encountered an error. The actual error message is then printed.

Although auto redirection of systemd journal messages to syslog seems like a cool feature at first, there are no one-to-one relationships between the fields captured by two. As a result, certain fields from a journal event will be found in its corresponding syslog message, while others won’t be there.

Output in JSON

Journals have rich structured data stored in different fields. For sending journal events to external data consumers that do not understand its native binary format, the data can first be exported to JSON and then transmitted. This is advantageous because JSON format has much wider support from common analysis tools.

Let’s consider the command journalctl -b -p err that we ran in our test Ubuntu system.

One of the output lines was:

Looking at the same error message when we use the –output=json-pretty switch, we have the following output:

The complete list of journal event fields can be found in this man page, but looking at this JSON output we see that only some of the fields map to a syslog message:

  • PRIORITY – This field can have a value between 0 (emerg) and 7 (“debug”). This is compatible with syslog’s concept of priority, although syslog priorities are calculated differently. This is more analogous to syslog’s severity field.
  • SYSLOG_FACILITY – This maps to syslog’s facility field.
  • SYSLOG_IDENTIFIER – This is the syslog identifier string.
  • SYSLOG_PID – This is the client process ID.
  • _PID – This is the id of the process that generated the journal message. In the json block above, we can see the syslog_pid and the _pid fields are both showing the same information.
  • _COMM – This is the name of the process that generated the message. This and other journal fields like _exe or _cmdline are equivalent to the app-name field in a syslog header.
  • _SOURCE_REALTIME_TIMESTAMP – This maps to the timestamp field from a syslog message header.
  • MESSAGE – This is the actual message. It maps directly to the msg field of a syslog entry.
  • _HOSTNAME – This is the name of the originating host. This maps to the hostname field of a syslog message header, although the syslog message hostname can have some extra details.

And then there are journal fields that do not map to syslog. These include:

  • _SYSTEMD_UNIT – This is relevant if the message is coming from a resource unit that supports systemd natively. This is probably the most outstanding piece of information absent from the syslog. However, it’s to be expected because the origin of syslog message format existed long before systemd came along. Also, as we can see, the value of _systemd_unit (cron.service) corresponds to the _comm (and in other cases _exe) field value (cron) and since _comm/_exe fields are equivalent to the app-name in syslog, we are not losing the application or service name that logged the message.
  • _SELINUX_CONTEXT – This is the selinux security context of the process that logged the journal event. This information is absent in a syslog header.
  • CODE_FILE, CODE_LINE, CODE_FUNC – These fields show relevant information from the program code file that’s throwing an error or information message.
  • _TRANSPORT – This field shows how the event record was logged in systemd journal. Possible values can be: driver (for internally generated messages), syslog (messages coming through the syslog socket), journal (messages natively trapped by the journal daemon), kernel (for kernel messages), and stdout (for messages coming from an app or service’s standard output).

Other Methods

For those who want to bypass syslog altogether, they can have a look at works already done by talented developers around the world.

For example, several people have written services that forward journals to a log management solution called SolarWinds® Loggly®. The GitHub project loggly.service from Jose-Luis Rivas creates a custom systemd service that continuously exports events from the journal and sends them to Loggly.

Another GitHub project is journald-forwarder from uswitch.com which uses a slightly more involved method.

Written & Contributed by


This guide will help software developers and system administrators become experts at using logs to better run their systems. This is a vendor-neutral, community effort featuring examples from a variety of solutions

Meet Our Contributors Become a contributor