Counter / gauge / histogram
Counter counts events, gauge shows the current level, histogram shows how measurements are spread across buckets.
See it
What it is
Counter, gauge, and histogram are the three metric shapes you reach for most often. A counter accumulates events and only rises until its process resets, such as total requests. A gauge is a current reading that can rise or fall, such as queue depth. A histogram sorts many observations into buckets, such as request durations under 100ms, 250ms, and 1s, so you can see a distribution instead of one average.
Use a counter for 'how many happened', then graph its rate or increase. Use a gauge for 'how many exist right now'. Use a histogram when the shape matters, especially latency or payload size, where an average can hide a painful tail. Prometheus histograms also expose a count and sum, and their buckets let you estimate percentiles across many instances.
Gotcha: a counter can reset when a process restarts, so never subtract raw samples by hand when the query system has a reset-aware rate function. Classic histogram buckets must be chosen before the measurements arrive, though Prometheus native histograms bucket automatically. If every useful request lands in the final +Inf bucket, the data is valid but tells you almost nothing.
Ask AI for it
Instrument this HTTP service with Prometheus metrics. Add a counter named http_requests_total, a gauge named http_requests_in_flight, and a histogram named http_request_duration_seconds with buckets at 0.05, 0.1, 0.25, 0.5, 1, 2.5, and 5 seconds. Label them only with method, route template, and status class. Expose /metrics, then write PromQL panels using rate(http_requests_total[5m]) for traffic and histogram_quantile(0.95, sum by (le, route) (rate(http_request_duration_seconds_bucket[5m]))) for p95 latency. Handle counter resets with rate rather than subtracting raw samples.