On 8/5/17 11:28 PM, David Lang wrote:
on the receiver, write a log with the format rawmsg or use the RSYSLOG_DebugFormat and look at the rawmsg line there. Let's see exactly what is being sent to see if the data is being lost at transmit or on reception.

Personally, I have my senders reformat the data so that the body of the message is in JSON, and then I create a $!trusted variable that I have contain various metadata. each machine that processes the message adds to the metadata (when it was received, what machine recived it, what IP it was recevied from,etc)

This is a good place to put high res timing info or syslogtag info to make sure that nothing mangles it in processing. On the final receiver, you then parse the JSON and have access to everything you every want.

This is an indirect way of solving the problem you have, but it solves a bunch of other problems at the same time, and doesn't require the SyslogProtocol123Format to get the timestamp you want (you may even just include the timestamp in various formats so you don't have to mess with changing it's format later)

David Lang

I responded back to my original email a few minutes ago before seeing your reply, but it looks like setting this global option on the clients will do what I need:

global (

That said, thank you for the tips. I know I'm eventually going to have to look at using JSON since most of the popular tool chains I'm researching seem to prefer it (e.g., Elastic Stack, Graylog), so I'm definitely interested in learning more about that approach.

Are there any good guides that cover the steps you mention in detail? I understand the basic idea of what you're suggesting, but perhaps not the step by step implementation details.

Thank you for your help.
rsyslog mailing list
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of 
sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE 

Reply via email to