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?
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.
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.
fixed with the merge of #243