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
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)
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:
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