You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently gauges are just an alias for KV. In statsite as far as I can see, it just passes through every input value, with prefix and timestamp added when flushed.
But in statsd gauges are supposed to be a 'sticky' value, thus only the latest value is sent, and it is kept between flushes. (This last part can disabled though).
For a graphite backend, I guess it will just overwrite the value with the latest as all of them have the same timestamp. But there is no need for actually storing and tracking all values?
The text was updated successfully, but these errors were encountered:
You are right! Statsd previously had key/value support, and I thought they merely renamed it to gauges but that they functioned the same. I didn't realize there was a semantic difference.
Are you interested in patching this? If not, I can work on changing the storage of gauges to a hashmap instead.
Just shipped version 0.5.0 which supports gauges that are "sticky". They do not support the +/- ability of statsd, but will retain the last value. Marking this as closed!
Currently gauges are just an alias for KV. In statsite as far as I can see, it just passes through every input value, with prefix and timestamp added when flushed.
But in statsd gauges are supposed to be a 'sticky' value, thus only the latest value is sent, and it is kept between flushes. (This last part can disabled though).
For a graphite backend, I guess it will just overwrite the value with the latest as all of them have the same timestamp. But there is no need for actually storing and tracking all values?
The text was updated successfully, but these errors were encountered: