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: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> bounces at lists.adiscon.com] 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: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> > bounces at lists.adiscon.com] 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
> > <rgerhards at hq.adiscon.com> 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: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> > >> bounces at lists.adiscon.com] 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
<julianokyap at gmail.com>
> > >> wrote:
> > >> > Roger that Rainer.
> > >> >
> > >> > Thanks,
> > >> > Julian
> > >> >
> > >> > On Thu, Jul 31, 2008 at 11:58 PM, Rainer Gerhards
> > >> > <rgerhards at hq.adiscon.com> 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