What is the difference between a counter and a gauge?

A counter only ever increases (or resets to zero on restart) and is used for cumulative totals like requests served. A gauge can go up or down and represents an instantaneous value like memory in use or queue depth.

When should I use a histogram versus a summary?

Use a histogram when you need aggregatable quantiles across instances or want to compute percentiles with histogram_quantile in PromQL. Use a summary when you need exact client-side quantiles for a single instance and do not need to aggregate them.

Why must I use rate() on counters?

Counters store ever-growing totals, so the raw value is not useful on its own. rate() and increase() compute the per-second or total change over a time window and correctly handle counter resets when a process restarts.

What suffix metrics does a histogram expose?

A histogram named x exposes x_bucket with a le label for each upper bound, x_sum for the total of observed values, and x_count for the number of observations. histogram_quantile uses the _bucket series to estimate percentiles.

What are the Prometheus metric naming conventions?

Use a base unit suffix such as _seconds or _bytes, _total for counters, and snake_case with an application or subsystem prefix. Avoid putting the unit in a label; the name should fully describe what is measured.

What is the Prometheus Metric Types Reference?

Reference for Prometheus metric types with data model, naming conventions and PromQL function applicability. Understand counters, gauges, histograms and summaries and when to use each. It runs free in your browser on Gera Tools, with nothing uploaded.

Prometheus Metric Types Reference

Name: Prometheus Metric Types Reference
Creator: Gera Tools
License: https://creativecommons.org/licenses/by/4.0/

Get one useful tool a week

Like this tool? Enter your email and we'll send you one genuinely useful Gera tool a week — plus a link to come back to this one. No spam, one-click unsubscribe any time.

Prometheus metric types reference

Prometheus has four core metric types — Counter, Gauge, Histogram, and Summary — each with its own data model, exposition output, and the set of PromQL functions that make sense for it. Choosing the right type is the single most important modelling decision when instrumenting a service. This reference summarizes each type, what it exposes, and how to query it.

The four types at a glance

Type	Changes over time	Typical use	Key PromQL functions
Counter	Only increases (resets to 0 on restart)	Request count, errors, bytes sent	`rate()`, `increase()`
Gauge	Can go up or down	Memory in use, queue depth, temperature	`avg_over_time()`, `delta()`, `deriv()`
Histogram	Counts observations into buckets	Request latency, response size	`histogram_quantile()`, `rate()` on `_bucket`
Summary	Client-side quantiles	Latency (single-instance, no aggregation needed)	Direct `quantile` label, `rate()` on `_count`

How it works

A Counter is a monotonically increasing value; it only resets to zero when the process restarts. You never read its raw value directly — you apply rate() or increase() to get throughput, both of which detect and correct for resets. A Gauge is a snapshot that can rise and fall; functions like avg_over_time, delta, and deriv apply.

A Histogram counts observations into configurable buckets and exposes three series: _bucket{le=...} (cumulative counts per upper bound), _sum, and _count. histogram_quantile() interpolates percentiles from the buckets, and because buckets are additive you can aggregate across instances before computing the quantile. A Summary computes client-side quantiles directly (exposed with a quantile label) plus _sum and _count; its quantiles cannot be meaningfully aggregated across instances.

Naming conventions

Prometheus naming conventions exist so alerts and dashboards stay consistent across services:

Use snake_case with a service prefix: http_requests_total, database_query_duration_seconds.
Append _total to counter names.
Use base units as the suffix — _seconds not _milliseconds, _bytes not _megabytes. Let PromQL convert at query time.
For histograms, the base name (e.g., http_request_duration_seconds) automatically produces _bucket, _sum, and _count series — do not add those suffixes yourself.

PromQL examples

Compute request throughput and error ratio from counters:

rate(http_requests_total[5m])

sum(rate(http_requests_total{code=~"5.."}[5m]))
  / sum(rate(http_requests_total[5m]))

Estimate the 95th percentile latency from a histogram — aggregating across all replicas first, then computing the quantile:

histogram_quantile(0.95,
  sum by (le) (rate(http_request_duration_seconds_bucket[5m])))

Prefer histograms over summaries when you run more than one replica, because histogram buckets are additive and can be summed across instances before the quantile is computed. Summaries compute quantiles on the client and cannot be meaningfully aggregated — you would get different percentile values per instance with no way to combine them. Align histogram bucket boundaries to your SLOs so the important thresholds (200ms, 500ms, 1s) fall on bucket edges rather than being interpolated.