> -----Original Message-----
> From: [email protected] [mailto:rsyslog-
> [email protected]] On Behalf Of [email protected]
> Sent: Tuesday, July 13, 2010 9:11 AM
> To: rsyslog-users
> Subject: Re: [rsyslog] NEW rsyslog.conf format
>
> 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.
To add some of the less obvious things: support for multiple listeners going
to different outputs, in an easy to use way. Support for explicitely
specified concurrency (or serialization) for high-speed environments, support
for different queues, and tying of different queues to different object
classes (inputs, message processors, actions). Flexibility to support
configuration for even unexpected plugins that we may not even know about
(because some third party writes them and never publishes them).
But I begin to agree that we, the community, as a whole have very different
needs. I have gotten the impression that it is probably a good idea to stop
the current effort and re-start it with a requirements definition. I have
tried to digest the discussions on config format we had over the year, but
sometimes it looks like the only consensus we have is that the current format
is ugly and hard to use. The solutions are very wide-ranging. I have even
briefly looked at syslog-ng, and seen a lot of the pain again that makes me
dislike that format (but I'll probably still have a closer look and will try
to write up my detailed position why I do not find buying into this format is
a good idea).
All in all, I think the best way to re-start our thinking about the config
format is to set up a web site where we gather user feedback on
a) what problems they have with the config format
(not what they just dislike, but real problems, an example
From myself: it is nearly impossible to get the sequence right
To bind inputs to the right rulesets AND use ruleset inclusion)
b) which alternatives they see
With all this being on a web site, it may be possible to craft a better
decision in 6 to 9 month, assuming we were able to gain sufficient feedback
during that time.
An alternative would be to create a config parser interface, so that
everybody could code up his favorite config language. However, this seems to
be impractical, as many of the ideas floating around (Lua, syslog-ng style)
require not just different config parsers, but a different rsyslog processing
core as well. Obviously a complete rewrite in the case of Lua, less for
syslog-ng, but still considerate. For the syslog-ng style we would need to
create named filters, something that I really find questionable. Also, we
would need to add an interim layer between inputs and rulesets, something
that eats performance. In any case, this are not config-parser only changes.
Of course, I could just pick one of the alternatives. However, it doesn't
make sense to invest a couple of month to do the config system "right", if we
know that a lot of folks will still be unhappy after we have done this.
Rainer
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com
