Not obvious that sampling for gauges and timers is client-side only #139

timblair opened this Issue Aug 8, 2012 · 3 comments


None yet

3 participants

timblair commented Aug 8, 2012

StatsD only deals with sampling data for counters but the README wasn't clear on this, so #138 has been raised to sort that out.

However, most (if not all) of the example clients "support" sampling for both gauges and timers too. For examples, see the Java, Ruby or Erlang clients. Each client applies the sampling internally and appends a |@...f field to the stat line, but that's then ignored by StatsD.

Do we need to find some way to make it obvious that should a client implement sampling for gauges and timers, then this is a client-side only feature, and has no effect once the data line reaches StatsD for processing, as it does for counters?

mrtazz commented Oct 10, 2012

I think it's a good idea to at least have it be consistent. So we either should remove the unnecessary appending of the sample rate or think about whether we want to have the sampling in StatsD.

@mrtazz mrtazz was assigned Oct 10, 2012

I came to open this exact issue. Sampling gauges and timers doesn't really make any sense server-side, and it's worth correcting the ambiguity in the README to indicate that all a sample rate does for these stats is to reduce the volume of UDP packets that get sent.

mrtazz commented Feb 8, 2013

fixed with the merge of #243

@mrtazz mrtazz closed this Feb 8, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment