On Tue, 24 Nov 2015, Rainer Gerhards wrote:
2015-11-24 11:36 GMT+01:00 Ciprian Hacman <[email protected]>:
Hi David,
I totally agree with you. This is something most people would appreciate. I
bump into these issues with customers quite often.
Not sure if the parsers for various formats would be obsoleted by this
generic parser, as most are not that simple and have many variations.
On the other hand, the change I am proposing is a one liner or a parser
that is very similar to the RFC5424. Both are easy to implement.
I have no time to look into it right at the moment, but shouldn't that
be something we can do with a custom data type (definition)?
not currently.
I can create a custom data type '@mytimestamp' that contains a month, day, year,
hour, min, sec, fractsec extracted from a bizzar log line, but the only way for
me to turn this into a timestamp is to do an exec_template to format a variable
based on these variables, and then run another mmnormalize against that
resulting string to get a timestamp.
the goal is to be able to take arbitrarily formatted data info and turn it into
something that you can use in a template %$!mydate:::<format>% and have it do
the right thing.
Anyhow, I'll add a note to the github tracker so that we can see when
we go there. In general, I try to limit the core parsers, as in v2 we
now really have much better capabilities.
I agree, but this is a case where you need to assemble multiple data elements
that can be in different orders, and with different separators (and sometimes
month will be 3, 03, Mar, March) but you want the real result to be internally a
'datetime' variable.
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.
