From d811281650658d99feb66dbb2a2381d99198afc5 Mon Sep 17 00:00:00 2001
From: Rainer Gerhards Description: 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. If the latter is needed, imjournal must be used. Otherwise,
+imjournal may be simply replaced by imuxsock.
+ 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.
-As such, it is strongly recommended to use this plugin only if there
+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
+seconds, 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.
Configuration Directives: Module Directives Legacy Configuration Directives:
+
-
+
+
+
This is a global setting. It specifies how often should the journal state be persisted.
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.
+
+
+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).
+
+
+Specifies the maximum number of messages that can be emitted within the
+ratelimit.interval interval. For futher information, see description there.
+
+
+
+
Caveats/Known Bugs:
+Equivalent to: ratelimit.PersistStateInterval
+Equivalent to: ratelimit.StateFile
+Equivalent to: ratelimit.interval
+Equivalent to: ratelimit.burst
+
Sample:
The following example shows pulling structured imjournal messages and saving them into /var/log/ceelog
-