Syslog format in MessageLoggingPolicy

[#1]

I am using the MessageLoggingPolicy to send logs to Loggly, however, the syslog "header" section does not appear to be correctly formatted.

(The "structured data" and "message" portions, which I have configured in the policy's <Message> element are correctly sent verbatim.)

This is the header portion which is appearing on the syslog messages:

<14>Fri Sep 26 01:32:23 UTC 2014Info: 

This is followed by the string configured in my policy's <Message> element.

Is there any way to change this behaviour? For instance, to set the time format as yyyy-MM-dd'T'hh:mm:ss, set the application name or message ID (per RFC 5424)?

Thanks!

[mdunker · Accepted solution]

Hi Alp,

I don't believe you can modify the structured data portion of the log..

My recommendation would be to put anything you want formatted in a specific way in the message. You can format your date in JavaScript before logging.

This has the added benefit of protecting you against any format changes or differences if you move to a different logging service provider.

Good luck!

Mike

[#3]

Apologies for replying to an old thread, but was wondering if anything has changed? I'm logging to a syslog server set up in AWS and am only interested in the log message.

I do not want the header at all and was curious to know if there's a way to modify it or simply remove this portion:

<14>Fri Sep 26 01:32:23 UTC 2014Info: 

[brentstains]

I know this thread is over 3 years old, but I can't seem to find a more definitive answer either. We're having issues with the timezone offset formatting which by the IEFT syslog format (RFC 5424) spec requires a ":" between hours and minutes.

For example, with FormatMessage=true:

Apigee generates: <14>1 2018-05-24T18:16:37.037+0000

Should be: <14>1 2018-05-24T18:16:37.037+00:00

I see there "may" be options to control the timezone settings for a private cloud installation, but nothing for public cloud instances.

There has to be people who are using Splunk, so my question is "How do you get around this issue?" Are you writing custom parsers in Splunk to deal with it?