What is high-cardinality data in Prometheus?
Understanding time-series storage cost.
Cardinality is the count of unique label combinations; each is a separate series; explosion blows up memory and query cost.
WHAT THIS TESTS This evaluates whether you understand the dominant cost driver in pull-based time-series systems and can propose realistic mitigations rather than just naming the problem.
A GOOD ANSWER COVERS Cardinality is the number of distinct time series produced by a metric, which equals the number of unique combinations of its label values. Prometheus creates and stores one independent series per combination, holding active series in memory. High cardinality arises when a label has many or unbounded values, such as user_id, request_id, email, or full URL paths. Because combinations multiply, adding two high-cardinality labels causes a combinatorial explosion. The consequences are severe: ballooning memory for the head block, slower and heavier queries, longer compaction, and eventual out-of-memory crashes.
COMMON WRONG ANSWERS Confusing cardinality with the number of samples or the scrape interval, which affects volume per series but not series count. Another mistake is suggesting you simply scrape less often, which does not reduce series. Adding a unique identifier as a label is the classic anti-pattern.
LIKELY FOLLOW-UPS How do you detect a cardinality spike before it crashes the server? Where should per-user dimensions live instead? How do recording rules help? What about remote-write and downsampling?
ONE CONCRETE EXAMPLE Suppose you expose http_requests_total with labels path and user_id. With one thousand paths and one hundred thousand users you risk up to one hundred million series. Strategy one: drop user_id and keep only bounded labels like method, status code, and a normalized route template such as /users/:id rather than the raw path; push user-level detail to logs or traces keyed by trace ID. Strategy two: aggregate at ingestion using recording rules or relabeling so only summarized series are stored, and apply downsampling or remote-write to a long-term store. Both collapse the series count back to a manageable, bounded number while preserving the dimensions that actually drive alerts.
Read the original → prometheus.io
Get five bites like this every day.
Tezvyn delivers a daily feed of 60-second tech bites with quizzes to lock in what you learn.