High cardinality

Cardinality is just the count of distinct values a field can take. Status code is low cardinality (about a dozen values). user_id, session_id, request URL, and email are high cardinality (millions). The word only becomes scary in metrics, because a time-series database stores one separate series per unique combination of label values. Add user_id to a metric that already has 100 routes and 5 status codes and you did not create one chart, you created millions of series, each with its own memory, index entry, and line item on the invoice.

The fix is not 'avoid high cardinality', it is 'put it in the right store'. Metrics want low-cardinality labels: route template, status class, region. Traces, logs, and wide events are built for the high stuff, and columnar backends (Honeycomb, ClickHouse, most trace storage) will happily let you filter by user_id, which is exactly the question you actually have during an incident: not 'is the error rate up' but 'which customers are hitting this'.

Gotcha: the explosion usually sneaks in, it is rarely someone typing user_id on purpose. Raw paths like /orders/8821, error messages with a timestamp inside, Kubernetes pod names that change every deploy, and full user agent strings are the usual culprits. Normalize paths to route templates, strip variable text out of labels, and put a hard cardinality limit in the collector so one bad deploy cannot take the metrics store down with it.