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://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.
