I am using the parse_json function to determine whether or not the msg element
is a JSON object.
set $.isjson = parse_json($msg, "\$!parsed");
if ($.isjson == 0) then {
set $!jmsg = $msg;
set $!smsg = "";
} else {
set $!jmsg = "null";
set $!smsg = $msg;
}
For network input this seems to always work, but for file input we seeing odd
behavior where some strings that are not JSON objects are being identified as
if they were JSON objects.
Case in point is the msg "a,b,c,d,e,f”. If received over the network (imptcp)
with a proper syslog header, this msg is correctly identified as not being a
JSON object, and the value is applied to the $!smsg element in the if construct
that follows.
However, if that same string is received in file input (imfile), the message is
incorrectly identified as being a JSON object and the value is applied to the
$!jmsg element. The same is true if the fields are pipe delimited as
"a|b|c|d|e|f".
If I modify the msg to be wrapped in parenthesis, i.e. "(a,b,c,d,e,f)” or
“(a|b|c|d|e|f)", then the string is identified properly in both cases.
Another thing that may be of significance is that if I add a syslog header to
each line of the file input, and specify needparse=“on” in the file input
definition, the issue goes away and the msg element is always identified
properly.
This is v8.2102. I’m not sure if this is a bug or if I’m missing something
fundamental about the differences between input types, so any advice or
guidance is greatly appreciated.
Thanks all!
_______________________________________________
rsyslog mailing list
https://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.
