Author : Adiscon Support

rsyslog 6.3.4 (devel) released

This release brings bugfixes and further improvements to the rule engine. Most importantly, the (scoped, RainerScript-based) action object is now available. This enables users to get some early experience with the new system’s advanced features. Note that output plugins must support the new system. With this release, omfile and omusrmsg have been upgraded to support it. The next minor releases will bring more output module support for scoped actions.

Documentation for the new capabilities is upcoming at http://www.rsyslog.com/doc/node1.html

ChangeLog:

http://www.rsyslog.com/changelog-for-6-3-4-v6-devel/

Download:

http://www.rsyslog.com/rsyslog-6-3-4-devel/

As always, feedback is appreciated.

Best regards,

Florian Riedl

rsyslog 6.3.1 (devel) released

This is a first implementation of a full-blown DNS cache. While there were some optimizations for DNS queries in older releases, especially UDP sometimes suffered under slow DNS resolution performance.

This is solved with the new dnscache module. Note that the module will undergo some more enhancements in the next couple of weeks. Feedback on its effect would be deeply appreciated.

ChangeLog:

http://www.rsyslog.com/changelog-for-6-3-1-devel/

Download:

http://www.rsyslog.com/rsyslog-6-3-1-devel/

As always, feedback is appreciated.

Best regards,
Florian Riedl

Log normalization and the leading space

Log normalization is simple, but has its quirks. A common pitfall is syslog message format as induced by RFC3164. Let’s look at a common case:  A log message has been sent to rsyslog. The message itself had no irregular characters. But, the message that should have been parsed by mmnormalize now has a leading space character. Basically, the message that should be parsed looks like this:

This is a test

Usually, one would think, that a simple parser can be used here. You might be correct, but there is a small caveat about this. The rulebase entry we currently have looks something like this:

rule=:%word1:word% %word2:word% %word3:word% %word4%

But strangely, rsyslog responds the following:

mmnormalize generated: {“originalmsg”: ” This is a test″, “unparsed-data”: ” This is a test″}

How comes, that rsyslog cannot parse the message? Why is there a leading space character in from of the message? The answer is, that messages are processed as RFC3164. In this RFC it is defined, that everything after the “:” of the syslog header is to be considered as the message. Thus, the message has a leading space now.

How is this to be solved? Simply insert the space to your rules in the rulebase. This will lead to a rule like this:

rule=: %word1:word% %word2:word% %word3:word% %word4%

Please note, that there has just the space character been added. Further, this is really only a example. The rule will fit to all messages that are 4 words long, so it is really not very suitable to be adopted to your configuration.

rsyslog 6.3.0 (devel) released

The release of rsyslog 6.3.0 introduces a new major feature. With this release we introduce a new config system. You can find some information about the new config system in Rainer’s blog:

http://blog.gerhards.net/2011/06/new-rsyslog-config-system-materializes.html

ChangeLog:

http://www.rsyslog.com/changelog-for-6-3-0-devel/

Download:

http://www.rsyslog.com/rsyslog-6-3-0-devel/

As always, feedback is appreciated.

Best regards,
Florian Riedl

Scroll to top