Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

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

Closed
timblair opened this Issue · 3 comments

3 participants

@timblair

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
Owner

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
@mattspitz

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
Owner

fixed with the merge of #243

@mrtazz mrtazz 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.