> -----Original Message----- > From: [email protected] [mailto:rsyslog- > [email protected]] On Behalf Of [email protected] > Sent: Wednesday, October 31, 2012 11:02 AM > To: rsyslog-users > Subject: Re: [rsyslog] subtree templates > > On Wed, 31 Oct 2012, Rainer Gerhards wrote: > > >> -----Original Message----- > >> From: [email protected] [mailto:rsyslog- > >> [email protected]] On Behalf Of Brian Knox > >> Sent: Tuesday, October 30, 2012 6:33 PM > >> To: rsyslog-users > >> Subject: [rsyslog] subtree templates > >> > >> I'm playing with the new template syntax today and for the most part > >> am having a lot of success. The one thing I find a bit confusing > >> still is working with the new subtree template types. Given a > subtree > >> that simply includes all properties: > >> > >> template(name="normalizeTest" type="subtree" subtree="$!") > >> > >> How can I say, add a line break to the end of the template, or > combine > >> this with other constants? > > > > I guess the doc does not yet explain this well enough. You actually > can't - because this type of template is aimed at plugins that do want > fields. So if you want a constant field, you set some filed name to the > constant and pass that in. > > > > I assume this is not what you want. I guess you want to have some > text template, and in this json. This is quite straightforward, but > cannot be done with subtree templates. Just use the other ones, > subtrees will be expanded as text: > > > > template(name="xxx" type="string" string="%$!%\n") > > > > Note that in this format, the subtree is actually a SINGLE string > FIELD, > > so this is usually not what a structure-aware plugin would want > (except, > > of course, if it simply needs to forward that string to a final > > destination). > > hmm, with the new variable assignment, it is possible to create a > subtree > template, assign the result of that to a variable, and then use that > variable in another template?
No, templates are always at the end of the process, as a final terminal. The idea is slightly different (IMHO I think this is based on your original suggestion): you create whatever fields you use via variable assignment. You can reuse these variables as much as you like. If you have different needs, you simply create different subtrees, but all based on the same variable set (or even include one subtree into another). When this is done, you bind this to the actions via the subtree templates. Note that under the hood there currently is a lot of deep copying involved, so there definitely is room for improvement. I just wanted to keep the changes as small as possible - it is already considerate. As we all know, hunting for bugs becomes much more complex the larger a single change is ;) This may be a good refresher on the set capability: http://blog.gerhards.net/2012/09/setting-variables-in-rsyslog-v7.html Note that the functionality described as "missing" has been implemented by now. Rainer > While the subtree is designed for fully automated processing, I expect > "interesting" things to be done by various people with all the new > tools > at their disposal :-) > > 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. _______________________________________________ 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.
