Rsyslog: The syslogseverity-text property should have special comparison rules

Created on 21 Apr 2016  路  5Comments  路  Source: rsyslog/rsyslog

Scenario: I have a program that logs to syslog, and I want to collect its log messages in a separate log file. I also want to filter by syslog severity. It uses the user facility, so I can't just use:

user.debug    /var/log/my-program.log

If I did that, I'd sort all user-facility messages into that logfile. So I write the following:

if $programname == "my-program" then /var/log/my-program.log

That works. Now I want to filter out severities below "notice", which is 5 in the numeric syslog severity values. I could write:

if $programname == "my-program" and $syslogseverity <= 5 then /var/log/my-program.log

Great; that works. But the number 5 in there is far from ideal. Every time I look at this line, I'm going to have to look up a table of syslog severity values to find out what 5 represents, because I don't keep that table in my head. So I look in the documentation: http://www.rsyslog.com/doc/v8-stable/configuration/properties.html says that there's a syslogseverity-text property. Great! I'll use that. So my config line becomes:

if $programname == "my-program" and $syslogseverity-text <= "notice" then /var/log/my-program.log

Oops! That doesn't do what I want! It's doing a simple string comparison on the word "notice". And the word "warning" is _greater than_ "notice", but the word "debug" is _less than_ notice. So all the warning messages my program logs (which I want to see) don't end up in my-program.log, but all the debug messages that I was trying to ignore _do_ end up in my-program.log.

In the context of syslog priorities, comparing them by string value is _not useful_, and you really want to compare them by the numeric value they represent.

I suggest that when someone compares the syslogseverity-text property to a string that represents a valid syslog severity name, it should have special comparison rules applied. Instead of comparing strings as with most other properties, both the property and the value it's being compared to should be converted to a severity _number_ and the numbers compared instead.

Without this feature, I'm forced to write if $syslogseverity <= 5 when what I really _want_ to write is if $syslogseverity-text <= "notice" (which I want to have the same effect as $syslogseverity <= 5). This adds an extra maintenance burden to the next sysadmin to look at this file (which might well be me six months from now), as he will have to look up which severity has the value 5.

Most helpful comment

another way of doing this is:

if $programname == "my-program" then {
*.notice /var/log/my-program.log
}

don't forget that the old style filters still work even in the new versions.

All 5 comments

Alternately, if some constants could be defined for syslog severity values, that would help too. Then I could write:

if $programname == "my-program" and $syslogseverity <= LOG_NOTICE then /var/log/my-program.log

That would also eliminate the maintenance burden on the next sysadmin to read the file, and might be simpler to implement.

There is a specific function for this. I think prifilt() out similar.

another way of doing this is:

if $programname == "my-program" then {
*.notice /var/log/my-program.log
}

don't forget that the old style filters still work even in the new versions.

Found this issue while searching for the right and modern syntax to a similar problem.

You could write:

if ( $programname == "my-program" and prifilt("*.notice") ) then {
    action(type="omfile" file="/var/log/my-program.log")
}

Here's a real example from my custom haproxy log config running on a Fedora 29 OS:

/etc/rsyslog.d/49-haproxy.conf:

module(load="imudp") # just once

ruleset(name="localudp"){
  if ( $programname == "haproxy" and prifilt("local2.*") ) then {
    action(type="omfile" file="/var/log/haproxy.log" flushOnTXEnd="off")
  }
}

input(type="imudp" address="127.0.0.1" port="514" ruleset="localudp")

/etc/haproxy/haproxy.cfg:

global
  log 127.0.0.1 format rfc5424 local2
  etc...

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

Was this page helpful?
0 / 5 - 0 ratings