Re[2]: [syslog-ng]Full pipe as destination

Thu, 23 Aug 2001 13:33:56 +0200

I agree with Herr Apelt.  The need for immediate notification needs to be
weighed against the traffic coming out of an already overburdened service.
A separate process listening for such things coming from the internal source
should be sufficient to catch the necessary information.  What you don't
want to do is send a stream of data from the internal source when you are
already dropping messages.  A statistical notification every 12 or 24 hours
is great but there definitely would need to be some sort of immediate
notification so action can be taken to correct any problems.  I think using
the internal channel would allow for the least amount of development work
and still give a desired result.

Regards,
Drew

-----Original Message-----
From: Volker Apelt [mailto:volker_apelt@yahoo.de]
Sent: Thursday, August 23, 2001 12:57 PM
To: syslog-ng@lists.balabit.hu
Subject: Re[2]: [syslog-ng]Full pipe as destination

On Thu, 23 Aug 2001 10:44:50 +0200 Andreas Schulze
<andreas.schulze@mediaways.net> wrote:

> Dear Bazsi,
> Brad Arlt schrieb:
> > > logs are silently dropped in this case. I was thinking of implementing
some
> > > kind of automatic statistics message to report log losses, but that
would
> > > race against normal log traffic. do you have a better idea.
>
> statistics are a very good idea and for many syslog-ng users its
> important to know as most as possible about messages dropped
> (for which destination, etc.), messages transfered by source ond/or
> destination and something more.
>
> I think the discussions about possible log destinations hasn't the real
> impact in this context.
> 
> as you say its important that we prevent the daemon from stucks
> in-active with its internal statistics stuff.
> the real problem here is, to implement the output method of the stat.
> informations. 
> but answer the following question: "is it really mandatory to realize
> a continuous output of statistical informations?"
> I think not.
> 
> decide to which logging destination the stats should be send.
> I think the internal() log source is a better choice than brad's "oh
> shit!" file, because we keep save the flexibility of syslog-ng's
rule-based flow
> control. but a separate log is ok.
> 
> but don't send the stats continuously to internal(). do this e.g. at
> midnight for the last 24h. realize a command line switch to disable this
feature.

Sending it to the internal() queue, with serverity=alert or crit, sounds
good. 
To me, it is important to get the notification about dropped messages
immediately, because it requires some reaction. Maybe with a 'maximum
notifications per minute' brake to avoid race conditions or as 
"minimal notification time distance" implemented as a time stamp 
when the last emergency message was emitted.

--
Volker Apelt                 Group of Prof. Dr. Ch. Griesinger
Dipl. Chem.                  Johann Wolfgang Goethe Universitat 
+49 6172 31126               Frankfurt am Main, Germany 
va  .@.  org.chemie.uni-frankfurt.de (remove the dots, please)   

_______________________________________________
syslog-ng maillist  -  syslog-ng@lists.balabit.hu
https://lists.balabit.hu/mailman/listinfo/syslog-ng