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.
