Previously the docs indicated that "[statsdaemon] yields the exact same
metrics as etsy's statsd with legacy namespace and deleteGauges
enabled)". This implies that the behavior w.r.t. other delete* statsd
config options is in line with the defaults (deleteTimers=false and
deleteCounters=false). It seems though the behavior w.r.t. these types
of metrics is actually like deleteTimers=true and deleteCounters=true.
Given this, update the docs to reflect that overall behavior is really
comparable to the statsd configuration deleteIdleStats=true
(encompassing the various configs above).
One case where you can see this behavior difference is when either
timers or counters are sent input less frequently than the configured
flush intervals. In these cases, statsdaemon will not send any metrics
info to Graphite during the periods without input, while statsd in its
default configuration will send e.g. 0 valued metrics to Graphite for
counters.
Unfortunately this behavior difference prevented us from immediately
moving from statsd to stasdaemon. If you're interested, I'd consider
submitting a path that optionally preserved this aspect of statsd
behavior.
Previously the docs indicated that "[statsdaemon] yields the exact same metrics as etsy's statsd with legacy namespace and deleteGauges enabled)". This implies that the behavior w.r.t. other delete* statsd config options is in line with the defaults (deleteTimers=false and deleteCounters=false). It seems though the behavior w.r.t. these types of metrics is actually like deleteTimers=true and deleteCounters=true. Given this, update the docs to reflect that overall behavior is really comparable to the statsd configuration deleteIdleStats=true (encompassing the various configs above).
One case where you can see this behavior difference is when either timers or counters are sent input less frequently than the configured flush intervals. In these cases, statsdaemon will not send any metrics info to Graphite during the periods without input, while statsd in its default configuration will send e.g. 0 valued metrics to Graphite for counters.
Unfortunately this behavior difference prevented us from immediately moving from statsd to stasdaemon. If you're interested, I'd consider submitting a path that optionally preserved this aspect of statsd behavior.