2015-02-04 2:47 GMT+01:00 David Lang <[email protected]>:
> as I'm spending a bunch of time making templates from cisco logs, a few
> thoughts on mmnormalize
>
> 1. It should probably set parsesuccess like mmjsonparse does
>
> 2. it would be useful to have something like char-to that accepted
> multiple characters as the termination pattern. thanks to the addition of
> toeknize I was able to work around this ('flags FIN ACK on interface'
> where the number of flags listed is variable)
>
> 3. the number type should accept negative numbers, not just digits
>
>
> 4. it would be fantastic to be able to define custom types in the config
>
> example
>
> inside:1.2.3.4/56 is a pattern that happens a lot and I use
> %srciface:char-to:\x3a%\x3a%srcip:ipv4%/%srcport:number% and
> %dstiface:char-to:\x3a%\x3a%dstip:ipv4%/%dstport:number% to match this
> pattern
>
>
Florian thankfully found some old PIX logs which I have been played with
the past days. I also came over this syntax. It possibly is something that
a special parser would make sense for. I am working on a log structure
analyser and this is one of the things it already finds rather quickly when
data is thrown at it. Unfortunately, I received 0 log contributions, so
it's very hard to find out what would be needed.
> , being able to define
>
> custom=info:%iface:char-to:\x3a%\x3a%ip:ipv4%/%port:number%
>
> and then use "%src:info% to %dst:info% instead of that full pattern and
> have the resulting json be
> { src : { iface : inside, ip : 1.2.3.4, port : 56 }, { dst...
>
>
> 5. Going back to the 'or' question. It would be even better to be able to
> define this custom type as a set of patterns.
>
> while inside:1.2.3.4/56 is a common endpoint definition there are also
> 1.2.3.4/56 inside:1.2.3.4/56(string) inside/1.2.3.4 and 1.2.3.4
>
> if you could define the custom type to be a list of patterns this would
> let you take advantage of the two-dimentional nature of JSON and simplify
> the ruleset considerably.
>
these things already show up greatly in the structure analyzer. The idea is
to evolve lognorm based on the findings of the structure analyzer.
Just FYI,
Rainer
>
> It would also give you a good way to handle the 'or' for Apache logs for
> example defining one of the options as a constant '-'
>
> defining an 'or' instead each pattern is a horrible mess to try and
> understand, but if it's done by implementing a new type, I don't have a
> problem with it.
>
> 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.
