syslogng@feystorm.net writes:

Largely, this is just so that one can easily tell if processing has changed in a certain time period without having to do the math.

Additionally it also would help a great deal with system health monitoring software.

I'd say it would be the job of the system health monitoring software to keep state, and notice differences. It pretty much has to be able to do that anyway, as a large number of software (ifconfig and syslog-ng included, for example) do not reset their counters, for a good reason.

For example, something could look to see if syslog-ng has dropped any messages, but as it currently is it would have to compare the most recent stats with the previous set of stats just to see if the dropped counter went up.

Yep, and I believe that's good so. For example, if syslog-ng-ctl stats would reset the counters, then I wouldn't be able to look at the stats by hand if a monitoring software would be running aswell: one or the other would reset the stats, making it useless for the other. Of course, this could be worked around with a --reset or --no-reset option, or even a separate syslog-ng-ctl reset-stats command, but.. It's easier to teach monitoring systems to keep state. Most can already do that, anyway. For manual inspection, one can use a shell script like the following: ,---- | #! /bin/sh | set -e | | if [ -e "/var/cache/syslog-ng.stats" ]; then | mv -f /var/cache/syslog-ng.stats /var/cache/syslog-ng.stats.old | fi | | touch /var/cache/syslog-ng.stats.old | | syslog-ng-ctl stats >/var/cache/syslog-ng.stats | | diff -u /var/cache/syslog-ng.stats.old /var/cache/syslog-ng.stats `---- This can easily be enhanced to parse the stats output, and present the difference in a more human friendly way, and does not need a single change to syslog-ng itself. -- |8]