Cardinality

Cardinality, in metrics systems, is the number of unique time series a metric creates. Every distinct combination of label values is a separate series that must be stored, indexed and queried. High cardinality means a metric has so many combinations that it strains the backend and raises cost.

How it works

Series count is the product of the number of values for each label. An http_requests_total metric with 5 routes, 4 methods and 6 status codes makes 120 series. Add a user_id label with 100,000 users and the same metric can reach 12 million series. Identifiers like user IDs, request IDs and pod IDs are the usual causes. Stable labels such as route, method, status, region or tenant tier keep counts bounded.

Why it matters in production

High cardinality slows queries, increases memory use in tools like Prometheus, and is a common driver of observability bills. In autoscaling clusters, labels such as pod IDs also churn, which creates series that are written once and never queried. Put per-request detail in traces or logs instead.

See also

• Observability

• OpenTelemetry Collector

• RED metrics

• Trace sampling

On the One2N blog

• Building observable Go APIs with OpenTelemetry & Prometheus

• The gotchas of OTEL collector processors for effective observability in K8s

References

1. Metric and label naming (Prometheus documentation)

2. Instrumentation: do not overuse labels (Prometheus documentation)