I am struggling a bit with the counter. I am aware that I might not be expressing my thoughts as clearly as I thought, but I am trying to think through how I want metrology to work for me here.
I tend to want to have a per second rate in my stats backend for things. The problem with the counter is that it just keeps counting up. The meter is the same: It adds a moving average which is useful, but not the same thing, and the mean_rate, which just keeps going from the start point.
I suppose I want the behaviour I would be getting from a statsd counter. I send it the events, and statsd will calculate the per second rate, and send that to the backend. Basically, I need to call counter.clear() after sending the current metrology counter value to the backend, to get a new mean_rate for the next flush interval. But that means I lose the total, and moving average values, too.
I had a look at how the metrology statsd reporter handles this, and my guess it is doing the wrong thing. It is just sending the current, continually incrementing value of the counter to statsd, whereas statsd would expect to receive the increment() calls instead.
I kind of see metrology as a replacement for statsd. Rather than sending UDP to statsd, the metrics are in-process, and gets flushed to, say InfluxDB, once every couple of seconds. If a statsd counter gives me a per second rate for the last flush interval, how do I do this with metrology?
The best I can think of is using the Meter, and clearing it after every flush. If I want to send both the per-second rate for every flush, plus the moving average over the whole process, then I basically need to add a feature to Meter to only clear the counter, but keep the moving averages.
I am struggling a bit with the counter. I am aware that I might not be expressing my thoughts as clearly as I thought, but I am trying to think through how I want metrology to work for me here.
I tend to want to have a per second rate in my stats backend for things. The problem with the counter is that it just keeps counting up. The meter is the same: It adds a moving average which is useful, but not the same thing, and the mean_rate, which just keeps going from the start point.
I suppose I want the behaviour I would be getting from a statsd counter. I send it the events, and statsd will calculate the per second rate, and send that to the backend. Basically, I need to call
counter.clear()
after sending the current metrology counter value to the backend, to get a new mean_rate for the next flush interval. But that means I lose the total, and moving average values, too.I had a look at how the metrology statsd reporter handles this, and my guess it is doing the wrong thing. It is just sending the current, continually incrementing value of the counter to statsd, whereas statsd would expect to receive the
increment()
calls instead.I kind of see metrology as a replacement for statsd. Rather than sending UDP to statsd, the metrics are in-process, and gets flushed to, say InfluxDB, once every couple of seconds. If a statsd counter gives me a per second rate for the last flush interval, how do I do this with metrology?
The best I can think of is using the Meter, and clearing it after every flush. If I want to send both the per-second rate for every flush, plus the moving average over the whole process, then I basically need to add a feature to Meter to only clear the counter, but keep the moving averages.