In my case I switched to rfc5424 precisely for the subsecond timestamps, when agregating data from a lot of places, the messages would get unordered for some reason, adding the microsecond fixed all that.
Digging in the available choices I amb thinking about two different options: 1) I stumbled into this this <http://www.rsyslog.com/how-to-add-a-hmac-to-rfc5424-structured-data-messages/>, the module mmrfc5424addhmac allows adding to the structured data some information (in this case the hmac value), I looked around the code to check if there was a generic approach to this, but couldn't find anything. Is there anything that I have missed? BTW with the mentioned module the SD can be modified like this: action(type="mmrfc5424addhmac" key="yourenterprisekey" hashFunction="sha256" sd_id="id@32473") 2) Another way of doing it would be to compose the structured data by hand (removing the %STRUCTURED-DATA% currently empty) and replacing it by a crafted field $template Protocol23log4j,"<%$.pri%>1 %TIMESTAMP:::date-rfc3339% %HOSTNAME% %APP-NAME% %PROCID% %MSGID% %STRUCTURED-DATA% %msg%\n" $template Protocol23log4j,"<%$.pri%>1 %TIMESTAMP:::date-rfc3339% %HOSTNAME% %APP-NAME% %PROCID% %MSGID% [exampleSDID@32473 file="%$!metadata!filename%"] %msg%\n" Being the 1) not available if there is no such module, would be the 2) a valid way of creating this data? 2017-10-07 0:03 GMT+02:00 David Lang <da...@lang.hm>: > On Fri, 6 Oct 2017, Dave Cottlehuber wrote: > > at the final destination, I have all that data available and can either >>> use it, or create a template that just writes out a RFC3164 style message >>> with the original message content. >>> >> >> Is there any reason why you prefer RFC3164 vs the later RFC5424 >> http://datatracker.ietf.org/doc/rfc5424 ? >> > > rfc5424 is a failure in many ways and has largely been ignored. Most > things that emit syslogs do so via the older standard, virtually nothing > supports the 'structured data' that it provides (which is why I do json in > the body of the message, everything understands that). most log parsing > tools don't know what to do with the newer format. > > and the older format is just more compact (separate fields for app, pid, > and msgid vs the syslogtag app[pid]:) > > the one real advantage the new format has is the sub-second timestamp and > the timezone in the timestamp. If you have all your systems running on the > same timezone, then the latter doesn't help, and I really have never had to > worry about sub-second resolution when dealing with logs. It's either the > sequence of the logs or to the nearest minute is good enough. > > your milage may vary, there's nothing wrong with using the newer format. > > David Lang > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com/professional-services/ > 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 THAT. > _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com/professional-services/ 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 THAT.
