CODEWITHSUNDEEP
pythontestingrsyslog
andimeier
andimeier

Reputation: 1263

route some syslog messages to another server (via UDP)

Update: I used too many words and was not clear about what I really tried to achieve. I now edited the text to make my intentions clearer - and provide my own answer (s. below) because I successfully resolved this issue for me.

TL;DR:

Boiled down to the point, the question is:

How can I configure syslog so that some messages are routed to another service which processes them?

The question with much much more words (if you have time ;) ):

I have an integration test scenario where a Raspi would orchestrate and conduct the test. The Raspi stimulates the device under test (DUT) “from the outside” and listens for any expected reactions of the DUT. Thus, a typical integration test scenario (black box test).

+-----+   +-----+
| RPi |---| DUT |
+-----+   +-----+

One of the features to be tested is whether the DUT would issue syslog messages to a remote rsyslog server correctly. So I decided the Raspi should be the “remote rsyslog server” (a.k.a. the syslog receiver) and thus can test whether the DUT would send all syslog messages it is expected to. Now how can the received syslog messages be asserted on the Raspi? I could simply go through the syslog messages on the Raspi and expect to find messages from the DUT – along many other “standard” syslog messages from the Raspi itself.

This way the test runner would not have to parse the log files written by the "normal" rsyslog server.

After the test run, I would like the "other thing" to stop listening and the "normal" rsyslog config to go back to normal.

This is roughly the idea. Do you think this is a viable (and not too complicated) way to go?

The "other thing" would be a Python script, since the entire test orchestration is written in Python. So, maybe a Python rsyslog server listening on a special port, and additionally configuring the "normal" server rsyslog so that messages are forwarded to this Python consumer as well.

More nicely would be if the "normal" rsyslog server could be configured to only relay those messages to the "other thing" meeting specific criteria.

Do you think I should stick with parsing log files or does this seem like a good idea?

Upvotes: 0

Views: 1076

Answers (1)

andimeier
andimeier

Reputation: 1263

With syslog, you can use the target with a @ notation and an IP address - then those messages would be forwarded via UDP. So all you have to do is decide on syslog facility, priority and maybe other criteria (e.g. source IP) and add in your rsyslog.conf e.g.:

local7.info  @127.0.0.1:10514

Thus, all matching syslog messages would be sent via UDP. If no process is listening on that port, nothing will happen, so no problem for the rsyslog system.

That’s all, all the other stuff I’ve written was trying to describe the use case for this. Basically, I configured this rsyslog setting permanently (because it does no harm when no UDP server would consume the messages). And when the integration test launches, a UDP server is started and collects all syslog messages during the test – and only those of interest (this is what the syslog rules must make sure - in the above example a simple local7.info, but it could be more complex). That’s what I tried to achieve and that’s how I did it.

Upvotes: 0

Related Questions