Rewriting facility/severity in rsyslog v7 before shipping off to a remote collector

rsyslogsyslogsyslogd

I have a machine "A" with a local rsyslogd, and a remote collector machine "B" elsewhere listening with its own syslog daemon and log processing engine. It all works great…except that there is one process on A that logs at local0.notice, which is something that B's engine can't handle.

What I want to do is rewrite local0.notice to local5.info before the event is shipped off to B. Unfortunately I can't change B and I can't change the way the process does it's logging on A. Nor can I upgrade rsyslogd on A from v7.6 to v8 (which appears to have some very useful-looking features, like mmexternal, which might have helped).

I think I must be missing something obvious, I can't be the first person to need this type of feature. Basically it comes down to finding some way of passing through rsyslog twice with a filter in between: once as the process logs, through the filter to change the prio, and then again to forward it on.

What I've tried:

  • configuring rsyslog to log local0.notice to a file, and then reading that file with an imfile directive that tags it and sets the new fac/sev, followed by an if statement that looks for the tag and calls an omfwd action. I thought perhaps I could persuade rsyslog to write a file at the right prio and then have rsyslog come back around and naturally pick it up. Sadly, no dice.
  • loading an omprog module that calls logger -p local5.info if syslogfacility-text == 'local0', stopping processing there…and then having another config element check for syslogfacility-text == 'local5' and if so calling an omfwd action. Strangely this works but doesn't squash the original messages, now I just get two sets of logs being forwarded to B, one local0 and one local5.

Are there any solutions out there?

Best Answer

It's more a hack than a solution, but I was unable to find any "clean" way to solve your issue:

The UDP packet payload for local0.notice messages will always start with a <133> value (16*8 + 5 according to rfc3164), while a local5.info maps to <174> (21*8 + 6).

You can use nfqueue+scapy on A to rewrite all occurences of <133> to <174> while sending the packets on the wire and B will receive and log local5.info messages instead of local0.notice.

All other syslog UDP packets will be unaffected and logged normally.

Simple example : https://byt3bl33d3r.github.io/using-nfqueue-with-python-the-right-way.html

The RFC : https://www.ietf.org/rfc/rfc3164.txt

Script for tabular PRI values : http://www.digitalprognosis.com/opensource/scripts/syslog-priorities.py

Related Topic