Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

New metric type fixed histogram #43

Open
mixalturek opened this issue Jan 22, 2019 · 1 comment
Open

New metric type fixed histogram #43

mixalturek opened this issue Jan 22, 2019 · 1 comment

Comments

@mixalturek
Copy link
Contributor

It would be nice to have at least basic support for histograms. I know it's one of the non-goals, but the note was probably meant as expensive computation of various percentiles (which are in fact no histograms). https://en.wikipedia.org/wiki/Histogram

A histogram built on top of a small set of Counters with fixed predefined ranges should be quite simple to implement using API that Dipstick already provides and still quite powerful and with a great performance.

// Ranges and counters for: 'less', 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 'more'
let histogram = metrics.histogram("hist", Histogram::unit_step(0, 10));

// Ranges and counters for: 'less', 0-2, 3-5, 6-8, 9-11, 'more'
let histogram = metrics.histogram("hist", Histogram::const_step(0, 11, 3));

// Ranges and counters for: 'less', 0, 1, 2-4, 5-9, 10-49, 50-99, 100-999, 'more'
let histogram = metrics.histogram("hist", Histogram::steps(vec![0, 1, 2, 5, 10, 50, 100, 1000]));

What do you think? I'm ready to contribute, I'm asking in advance...

@fralalonde
Copy link
Owner

I know other libraries do it this way but I would not define a Histogram as a metric type, this is "premature configuration" i.e. the code defining the instrument should not have to care about what statistics will be tracked, not to mention what range of values are expected - all those things that could be very well put in a dynamic config file.

If Dipstick was to do histograms, it would be at the Bucket level. If you have a very fast way of doing it it could be an optional set of stats maintained by the AtomicBucket, or it could be new separate bucket type that can be joined to an AtomicBucket (if regular stats are also needed) using MultiInput. Or there could be a special multi-bucket wrapper to allow combining different buckets and have them act a single entity with regards to drain / flush.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants