This is a very valid request and I would like to have that myself. Unfortunately, the implementation is far from being trivial. It is not something that can be implemented as a side-activity. I understand that this is not easily to see.
Rsyslog has a modular architecture, so we have a variable set of stats counters. To support that, we need to introduce a new stats interface and some kind of registry for stats that are being gathered -- so that a process (periodic or on demand) can query and output that registry. Also, it is not obvious which counters should/can be provided. For example, what means "how long a message sits inside a queue". Does that mean time since enqueue? If so, we need to query system time for each message enqueued. Even more, we need to persist this timestamp together with the message object inside the queue (we need it to update the oldest timestamp on dequeue). However, the queue engine does not support such a data element. So we need to change the queue interface to not only contain a pointer to the message, but now a pointer to a structure that contains the stats-required entities together with a pointer to the message. That also has large performance implications. One may now argue that a simple solution is to store that timestamp inside the message object. However, this conflicts with the planned copy-on-write feature for the message object. This would always force a full copy due to the timestamp. There are some more subtle issues along all that, but I hope these samples get the idea over. Also, as David said, there are large performance implications. Even with lock-free sync, we do have hardware sync. My testing earlier this year showed that e.g. an atomic inc (without lock) has a very noticeable overhead (out of my had, I think far more than double the time required). So it is absolutely vital to implement counters in a way that they affect performance only then when stats functions are actually turned on. This most probably means that we need to implement some functions multiple times and select the one to use via a function pointer (which bears some overhead, but I consider that acceptable). As I said, I am interested in these stats myself very much, especially when I approach the next phase of performance enhancement later this year. Unfortunately, I am still working on some backlog and it would probably be counter-productive to stop doing these things and look into the stats issue (I once was close to implementing it, but then obviously more important things pushed it away). I thought about outputting main message queue size periodically (relatively simple to obtain and can already be queried via imdiag and diagtalker), but, honestly, how much does this small piece of information help...? In some configs maybe, in others it probably is quite misleading at best. When I approach the next tuning step, I will probably implement the stats registry and may make available some select counters via conditional compilation (that reduces the complexity of keeping the performance good if stats are not turned on). I know this is not the answer you looked for, but I hope it explains the situation. Feedback, of course, is always appreciated and it may be useful to talk about some counters that may be considered useful and potentially easy to obtain. Rainer > -----Original Message----- > From: [email protected] [mailto:rsyslog- > [email protected]] On Behalf Of Joe Williams > Sent: Tuesday, September 07, 2010 7:46 PM > To: rsyslog-users > Subject: [rsyslog] rsyslog stats > > > Is it possible log or output stats (ala haproxy's stats socket) for > rsyslog? I am thinking messages processed per second, messages written > to disk per second, etc. Maybe even timing for how long messages sit in > queues, etc. If not I would find this quite helpful when debugging, > perhaps this could be added to a future version? > > -Joe > > > Name: Joseph A. Williams > Email: [email protected] > Blog: http://www.joeandmotorboat.com/ > Twitter: http://twitter.com/williamsjoe > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com
