Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

"reset to 0 on flush" behavior of counter is not clear #140

Closed
Dieterbe opened this Issue · 8 comments

3 participants

@Dieterbe

nothing about the word 'counter' suggests anything about automatic resetting to 0 on each flush.
This is very confusing for newcomers. When I hear the word "counter" I actually think of something like a gauge that keeps incrementing, like rx/tx packet counters. I think I'm not the only one

I suggest to rename the "counter" metric to "bucket"

@mrtazz
Owner

I think the name counter is fairly appropriate, given the fact, that we are simply counting things. The fact that StatsD only persists those until the next flush interval has nothing to do with that name imho. Maybe the docs should make the effect of flushing a little clearer.

@fooblahblah

We've also found that simply reseting counters to 0 effectively creates a load on graphite which is proportional to all the metrics ever seen. This eventually causes high load on Graphite. I've been running the following patch for months to remove stale counter keys entirely:

https://gist.github.com/3625157

@mrtazz
Owner

Interesting patch. Do you only do that for counters or generally all metrics?

@fooblahblah

We're only doing it on counters, but to be honest I haven't used timings or other features much myself.

@mrtazz
Owner

ok, might make sense to change that for all metrics.

@fooblahblah

Yeah, I was just looking at stats.js, clear_metrics callback and I think it makes sense for timers too. I just updated to the latest statsd today, so I'm not too familiar with the newer code yet.

@Dieterbe

I think this patch should be applied, not just to lower the load (as is @fooblahblah use case) but also this is more useful when you switch to a different server. if statsd doesn't receive any packets for a counter, it should not keep submitting packets to graphite saying the counter is 0. i would argue that if statsd doesn't receive any packet for a metric, it should not send packets to graphite for that metric. the value will become null in graphite and that makes sense. also, this can happen when you rename a metric.

@mrtazz mrtazz was assigned
@Dieterbe

okay both #183 and #199 are merged, so I can close this one.

@Dieterbe Dieterbe closed this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.