Just to prove the point: I have now implemented it. As expected, it is a very small code change (once you know where to apply it ;)). Have a look at the primary patch:
http://git.adiscon.com/?p=rsyslog.git;a=blobdiff;f=action.c;h=3a2584de0f 24fdf3f1af0c35748d29fe5e3a3845;hp=f72194059d41f011ae6daf6b6aa1a61d147255 3e;hb=1480263b026984a3d48a7f750a78911777464797;hpb=0a7f964436af73f2e7fbd 403b563f8d5a743f4a5 and note that most is comment. The amount of code actually executed each time is rater limited and does neither bear a large memory footprint, nor execution footprint. If the feature is not used, it is one simple branch. Even if it is used, the performance effects are very limited. Most importantly, a costly call to time() could be avoided by using the value that was already present (but needed a bit of reordering). I am going to this detail just to explain the fine difference between what belongs into the core (even though it is not "real core functionality") compared to what must not get into it. For example, if I had implemented that via a plugin, I would have needed at least one (indirectly addressed) procedure call branch, still an if, plus a return branch. Not good for speculative execution. Also, the plumbing would probably have required more code than the full patch shown (what means bad from a maintenance point of view as well a bad from a CPU memory cache point of view ;)). It remains the argument that if the code would not have been introduced, the core would be a little more slim. That's right ;) An easy solution would have been conditional compilation, but I have not applied it as I think the few extra bytes and CPU cycles really don't matter (that much). Just for you info... Rainer > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:rsyslog- > [EMAIL PROTECTED] On Behalf Of Rainer Gerhards > Sent: Friday, August 01, 2008 5:24 PM > To: rsyslog-users > Subject: Re: [rsyslog] Alert when multiple repeated lines are found > > Actually, in this case the (limited) functionality will go into the > core. But that's not because we need it for alerting but it is > something > that was scheduled for the core engine at all (because there are other > use cases besides alerting where you need it, e.g. start some > corrective > action only after the n-th error indication). Plus, it will be very > limited code. There are some other things, namely the enhanced rate > limiter, which will go to the core. I have some ways to do that via > plug-ins too, but given the expected complexity of this functionality > vs > the expected complexity of pluginizing them, the choice to go to core > is > really obvious. Another point where one could debate is enhanced > queuing. This, in the long term, is a candidate for being moved to a > plugin because many installations do never use disk-based (or assisted) > queues. > > Now comes the important difference: if a generic, any message let me > know when it happens n times in the row filter would have been needed, > that would NOT go into the core. Because it does not belong there. It > is > quite complex and even performance intense. For that, future version > will have customer (RainerScript) functions which can be provided by > library plugins. I have plans to implement such a beast (much later), > but it will come as a function that you provide the message to and that > is only loaded on an as-needed basis. > > I hope this clarifies. > > Rainer > > > -----Original Message----- > > From: [EMAIL PROTECTED] [mailto:rsyslog- > > [EMAIL PROTECTED] On Behalf Of (private) HKS > > Sent: Friday, August 01, 2008 5:17 PM > > To: rsyslog-users > > Subject: Re: [rsyslog] Alert when multiple repeated lines are found > > > > Thanks for the link, that post makes a lot of sense. I interpreted > > this discussion as moving towards adding alert functionality to the > > rsyslogd core - but your stance of keeping the rsyslogd core lean and > > efficient while plugins provide a full suite of event handling > > processes is reassuring. > > > > I'm looking forward to seeing where you take this plugin > architecture. > > > > -HKS > > > > On Fri, Aug 1, 2008 at 11:02 AM, Rainer Gerhards > > <[EMAIL PROTECTED]> wrote: > > > That's not a silly one ;) And it is coming up every now and then. > The > > > last time it came up, I was smart enough to write a blogpost: > > > http://blog.gerhards.net/2008/03/on-rsyslog-design-philosophy- > > plugins.ht > > > ml > > > > > > In short, and to this questions: there are different schools of > > thought. > > > If you think about a plain ole syslogd shuffling data to disk > files, > > you > > > do not need that. My vision of the syslogd (actually the "event > > logging > > > and alerting") subsystem is much broader. IMHO, it should support > > > anything that is needed to gather, process and persistently store > > > events. Also note that I say "events" for a reason - syslog > messages > > are > > > just a subset of the potential set of events. > > > > > > Rainer > > > > > >> -----Original Message----- > > >> From: [EMAIL PROTECTED] [mailto:rsyslog- > > >> [EMAIL PROTECTED] On Behalf Of (private) HKS > > >> Sent: Friday, August 01, 2008 4:25 PM > > >> To: rsyslog-users > > >> Subject: Re: [rsyslog] Alert when multiple repeated lines are > found > > >> > > >> This may be a silly question, but is the syslog daemon the proper > > >> place for something like this? > > >> > > >> -HKS > > >> > > >> On Fri, Aug 1, 2008 at 6:13 AM, Julian Yap <[EMAIL PROTECTED]> > > >> wrote: > > >> > Roger that Rainer. > > >> > > > >> > Thanks, > > >> > Julian > > >> > > > >> > On Thu, Jul 31, 2008 at 11:58 PM, Rainer Gerhards > > >> > <[EMAIL PROTECTED]> wrote: > > >> >> OK, that greatly simplifies things. Actually, it now boils down > > to > > >> >> "execute an action only on the n-the time the filter evaluates > to > > >> true". > > >> >> I think this is quite easy to implement, but I must verify > > that... > > >> >> > > >> >> Rainer > > >> _______________________________________________ > > >> rsyslog mailing list > > >> http://lists.adiscon.net/mailman/listinfo/rsyslog > > > _______________________________________________ > > > rsyslog mailing list > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog
