On Tue, 13 Jul 2010, Sean Conner wrote: > It was thus said that the Great [email protected] once stated: >> On Mon, 12 Jul 2010, Sean Conner wrote: >> >>> Since most of what you want to do is based off the input message, how >>> about extending this style of syntax to more than just the facility/priority >>> pair? Since host, program, facility, priority and message are typically the >>> most interesting fields (at least, in my experience), perhaps a syntax that >>> includes matching those as well would work. Something like: >> >> <snip> >> >> this is the approach that rsyslog took with the old config file. >> >> the problem is that we are now getting capibilities that can't easily be >> represented this way > > Such as? > > That's one reason why I took the approach I did in my syslogd (which uses > Lua)---if the configuration file is going to be complex anyway, why not just > write a syslog filter in Lua and be done with it? I know why Rainer is > rejecting Lua (and by extension, even his own RanierScript), but the current > method is obviously not working, because the topic keeps coming up as mroe > and more use cases come into being. > > So perhaps the question to ask is not what the configuration file looks > like, but rather, what, exactly, is rsyslogd expected to do? Just route > messages from sources to destinations and nothing more? Or do people want > logic in the processing? (My guess is "Yes"---and that's what is causing > problems with the configuration file).
if-then-else logic in the processing, sending things to the same output based on different logic, subsets of rules that only get evaluated if earlier conditions are true, allowing some outputs to queue while not others. just as a few of them earlier in this thread some of the examples that Rainer gave give some hints of this. David Lang _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com
