> -----Original Message----- > From: [email protected] [mailto:rsyslog- > [email protected]] On Behalf Of [email protected] > Sent: Thursday, July 14, 2011 9:32 AM > To: rsyslog-users > Subject: Re: [rsyslog] new config parser out... > > On Thu, 14 Jul 2011, Rainer Gerhards wrote: > > >> as far as the perl-ish use of '$', in many ways this is becoming a > >> programming environment, especially if there is going to be the > ability > >> to define our own properties (i.e. variables) in the future > (something > >> I think I remember reading) > > > > This is not on my current TODO list, but definitely possible with the > new > > system. It would make sense to get some actual use cases, so that I > can begin > > to model it into the longer term todo. > > sorry, I thought I had read that you were thinking of this.
No need to be sorry. Thinking I was, but not with a real conclusion, just the overall feeling that it would be useful for some cases. > > a use case would be where you want to take some fairly complex subset > of > an existing property (probably in the message) and then make decisions > on > it, or use it in a future template (potentially using another subset of > the value). it is a lot cleaner to be able to assign your own property > name, and some things may not be possible without a multi-step approach > > > if the message matches X > the Nth word is the server name > write the log to a dynafile based on the basename of the server > > the server name is in the form basename[location][farm]-memberid > where location is numeric, farm and memberid are alpha > > real-world example gaunetlet1a-c > > gauntlet means a particular type of function (in this case a > firewall > doing a particular type of job) > > location indicates what environment it's in (1 = production, 2=DR, > 0=QA) > > farm further refines the location (a particular subset of > production) > > memberid indicates which system in the farm this is (the 3rd member > in > this case) > > this is hard enough to do if gauntlet1c is the hostname for the log > entry > you are looking for, but if you are looking for a log from another > system > referring to gauntlet1a-c in the log message (say a manager system > saying > that it's published rule updates on gauntlet1a-c) that quickly gets > beyond > what you can do today, but would be pretty easy if you can set > additional > variables/properties to hold the intermediate values. I think I get the idea. To me, it looks much like a performance optimization. Please correct me if I am wrong, but I think the more important thing is to have block nesting. That, compared with substr() could probably get you somewhere. But I agree that user-settable variables would definitely a plus. I assume a local scope limited to the message being processed is sufficient. I also assume that there is no need to carry these variables over to an async action. Or is it? That would complicate and slow down things. Do you think variables without block nesting make sense (this is the question if it is a v6 or a v7 feature)? Rainer > > David Lang > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com
