Open MaxGabriel opened 8 years ago
Edited: Ignore me! I see there's already a client you've written.
It might be possible to make ekg work with the statsd approach, but it would require reworking the internals (e.g. so that each metric update results in a callback, from which we could send a packet to statsd).
Were you thinking of just implementing the callback and no StatsD client?
The best way I know how to do this is by storing histograms (not the theoretically best approach, but the best engineering approach) and computing approximate percentiles from that.
Have you seen HdrHistogram? It's a preferred alternative to an ordinary histogram since it avoids coordinated omission.
Have you seen HdrHistogram? It's a preferred alternative to an ordinary histogram since it avoids coordinated omission.
I have. Unfortunately I believe they suffer from the same problem as most "theoretically better than a histogram" approaches, namely that you cannot merge two HdrHistograms created on different machines. Being able to gather statistics separately and then compute global quantiles is a really important property.
Being able to gather statistics separately and then compute global quantiles is a really important property.
Absolutely agree here as well. I've seen both approaches used in tandem to good effect.
Thanks!
A nice feature of StatsD's timers is that they track percentiles, in addition to things that
Distribution
already tracks like the min, max, mean, etc. Having e.g. 99th and 95th percentile data is useful when you know the mean could be biased by outliers. For example:@tibbe had this to say about the implementation: