On 07/16/2013 12:12 AM, David Lang wrote:
On Tue, 16 Jul 2013, Rainer Gerhards wrote:
On Tue, Jul 16, 2013 at 8:36 AM, David Lang <[email protected]> wrote:
On Tue, 16 Jul 2013, Rainer Gerhards wrote:
Couple of points:
$!all-json is a legacy property. It is better to access native json
pathes.
Overall idea: to handle cases like this, the idea is that the data
to be
sent is put into differet subtress and a subtree template [1] is
used for
forwarding. IIRC, I did a blog post about this, but I have to admit I
didn't find it on quick search :-(.
It may be worth defining _rsyslog_local!* as a tree that is not included
in all-json
all-json is really just an old legacy hack. I don't want to enhance it
any
further. It's essentially dead ad just there so that old things
continue to
work.
so that people can define whatever they want (and I believe that 'real'
json trees cannot start with aa '_', so it wouldn't even be a namespace
conflict, assuming that rsyslog can tolerate it)
Thinking about the full json tree ("$!"), I don't see this brings benefit
over properly working with subtrees. Does it? It adds complexity in any
case (and hurts performance due to this added complexity).
I didn't know about "$!", neat trick and makes all sorts of sense.
However, we will have people creating variables in the root tree, or
parsing messages into the root tree basically forever (due to backwards
compatibility for configs if nothing else), so I think that trying to
say that people just should do all their work in subtrees is a lost
cause. I think we are going to be able to define some way to filter
things out of $! (or $!all-json) much more easily.
think the way Rainer describes it in the other posts makes sense, as
long as subtrees can be used everywhere and old behaviour is default it
would be backward compatible and only people who actually want to use
subtrees need to worry about them...
As a quick hack, that I think solves a real use case, we need a way to
carve out variables that we will be creating and manipulating but don't
want to have show up in $!. This would be for variables that are used in
dynafile templates but don't make sense in the message itself.
Later on, I think it makes sense to create a filter function something
along the lines of
filter-json($!, "leave-me-out1", "leave!me!out!2", ....);
this would not work in general since whatever one tries to leave out
might have been part of parsed tree.
where it returns a json string that has the list of subtrees filtered
out of it.
But this is significantly more work and requires a lot more thinking.
If there is a variable name that's not legal json, but is legal in
rsyslog, then we can use that to define a 'local variable' namespace.
It's more work to use than using something in the root namespace, but
the common case is that most people will want everything, the case where
someone wants to define a variable and then not have it show up in the
output is the exception. Make the common case easy at the cost of the
exception case, not the reverse.
I think pretty much everything legal in json, it's essentially a
string (key value, not really variable name), some characters need
escaping when in text format (e.g. "a is a valid name only needs to be
escaped, i.e. {"\"a":"b"} is valid json). Actually I think pretty much
only " and \ needs to be escaped (and control chars, see
http://www.json.org/ and the definition of char in the right hand
column). They also list / but it works fine by itself according to
jsonlint.com.
erik
_______________________________________________
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.
