Cardinality: a metric http_requests_total{method, status, user_id} with 1 million user IDs creates 1 million time series. High cardinality strains metric storage and query performance in systems like Prometheus.
2 / 5
Why is user_id as a label considered a high-cardinality anti-pattern?
High-cardinality label: unbounded values (user IDs, request IDs, IP addresses) explode the number of series. Instead, aggregate to cohorts or use logs/traces for per-entity data and reserve metrics for aggregate counts.
3 / 5
What is a time series in Prometheus?
Time series:http_requests_total{method="GET", status="200"} is one series. Each unique label combination is a distinct series stored separately. The total series count is the primary capacity driver.
4 / 5
What strategy helps manage cardinality for request tracing labels?
Metrics vs traces: Prometheus is wrong for per-request granularity. Record aggregate metrics (p99 latency, error rate) in Prometheus and per-request detail in a tracing system like Jaeger or Tempo.
5 / 5
What is recording rule in Prometheus and how does it help cardinality?
Recording rule:sum(rate(http_requests_total[5m])) by (service) pre-aggregates across high-cardinality labels into a lower-cardinality result series. Dashboards query the cheap summary, not the expensive raw metric.