Metrics

In the dominant dimensional data model, popularised by Prometheus and adopted by OpenTelemetry, a time series is identified by a metric name plus a set of label key-value pairs, and holds a sequence of (timestamp, value) samples. Every distinct combination of label values is a separate series, so the cost of a metric is roughly the product of its label cardinalities. Putting unbounded values such as user IDs, request IDs or raw URLs into labels is the classic way to exhaust memory in a time-series database; such detail belongs in logs, traces or exemplars instead.

Prometheus defines four metric types. A counter only increases, apart from resets to zero when a process restarts, and is queried with rate() or increase(), which detect and compensate for resets; a gauge goes up and down (queue depth, memory in use); a histogram counts observations into cumulative buckets (le labels) plus a sum and a count, so quantiles can be estimated server-side with histogram_quantile() and aggregated across instances; a summary computes quantiles in the client, which is precise per instance but cannot be meaningfully averaged across instances. Bucket boundaries fix the achievable precision, which is why OpenTelemetry exponential histograms and Prometheus native histograms use automatically scaled bucket layouts. OpenTelemetry instruments (Counter, UpDownCounter, Histogram, Gauge and asynchronous observable variants) map onto these, with an additional choice of cumulative or delta aggregation temporality that must match what the backend expects.

Collection is either pull, where Prometheus scrapes an HTTP endpoint exposing the text or OpenMetrics format at a scrape interval (the global default is one minute, commonly set to 15 or 30 seconds), or push, as with OTLP export, StatsD or remote write. Pull makes a missing target visible through the synthetic up series; push suits short-lived jobs and crosses network boundaries more easily. Storage engines compress samples heavily with delta-of-delta timestamp and XOR value encoding, derived from Facebook's Gorilla paper, and long retention is handled by downsampling in systems such as Thanos, Mimir or VictoriaMetrics.

Useful selection frameworks are the four golden signals (latency, traffic, errors, saturation) for services, Brendan Gregg's USE method (utilisation, saturation, errors) for resources, and the RED method (rate, errors, duration) for request-driven services. Common analytical errors include averaging percentiles, which is mathematically invalid, alerting on averages that hide tail latency, and computing rate() over a range shorter than two scrape intervals. Metrics are aggregates by design: they show that the error rate rose but not which request failed, which is why they are the basis for SLIs and alerts while traces and logs carry per-event detail.