Compatibility Notes for rsyslog v7

This document describes things to keep in mind when moving from v6 to v7. It does not list enhancements nor does it talk about compatibility concerns introduced by earlier versions (for this, see their respective compatibility documents). Its focus is primarily on what you need to know if you used v6 and want to use v7 without hassle.

Version 7 builds on the new config language introduced in v6 and extends it. Other than v6, it not just only extends the config language, but provides considerable changes to core elements as well. The result is much more power and ease of use as well (this time that is not contradictionary).

BSD-Style blocks

BSD style blocks are no longer supported (for good reason). See the rsyslog BSD blocks info page for more information and how to upgrade your config.

[manual index] [rsyslog site]

CEE-Properties

In rsyslog v6, CEE properties could not be used across disk-based queues. If this was done, there content was reset. This was a missing feature in v6. In v7, this feature has been implemented. Consequently, situations where the previous behaviour were desired need now to be solved differently. We do not think that this will cause any problems to anyone, especially as in v6 this was announced as a missing feature.

omruleset and discard (~) action are deprecated

Both continue to work, but have been replaced by better alternatives.

The discard action (tilde character) has been replaced by the "stop" RainerScript directive. It is considered more intuitive and offers slightly better performance.

The omruleset module has been replaced by the "call" RainerScript directive. Call permits to execute a ruleset like a subroutine, and does so with much higher performance than omruleset did. Note that omruleset could be run off an async queue. This was more a side than a desired effect and is not supported by the call statement. If that effect was needed, it can simply be simulated by running the called rulesets actions asynchronously (what in any case is the right way to handle this).

Note that the deprecated modules emit warning messages when being used. They tell that the construct is deprecated and which statement is to be used as replacement. This does not affect operations: both modules are still fully operational and will not be removed in the v7 timeframe.

"last message repeated n times" Processing

This processing has been optimized and moved to the input side. This results in usually far better performance and also de-couples different sources from the same processing. It is now also integrated in to the more generic rate-limiting processing.

User-Noticable Changes

The code works almost as before, with two exceptions:

The supression amount can be different, as the new algorithm precisely check's a single source, and while that source is being read. The previous algorithm worked on a set of mixed messages from multiple sources.
The previous algorithm wrote a "last message repeated n times" message at least every 60 seconds. For performance reasons, we do no longer do this but write this message only when a new message arrives or rsyslog is shut down.

Note that the new algorithms needs support from input modules. If old modules which do not have the necessary support are used, duplicate messages will most probably not be detected. Upgrading the module code is simple, and all rsyslog-provided plugins support the new method, so this should not be a real problem (crafting a solution would result in rather complex code - for a case that most probably would never happen).

Performance Implications

In general, the new method enables far faster output procesing. However, it needs to be noted that the "last message repeated n" processing needs parsed messages in order to detect duplicated. Consequently, if it is enabled the parser step cannot be deferred to the main queue processing thread and thus must be done during input processing. The changes workload distribution and may have (good or bad) effect on the overall performance. If you have a very high performance installation, it is suggested to check the performance profile before deploying the new version. Note: for high-performance environments it is highly recommended NOT to use "last message repeated n times" processing but rather the other (more efficient) rate-limiting methods. These also do NOT require the parsing step to be done during input processing.