That's a very good case. Thanks for sharing. I think we should add an ability like a ruleset that is called only once upon startup or so. You could also emulate this behaviour with the lookup table support that is upcoming on the stable branch (actually, the code is already present, but I need to re-verifiy it and add doc). Actually, I think using lookup table for these types of vars is the best solution (you can load them form an external file, reload on hup and accessing them is fast -- but they are (yet?) missing template support).
Note that there is doc on lookup table,but that's for a proposed enhanced version. But the basic idea is there. Rainer On Thu, Oct 24, 2013 at 12:46 AM, Erik Steffl <[email protected]> wrote: > On 10/23/2013 03:31 PM, David Lang wrote: > >> On Wed, 23 Oct 2013, Erik Steffl wrote: >> >> On 10/22/2013 11:05 PM, David Lang wrote: >>> >>>> On Tue, 22 Oct 2013, Erik Steffl wrote: >>>> >>>> >>> so is the use case that I presented a valid one for usage of global >>> variables? The use case I have in mind is having variables set up in >>> one of the files in /etc/rsyslog.d/ then use them in templates. It >>> seems to me these should be global variables (even though they are >>> pretty much constant, i.e. they are only initialized, never changed >>> afdterwards). This is a somewhat different use case than counters that >>> other people mentioned (different from the point of vier why we need >>> the global variables, same from the implementation viewpoint) >>> >>> >> If I am understanding you correctly, absolutly. >> >> the question is what sets these variables. If they are set and not >> changed by future messages (or at least, not changed for a significant >> time period) then that seems like the perfect use case for global >> variables. >> > > yes, in our case these variables are essentially constants, something > like: > > set $!logOrigin!cluster = "clusterName"; > > as part of our deployment we split rsyslog config into one file that has > these variables (file is generated during deployment, mostly things like > cluster name) and another part that is essentially same for all > installations (templates, inputs, outputs etc. that use the variables from > the other file). > > 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://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.
