> -----Original Message----- > From: [email protected] [mailto:rsyslog- > [email protected]] On Behalf Of Aaron Wiebe > Sent: Thursday, June 17, 2010 2:26 PM > To: rsyslog-users > Subject: Re: [rsyslog] feedback requested: NEW rsyslog.conf format > > A few comments: > > execonlyonce 5sec ## this is a directive GLOBAL to > ALL actions! > > You should never be able to declare a globally-impacting variable > outside of the global scope. It should be in <global> up at the top. > If you allow this, it will confuse people: when reading this, how > would we know that it was globally impacting without the comment? It > appears to be a scoped declaration.
Oops, sorry, my bad - the comment is wrong :( [I'll remove it from the online version, so do not wonder when you do not see it any longer]. This was intended as a *scoped* directive. Only things in global (and these should be few) should actually be global. > > <action dynfile> > type omfile > > Perhaps: > <action name=dynfile type=omfile> > > That would make something like this more readable: > > <input name=inp10515 type=imtcp><params>listen 10515; ruleset > remote10515</params></input> This was something we discussed, and kind of my favorite. I got convinced by the following arguments a) Apache uses a single parameter, and it always is the name of the object described b) this becomes ugly if there are more than a handful of modifiers (and there sometimes are) I'd appreciate feedback on these arguments. Note that the overall idea of staying close to Apache is that folks already know that format -- and it seems to be received well. > In other words, everything should be nameable, and everything defined > in-scope should also be reference-able. Yes, that's my idea and requirement as well. I intended to tackle this via <object name> ... </object> OR <object use=obj_defined_elsewhere /> > > I'm a little concerned by the reference to rulesets in the input > section of the example - there you've got an example of something > being referenced before its been declared. That can also be > confusing, even though I understand how that is being handled. One of the things that often causes problem with the current format is that everything needs to be defined before it is used. This has caused quite some problems. So my idea was to remove that requirement, actually in the hopes that it makes to format easier to use. If that is not the case, we can stay with the "define before use" paradigm, it is easier to implement from the parser level. Note that for some complicated configs (like multiple listeners, multiple rulesets, multiple queues and omruleset in one big config) it is rather complicated to get the "define before use" into the right sequence. I myself failed more often than once ;) > I think it comes down to this (i'd bold it if this wasn't plain text): > We should be able to easily understand what is being declared against > what is being applied, and I think this initial mock-up can be > confusing. Can you elaborate a little bit more -- I simply do not fully understand the sentence (probably a non-native speaker issue). > > Lastly - please.... HUP configuration reloads. Having written that > type of code myself, I realize its not easy, but it would be very much > appreciated. Yes, yes, yes, ... but: I'd like to have it myself, but it is extremely difficult with all the dynamic things that go on in rsyslog. I intend to tackle that in multiple steps. The new config system would run in two stages: 1) parse the config and create a new config tree 2) apply the new config tree That process facilitates dynamic config reloads, but it doesn't bring them for free. In fact, almost anything inside the core and in all plugins must be touched to make this happen. So my plan is to get the config system ready to support multiple in-core configs, and *at a later stage* and gradually move to dynamic config change. Thanks again for the feedback, it is very valuable. Rainer > > -Aaron > > > On Thu, Jun 17, 2010 at 7:02 AM, Rainer Gerhards > <[email protected]> wrote: > > Hi all, > > > > me again with some feedback request ;) > > > > As you all know, rsyslog.conf format is ugly (to phrase it politely). > Adiscon > > has begun an initiative to unify config language across products. I'd > like to > > join that initiative with rsyslog, thus gaining some extra help. So > my plan > > is to actually begin looking at the config language once I am through > with > > the current round of optimizations. > > > > To do so, I would like to receive your feedback on a config proposal > that I > > have been able to discuss with an internal expert. We have now based > the > > format on the familiar Apache config format, with some extra bells > and > > whistles to make it more useful for syslog. Most importantly, my > personal > > feeling is that pure Apache format is quite verbose, and thus it may > take too > > much space (read: make unreadable) to describe a plain vanilla > rsyslog.conf > > (all those "pri.severity /do/somewhat" rules). As such, I have asked > for a > > way to describe more condensed rules. I think we have found a nice > > compromise. > > > > Also, I have included some things into the config format that would > easily > > enable me to do a next round of performance enhancements once we have > the new > > format in place. It allows to express things like shared actions, > which > > simply cannot be done with the current engine and would be a major > pain to > > implement without a new config format. As a side-note, I will > probably be > > able to obtain, from Adiscon's closed source, a higher speed > expression > > evaluation engine, which would be something really nice. > > > > I have posted a hypothetical config in the new format to > > > > http://www.rsyslog.com/download/new_rsyslog.conf > > > > It should be relatively self-explanatory (at least to people who know > Apache > > config) -- if not, that's already a bad sign ;) > > > > I would appreciate feedback on this config format. Is it useful? Is > it > > readable? Does it look sufficiently simple for simple use cases and > > sufficiently expressive for complex cases? Would you like to work > with such a > > format? > > > > Please raise your voice especially if you DO NOT LIKE the format -- > the > > reasons is that I will probably work towards such a format if I don't > get > > feedback that convinces me it is a bad idea to do so ;) > > > > Thanks to all, > > Rainer > > _______________________________________________ > > 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 _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com
