List a metric's labels and how many distinct values each one has. See how many time series that multiplies into, what it costs to store, and which label is to blame.
One row per label: its name and the number of distinct values it can take.
Runs entirely in your browser — nothing you enter here is sent to a server.
In Prometheus-style monitoring, every distinct combination of a metric name and its label values is a separate time series. A counter with a method label that takes 5 values is 5 series. Add status_code with 8 values and it is 40. Add endpoint with 60 and it is 2,400 — per instance. Cardinality is that product, and because it multiplies, one careless label can turn a harmless metric into millions of series.
Each series costs memory while it is active, disk for every sample and CPU on every query that touches it. On hosted platforms it is usually what you are billed for. A cardinality explosion is one of the commonest ways for a monitoring system to fall over — typically during an incident, when it is needed most.
User ids, email addresses, session ids, request ids, full URLs with parameters. Every new value is a new series, for ever. These belong in logs or traces.
A histogram stores one series per bucket, plus sum and count. Ten buckets turn every label combination into thirteen series.
Pods and containers get new names on every deploy. A label with the pod name creates fresh series each rollout, and the old ones linger until they expire.
Not every endpoint returns every status code. The "combinations that occur" setting scales the theoretical maximum down to something realistic.
/orders/{id}, never the real path.2xx, 4xx, 5xx where the exact code is not needed.topk(10, count by (__name__) ({__name__=~".+"})) shows your ten largest metrics.The number of distinct time series a metric produces: the product of the number of values of each of its labels. More labels and more values mean higher cardinality.
A single well-sized server manages a few million active series. Memory is the limit — roughly 3 to 4 KB per active series — so ten million series need tens of gigabytes of RAM.
Anything unbounded: user or customer ids, request ids, email addresses, IP addresses, full URLs, timestamps and error messages. Put those in logs and traces, not metric labels.
Run topk(10, count by (__name__) ({__name__=~".+"})) in Prometheus, or look at the TSDB status page, which lists the metrics and label names with the most series.
Upzilla checks your sites, servers and APIs around the clock and alerts you the moment something breaks. 10 monitors free, no card required.