Technical
Simulator: cardinality explosion
For: engineers and SREs · architectsPrerequisites: Know what a metric and a label are.
A metric is often billed, and always sized, per active series, that is, per unique combination of label values. Cardinality is the product of the number of values of each label; for a classic histogram, multiply it by the number of buckets plus two, because each combination also produces a _sum and a _count series. The simulator applies this formula. Prices change fast and vary by contract: this guide gives none; use your provider’s dated price list. The price field is therefore empty: enter yours to get a monthly cost.
Metric: HTTP latency histogram
| Keep | Labels | Distinct values |
|---|---|---|
service | ||
endpoint | ||
method | ||
status_code | ||
pod | ||
user_idunbounded |
Assumptions
Each label combination produces one series per bucket, plus the histogram’s _sum and _count series. Orders of magnitude. Memory per series depends heavily on the backend (Prometheus, VictoriaMetrics, SaaS offerings): replace the assumption with your own value. The price is empty by default: enter the one from your provider’s dated price list to get the cost.
Things to try
Section titled “Things to try”- Start from the defaults: 268,800 active series and about 525 MB of memory.
- Tick
user_id: an unbounded label. Series count reaches 5.4 billion and memory 10 TB; with your price entered, cost is multiplied by 20,000 like the series. - Untick
pod(withuser_idunticked): aggregating per service rather than per pod divides series by six (44,800) without losing what you actually query. - Cut buckets from 12 to 8: 192,000 series instead of 268,800, an often forgotten lever on histograms.
The rule
Section titled “The rule”An unbounded identifier (user, request, session, raw URL) belongs in a trace or a log, never on a metric. To tie a metric to a specific request, use exemplars. Details in the business plane and the glossary.
Revised on 2 October 2026: prices removed; cost only shows with your price.