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