On Tue, 22 Mar 2016, singh.janmejay wrote:
How about this: we support a new flag in impstats which allows
json-formatted stats-line to optionally use
encapsulated/wrapped-layout?
impstats(format="json" ...) generates
{"name":"msg_per_host","origin":"dynstats.bucket","z-scribe1r-b":80,"SWEB10":67}
however,
impstats(format="json/w" ...) generates {"header":
{"name":"msg_per_host","origin":"dynstats.bucket"}, "counters" :
{"z-scribe1r-b":80,"SWEB10":67}}
This is relevant, the serilization format we use right now mixes
pre-defined keys with counter-names and it can affect regular static
counters too.
with the existing pstats output, there is no ability for user-defined data to
become a tag name, so there is no potential for ambiguity. but with dynastats,
this is not a possibility, and the format we use should prevent problems.
Also, just from a conceptual point of view, why should the bucket contents be at
the same level as the bucket name?
other than backwards compatibility, what advantage is there of the current
version in JSON? the documentation uses the plain text equivalant, which is
perfectly legitimate because there is an order to the line, and after you get
past the name and origin, everything else on the line is name-value pairs of
counters, again, no ambiguity.
But with JSON, I don't believe that you can depend on tools maintaining (or even
identifying) the order of the elements, and if you have multiple elements with
the same name, it's implementation dependent as to which one will be seen.
So purely from a correctness and defensive programming point of view, I think
the current JSON serialization should be changed, with the old format no longer
being an option.
As to the details of the new format
What I'm wanting to do with the counters is something like
if $!origin == "dynstats.bucket" then {
foreach $.tag $!counters {
/var/log/stats;format
}
}
to output one line per counter.
I'm very flexible in how to do this, but I would much rather be able to do this
inside rsyslog than have to serialize things to an external script, have it
parse the json and process it.
my initial thinking was just do
counters: [ "z-scribe1r-b":80,"SWEB10":67 ]
but as I'm typing this, I realize that doesn't work as I don't have a way to
break $.tag down to reference the name and the value.
I'd hate to have to do something like
counters: [{"name":"z-scribe1r-b","value":80 },{"name":"SWEB10","value":67}]
this mirrors the misuse of XML that gives it such a horrible reputation. But
unless we introduce some new function to rsyslog to break things down, I don't
see a better way. If we do need to do something like this, I sure would not want
to make it the default JSON, which would result in two different formats. I hate
the idea of starting to have different formats because of subtypes of data (what
is someone wants the cee version of this for example, you start to have
orthoginal format decisions)
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.
