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 Universität +49 6172 31126 Frankfurt am Main, Germany va .@. org.chemie.uni-frankfurt.de (remove the dots, please)