These are chat archives for HdrHistogram/HdrHistogram
@vladimir-bukhtoyarov's ideas in dropwizard/metrics#1016 are related.
I do of course agree re: the importance of reporting, but, IMO, its all for naught if the capturing bit doesn't manage to accurately record what is desired, in our cases, an atomic snapshot of all Metrics.
That said, I think the default/base impl of the Metrics, MetricRegistry, etc should maintain compatibility. Perhaps moving + increasing the visibility of the actual impl guts of those classes, and thus allowing for clean extensibility, could be a start?
@giltene I also love me some HdrHistogram :)
However, we should keep in mind that not all reporters are / will be live network connections to some variety of stats service. For example, the Metrics pipeline in the apps/services I'm working on are completely decoupled from (and know absolutely nothing about) the potential, eventual destination of their output, a remote Elastic Stack pipeline (Filebeat -> Logstash -> Elasticsearch <-> Kibana).
Periodically, my reporter is serializing all metric values as the fields of a Logstash JSON entry.
In the past, all of the values exposed by a given metric were being output (i.e. count, each of the percentiles, etc for histograms), but I'm working on limiting this down to just the raw "values" (ex. counts mapped to timestamps for timers) and having elasticsearch do the analysis + aggregation work (surprise, it also uses HdrHistogram :D).