Prometheus histogram versus summary
where quantiles are computed and whether they aggregate.
histograms expose bucket counts and let you compute aggregatable quantiles at query time; summaries compute fixed quantiles per instance that cannot be combined.
What's really being asked
Whether you understand the practical Prometheus consequence of computing quantiles client-side versus query-side, especially across many servers.
The full answer
A histogram samples observations into configurable cumulative buckets and exposes three things: the per-bucket counts as metric_bucket with a le label, the total metric_sum, and metric_count. Quantiles are not stored; you compute them at query time with histogram_quantile, and because bucket counts are additive you can sum buckets across the whole fleet first and then derive a correct fleet-wide quantile, bounded in accuracy by bucket width. A summary computes a fixed set of quantiles, like 0.5, 0.9, 0.99, locally on each instance over a sliding time window, and exposes them directly plus sum and count. Those quantiles are accurate for one instance but cannot be aggregated: you cannot validly combine per-instance p99 values. Summaries also lock in which quantiles exist when you write the code.
The mistakes people make
Saying you can average summary quantiles to get a fleet quantile. Claiming histograms give exact quantiles regardless of buckets. Ignoring that summaries do more work on the client and histograms can be heavier on series count due to buckets.
What usually comes next
How do you choose bucket boundaries? What do native or exponential histograms change? How does bucket count interact with label cardinality?
A concrete example
To measure p99 request latency across 30 servers, you instrument with a histogram http_request_duration_seconds. The query histogram_quantile(0.99, sum by (le) (rate(http_request_duration_seconds_bucket[5m]))) gives a correct fleet-wide p99. Had you used a summary, each server would report its own p99 and you would have no statistically valid way to combine them, so histograms are the right choice for fleet latency.
Interview question
For measuring p99 latency aggregated across a 30-server fleet, why are Prometheus histograms preferred over summaries?
- a.Histograms compute exact quantiles with no approximation
- b.Histogram buckets are additive so quantiles can be computed fleet-wideCorrect
- c.Summaries require more disk than histograms in every case
- d.Summaries cannot record request latency at all
Why? this is the answer
Histogram bucket counts sum across instances, so a correct fleet-wide quantile is computed at query time. Summary quantiles are per-instance and non-aggregatable; histograms are approximate, not exact.
Just read this? Test yourself on what you have been reading.
Read the original → prometheus.io
- #prometheus
- #histograms
- #summaries
- #latency
- #metric-types
Put your scrolling time to good use
Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on prometheus — each one lists the topics its interview covers.
See open roles