Use this documentation with care! It describes
the outdated version 7, which was actively
developed around 2014 and is considered dead by the
This documentation reflects the latest update of the v7-stable branch. It describes the 7.6.8 version, which was never released. As such, it contains some content that does not apply to any released version.
To obtain the doc that properly matches your installed v7 version, obtain the doc set from your distro. Each version of rsyslog contained the version that exactly matches it.
As general advise, it is strongly suggested to upgrade to the current version supported by the rsyslog project. The current version can always be found on the right-hand side info box on the rsyslog web site.
Note that there is only limited rsyslog community support available for the outdated v7 version (officially we do not support it at all, but we usually are able to answer simple questions). If you need to stick with v7, it probably is best to ask your distribution for support.
imjournal: Systemd Journal Input Module¶
Module Name: imjournal
Author: Milan Bartos <firstname.lastname@example.org> (This module is not project-supported)
Available since: 7.3.11
Provides the ability to import structured log messages from systemd journal to syslog.
Note that this module reads the journal database, what is considered a relativly performance-intense operation. As such, the performance of a configuration utilizing this module may be notably slower then when using imuxsock. The journal provides imuxsock with a copy of all “classical” syslog messages, however, it does not provide structured data. Only if that structured data is needed, imjournal must be used. Otherwise, imjournal may simply be replaced by imuxsock, and we highly suggest doing so.
We suggest to check out our short presentation on rsyslog journal integration to learn more details of anticipated use cases.
Warning: Some versions of systemd journal have problems with database corruption, which leads to the journal to return the same data endlessly in a thight loop. This results in massive message duplication inside rsyslog probably resulting in a denial-of-service when the system ressouces get exhausted. This can be somewhat mitigated by using proper rate-limiters, but even then there are spikes of old data which are endlessly repeated. By default, ratelimiting is activated and permits to process 20,000 messages within 10 minutes, what should be well enough for most use cases. If insufficient, use the parameters described below to adjust the permitted volume. It is strongly recommended to use this plugin only if there is hard need to do so.
This is a global setting. It specifies how often should the journal state be persisted. The persists happens after each number-of-messages. This option is useful for rsyslog to start reding from the last journal message it read.
This is a global setting. It specifies where the state file for persisting journal state is located.
ratelimit.interval seconds (default: 600)
Specifies the interval in seconds onto which rate-limiting is to be applied. If more than ratelimit.burst messages are read during that interval, further messages up to the end of the interval are discarded. The number of messages discarded is emitted at the end of the interval (if there were any discards). Setting this to value zero turns off ratelimiting. Note that it is not recommended to turn of ratelimiting, except that you know for sure journal database entries will never be corrupted. Without ratelimiting, a corrupted systemd journal database may cause a kind of denial of service (we are stressing this point as multiple users have reported us such problems with the journal database - information current as of June 2013).
ratelimit.burst messages (default: 20000)
Specifies the maximum number of messages that can be emitted within the ratelimit.interval interval. For futher information, see description there.
This option specifies whether imjournal should ignore messages currently in journal and read only new messages. This option is only used when there is no StateFile to avoid message loss.
- As stated above, a corrupted systemd journal database can cause major problems, depending on what the corruption results in. This is beyond the control of the rsyslog team.
- imjournal does not check if messages received actually originated from rsyslog itself (via omjournal or other means). Depending on configuration, this can also lead to a loop. With imuxsock, this problem does not exist.
Development headers for systemd, version >= 197.
The following example shows pulling structured imjournal messages and saving them into /var/log/ceelog.
module(load="imjournal" PersistStateInterval="100" StateFile="/path/to/file") #load imjournal module module(load="mmjsonparse") #load mmjsonparse module for structured logs template(name="CEETemplate" type="string" string="%TIMESTAMP% %HOSTNAME% %syslogtag% @cee: %$!all-json%\\n" ) #template for messages action(type="mmjsonparse") action(type="omfile" file="/var/log/ceelog" template="CEETemplate")
Legacy Configuration Directives:
Equivalent to: PersistStateInterval
Equivalent to: StateFile
Equivalent to: ratelimit.interval
Equivalent to: ratelimit.burst
Equivalent to: ignorePreviousMessages