The four Prometheus metric types, explained

Prometheus instrumentation commonly uses four metric types: counters for cumulative events, gauges for values that rise or fall, histograms for distributions, and summaries for distributions with optional client-computed quantiles. The type determines which calculations make sense.

Counter: events accumulated over time

A counter increases as events occur and can reset, usually when the process restarts. Examples include completed requests, errors, or orders. Use rate for a per-second rate or increase for an estimated increase over a window:

rate(http_requests_total[5m])

You can inspect a raw counter, but it does not by itself describe current traffic. Apply the rate calculation before aggregating across independently resetting counters.

Gauge: a value that can go up or down

Gauges describe current state: available memory, queue depth, open connections, or temperature. Query the value directly, for example with Node Exporter:

node_memory_MemAvailable_bytes

Do not apply a counter rate function to an ordinary gauge merely because the value changes.

Histogram: a distribution you can aggregate

A classic histogram exposes bucket counters, plus a count and sum. A latency histogram might expose request_duration_seconds_bucket{le="0.5"} for observations at or below half a second.

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

This estimates P95 across the selected instances, assuming compatible classic bucket boundaries. Keep additional labels in the aggregation when you want separate results per service. Native histograms represent distributions differently and do not use this _bucket query form.

Summary: quantiles computed by the client

A summary exposes count and sum, and may expose configured quantiles such as {quantile="0.95"}. Those quantiles reflect the client's configured calculation window and cannot be combined into a correct fleet-wide P95 by averaging or summing them.

The sum and count can still be aggregated where their semantics permit. When cross-instance latency quantiles are the goal, a histogram is usually the more suitable choice.

Quick selection guide

FAQ

How should I choose classic histogram boundaries? Put boundaries around operational thresholds. For a 500 ms latency objective, boundaries such as 0.05, 0.1, 0.25, 0.5, and 1 second might be a starting point. Choose the actual range and resolution from the workload.

Can I change a metric's type? Avoid reusing one name with incompatible semantics. Client libraries can reject conflicting registrations, and existing queries may become misleading. Introduce a clearly named replacement and migrate dashboards and rules deliberately.

Sources

This guide is based on the documentation below; the examples have not been tested against a live deployment.

• Prometheus metric types
• Histograms and summaries