What use cases really make prometheus's summary metrics type necessary/unique?

For prometheus metrics collection, like title, i could not really find an use case which only can be done via the type Summary, seems that they all somehow can be done via the type Histogram also.

Lets take the request concurrency metrics as example, no doubt this can be perfectly done via type Summary, but i can also achieve the same effect by using type Histogram, as below:

type Summary

type Histogram

rate(http_request_duration_seconds_sum[1s]) / rate(http_request_duration_seconds_count[1s])

The only difference i can see is: for a summary the percentiles are computed in the client, it is made of a count and sum counters (like in Histogram type) and resulting quantile values.

So i am a bit lost on what use cases really make the type Summary necessary/unique, please help to inspire me.

type Summary

1 Answer
1

The Summary metric is not unique, many other instrumentation systems offer similar - such as Dropwizard's Histogram type (it's a histogram internally, but exposed as a quantile). This is one reason it exists, so such types from other instrumentation systems can be mapped more cleanly.

Another reason it exists is historical. In Prometheus the Summary came before the Histogram, and the general recommendation is to use a Histogram as it's aggregatable where the Summary's quantiles are not. On the other hand histograms require you to pre-select buckets in other to be aggregatable and allow analysis over arbitrary time frames.

There is a longer comparison of the two types in the docs.

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.