a literal space is always more efficent than whitespace, only use
whitespace if there can be more than one space, or tabs
Ok.
just a note, the new syntax is not always better than the old syntax
127.0.0.1 - - [17/Mar/2016:18:15:06 +0100] "GET /redacted HTTP/1.1"
200 59506
type=@apache_common:%ip:ipv4% %ident:word% %user:word%
[%date:char-to:]%] "%request:char-to:"%" %response:number% %bytes:rest%
Indeed. switched to old syntax and everything is working...¬¬
type=@apache_common:%ip:ipv4% %ident:word% %user:word%
[%date:char-to:]%] "%method:word%%-:whitespace%%request:char-to: %
HTTP/%httpversion:float%" %response:number% %bytes:word%
# ] this comment here fixes highlighting
rule=access_common:%.:@apache_common%
# .
rule=access_combined:%.:@apache_common% %referrer:quoted-string%
%useragent:quoted-string%
# .
note that bytes really should be type number, but that requires a
trailiing space right now.
Actually, as sometimes is "-", i must use word, which doesn't seem to
have issues with SP/LF
rule=access_combined:%[
{"type":"@apache_common", "name":"."},
{"type":"@apache_combined","name":"."}
]%
this is looking for one after the other, not either
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"}
]}
]%
when looking at the trace, everything before the "To normalize:" is
probably not that useful (it's needed if you think the ruleset isn't
being parsed correctly, but not to try and figure out why the log line
isn't being parsed correctly)
Ok
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.
normalized: '{ "originalmsg": "127.0.0.1 - - [17\/Mar\/2016:18:15:06
+0100] \"GET \/redacted HTTP\/1.1\" 200 59506", "unparsed-data": "" }'
ok, now I understand this, it parsed the message with @apache_common
and got to position 77 (the end of the message), but that wasn't the
end of the rule, so the parsing failed, and it failed with nothing
left to parse
Understood. Hope it won't happen again.
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! ;)
_______________________________________________
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.
