# Cardinality — Prometheus + Grafana

Source: https://www.skillbyai.com/en/prometheus-grafana/o-cardinality

> The number of series is the cost.

## Unbounded labels explode series counts

Prometheus memory and storage scale with the number of **active series**. Each label multiplies series: 50 routes × 5 status codes × 4 methods × 20 instances is already 20,000 series for one metric. Labels with unbounded values (user IDs, email addresses, raw URLs, request IDs, timestamps) can create millions and crash the server. Inspect the TSDB status page in the Prometheus UI or count series per metric, drop unneeded labels with relabelling, and keep high-cardinality details in logs and traces instead.

## Reliable, scalable monitoring

Controlling cardinality, planning storage and following proven methods keep monitoring trustworthy.

![Four ideas: cardinality, storage and scaling, RED and USE, checklist.](assets/figures/prometheus-grafana/section-8-map.svg) — Figure 8.1 — Cardinality, scaling, methods and checklist.

## Finding expensive metrics

PromQL queries for cardinality (can be heavy on large servers; run them carefully).

```promql
# top 10 metric names by number of series
topk(10, count by (__name__) ({__name__=~".+"}))

# series per label value for one metric
count by (route) (http_requests_total)

# total series scraped from each job
sum by (job) (scrape_samples_scraped)
```

## Set limits per scrape

sample_limit and label limits in scrape configs stop a misbehaving target from flooding Prometheus.

**Quiz:** Which label is most dangerous for cardinality?

- [ ] region
- [ ] status_code
- [ ] http_method
- [x] user_id

*Answer:* user_id. Unbounded values create unbounded series.