On Tue, 16 Jul 2013, Rainer Gerhards wrote:
On Tue, Jul 16, 2013 at 9:12 AM, David Lang <[email protected]> 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.
OK, If we buy that argument (I can live with it), a proper and least
complex extension probably is to support three different trees (that also
doesn't require a real resolver as it is hardcoded).
$! - msg
$!! - user
$!!! - global
where the actual name for $!! and $!!! need to be decided (could also be
s/t like "$/" or so).
sounds reasonable, we don't have anything global now, but we know we need it. It
would be a good performance benefit to force all global variables to be
explicitly defined, this gives us an obvious way to do this.
this thread shows the need for user/local.
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", ....);
you can unset variable right now!
the problem is that you may need the variable for a dynafile template, but don't
want it in your message output.
Or where you need the variable for later rules, but don't want it showing up
in some other output (and you can't always order things so that you can unset
them)
where it returns a json string that has the list of subtrees filtered out
of it.
It's very hard to do this with decent performance, involves a lot of
copying... I also think it's unnecessary if we have these three different
roots (I stil like the simpilicity of a FS-like method, though).
I agree, how about instead of a function, have some sort of template filter
%$!:filter:leave_this_out:leave!this!out%
at that point you are creating the string anyway, so it's not additional
overhead.
David Lang
Rainer
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://lists.adiscon.net/mailman/listinfo/rsyslog>
http://www.rsyslog.com/**professional-services/<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.
_______________________________________________
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.
_______________________________________________
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.
