You can clone with
HTTPS or Subversion.
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"
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.
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:
Interesting patch. Do you only do that for counters or generally all metrics?
We're only doing it on counters, but to be honest I haven't used timings or other features much myself.
ok, might make sense to change that for all metrics.
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.
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.
okay both #183 and #199 are merged, so I can close this one.