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.
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", ....);
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.
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.
