I thing it would be very useful to use the statistics to determine how close the buffering has gotten to the limit of the log_fifo_size before messages start being dropped. This information can be used to; - proactively change the configuration on a host. - calculate the rate of buffer consumption and predict how much time will elapse before dropping will start. Alerts to system operators can be created prior to messages being dropped. This information can be calculated from having the number of messages queued, and the log_fifo_size for the destination, or a percentage full could be used. I would prefer the log_fifo_size. I would also prefer to see all of the stats for a destination on a single line. Programaticaly it is easier to split the numbers up than it is the try to join them back together based on the first three fields of a stat line dst.file;d_var_syslog#0;/var/log/syslog.20120908.000000;a;dropped;0 dst.file;d_var_syslog#0;/var/log/syslog.20120908.000000;a;processed;326 dst.file;d_var_syslog#0;/var/log/syslog.20120908.000000;a;stored;0 Something like dst.file;d_var_syslog#0;/var/log/syslog.20120908.000000;a;0;326;0;5000,1347143526 where the 4 numbers are dropped, processed, stored, fifo_size and stamp or two different formats, one for source and one for destination src.file;local#2;/proc/kmsg;a;1549;1347143526 dst.file;d_var_syslog#0;/var/log/syslog.20120908.000000;a;0;326;0;5000 where src has processed and stamp dst has dropped, processed, stored, fifo_size Possibly the source could also show the flow-control state as well, or even better, the flow control duration, so if a source has been blocked for x number of seconds I can alert an operations center about the condition. Thanks again for your consideration. Evan.