Metrics(Telemetry) what data types are people using?

[Heiko Rupp]

Hi,

in todays Metrics call we discussed supporting of various (data) types.

I am thinking we should do KISS and only support counters and gauges. 

And then there are frameworks / applications like DropWizard Metrics[1] or Prometheus[2] that also support complex types like histograms, meters, timers and summary.

Now my question is: do people really use those more complex types like histograms? 

While I can see the usefulness, I also fear the additional complexity and would only like to add them if people are really using them and not on the potential usefulness. See also [3], where the Metrics spec should not end up in the lowest of the 3 items. 

[1] http://metrics.dropwizard.io/3.1.0/manual/core/

[2] https://prometheus.io/docs/concepts/metric_types/

[3] https://www.baekdal.com/blog/company-application-complexity

[donbo...@gmail.com]

I think Timers are quite important.  If a servlet is performing poorly, for example, a Timer would be the best way to see that.  In dropwizard, timers are a composite type that essentially combine histograms and meters.  The histogram part is to be able to record duration percentiles (eg. 95% of the time this servlet responded within n millis).  The meter part is to be able to record rates (eg. this servlet has been requested 100 times in the last 5 minutes).  Dropwizard timers also provide that info based on exponentially weighted moving averages -- meaning that I can see the response time of requests that have happened in the last few minutes, not just the response time since the server started.  If we only have counters/gauges, a user could see how many hits there are to a servlet, and what the total time is for all hits to a servlet, but just knowing the average response time since server startup doesn't tell the whole story.

[Heiko Rupp]

Couldn't that be replaced by more often polling the servlet counters / gauges?

[donbo...@gmail.com]

You could do everything a Timer does using a bunch of gauges and some somewhat complex sampling logic.

Using servlet response time as a concrete example of something you might time, a Timer gives you:

from roughly last 5 min of timing samples...

    the longest response time 

    the shortest response time

    the average response time

    the median response time

    the 99th percentile response time

    the 95th percentile response time

    the ... percentile response time

plus...

    the rate of requests in last 15 min

    the rate of requests in last 5 min

    the rate of requests in last 1 min

    the average rate of requests since the Timer was created

So - yes, you could manually create all of those gauges for each thing you wanted to time (and implement the exponentially weighted sampling logic yourself), and remember to carefully use them all wherever you want to time something for consistency, but it would be painful.