[syslog-ng] [review request] 3.6queue/f/stats-reset

Balazs Scheidler bazsi77 at gmail.com
Wed Nov 20 12:08:18 CET 2013


On Mon, 2013-11-18 at 18:22 +0100, Gergely Nagy wrote:
> Evan Rempel <erempel at uvic.ca> writes:
> 
> > Perhaps the same logic can be used to identify those counters that have expired meaning that the stats-lifetime() has been exceeded,but
> > instead of dropping the stat counter at that time, the counter is just flagged for dropping.
> >
> > Then it becomes the job of the statistics logging, based on the stats-freq() value, to log AND drop those counters that
> > have been flagged as having exceeded the stats-lifetime().
> >
> > This way a counter is never dropped until it has exceeded the
> > stats-lifetime() AND has been logged.
> 
> That makes a lot of sense, but syslog-ng-ctl stats should not count (or
> perhaps only with a flag), precisely to avoid the scenario you outlined
> too.
> 

This really makes sense, however my issue is that stats-freq() is often
set to 0 which disables the Log statistics message currently. Relying
the cleanup mechanism on that would disable cleanup altogether in a lot
of setups.

hmm... maybe we should use stats-freq() if that's nonzero and
stats-lifetime() when it is zero. This way the cleanup mechanism would
kick in, without the risk of losing messages.

syslog-ng-ctl stats wouldn't prune counters.

This way, stats-freq() would be the one which actually clears counters,
we get rid of an additional iteration over the set of counters.

This paves the way for an improved log statistics message that could be
sent into graphite/logstash/whatever graphing application via standard
syslog-ng destination drivers, and all this without the risk of losing
counters.

What do you think?

-- 
Bazsi



More information about the syslog-ng mailing list