On Wed, 7 Dec 2016, [email protected] wrote:
you either use alternative or you have two different rule lines
I'm getting /invalid field type 'alternative'/ when using it. Any ideas?
rule=test:%[
{"type":"alternative","parser":[
{"type":"literal","text":"-"},
{"type":"word","name":"identd"}
]}
]%
no idea
it would be nice if -v only showed you the part we normally care about,
there may be a way to get just this portion, but I don't know how
I didn't notice any difference between -v, -vv and -vvv, so perhaps it's a
bug/not implemented/something to ask to @rgerhards
this looks like it's undoing things, it may be an artifact of using a
custom type (misleading at best)
and we've undone averything.
No idea...does it make sense to declare "longer matching rules" first?
AKA: combined before common.
it really doesn't matter (minor speed difference for putting most commonly
matched rules first, but no difference in parsing accuracy)
now we look at the second message (it helps understand this if you only
look at one at a time, one rule and one log message)
To normalize: '127.0.0.1 - - [17/Mar/2016:18:15:24 +0100] "OPTIONS /
did not find the field useragent, so backing up (probably end-of-line
problem)
It was that, indeed.
Thanks for so long and instructive reply! ;)
now you know how to read that debug output, you will find it really helpful when
you just can't see why a rule doesn't match :-)
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.