sounds good, will test/use it when it's available,
is this a short term or long term solution? I.e. did you give up on
the parsing into a subtree? Would rather wait for long term solution (if
it's coming in e.g. few weeks) cause I need some workaround right now
anyway and I think whatever it is it will work for short term (think I
will generate the templates with my custom info instead of using variables).
erik
On 07/16/2013 09:12 AM, Rainer Gerhards wrote:
Looks like adding "$.name!name!name" for "local variables" seems not to be
overwhelmingly much work. I'll try to fit it in tomorow or Thursday (no
promise, though).
Rainer
On Tue, Jul 16, 2013 at 10:44 AM, Rainer Gerhards
<[email protected]>wrote:
just quickly: will see which of these options I can implement most
quickly. Will try to look at it withint this week (but need to make sure
the "necessary" things are done first).
Rainer
On Tue, Jul 16, 2013 at 9:57 AM, David Lang <[email protected]> wrote:
On Mon, 15 Jul 2013, Erik Steffl wrote:
the problem with that is that I have to set variables somewhere (so
that I can use them no matter what, I have two templates but they need the
same info).
Only after that the message is parsed, so it's actually parsing of the
message that would overwrite my info.
ahh, this is _exactly_ the trusted parameters problem that I alluded to
earlier. I had suggested having a way to specify a 'protected' and 'where
to move duplicates' tree when parsing. Rainer is talking about having the
ability to set the root the the parsed tree to be something other than $!
($!parsed! for example, it would need to be configurable, eventually we
will need the ability to take sub-elements and run them through a parser to
create additional variables, think a JSON strin embedded in a name=value
message)
The proposal to have three sepearate roots
1. parsed/generic
2. explicitly local (will not show up in $! or all-json)
3. explicitly global (will stick around for future messages and not show
up in $!)
sounds like a good start.
By default everything is in one namespace, but we know we need these
other two, and they are different enough to be worth considering completely
separate. I do like the global filesystem view of things, but if we do that
we really do need the ability to carve off subtrees (the equivalent of -x
"don't cross device boundries" in find/tar)
for most things, I think explicit filters or boundries is good, but
global really will be handled differently than normal variables, and
explcitly local variables are going to be exceptions in lots of code. So it
seems that this may be sufficient justification to split them off.
David Lang
I currently have two files, one is a simple file that only sets the
variables (generated at deployment/installation time) and the other ones is
a somewhat complex file (stored in git) that has the templates, sets up the
actions, json parsing etc.
file with variables /etc/rsyslog.d/30-my-vars.**conf:
set $!cluster = "something";
the other file /etc/rsyslog.d/31-my.conf:
template(name="json-parsed-ok" type="list") {
... standard header (pri, time, host)
constant(value="@cee{\"**original-message-json\":\"")
property(name="$!all-json")
constant(value=",\"cluster\":\**"")
property(name="$!cluster")
constant(value="\"}\n")
}
template(name="json-parsing-**failed" type="list") {
... standard header (pri, time, host)
constant(value="@cee{\"**original-message-txt\":\"")
property(name="msg" format="json")
constant(value=",\"cluster\":\**"")
property(name="$!cluster")
constant(value="\"}\n")
}
if prifilt("local0.*") then {
action(type="mmjsonparse")
if $parsesuccess == "OK" then {
action(template="json-parsed-**ok" type="omfwd" ...)
} else {
action(template="json-parsing-**failed" type="omfwd" ...)
}
stop
}
The json-parsing-failed template works fine since $!cluster does not
change property("msg"). The json-parsed-ok does nto work so well since
$!cluster becomes part of json. I could almost use property("msg") in
json-parsed-ok as well but it has @cee at the beginning.
It seems that the only way out of this is to dynamically generate the
templates themselves but I was trying to keep the generated part as simple
as possible and the templates are not very readable even when typed
directly.
Or maybe use substring of property("msg")?
Is there some other place to store the value of cluster name (in
reality it's few more items but nothing complex, just strings) other than
$!all-json?
thanks!
erik
______________________________**_________________
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://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.
