Practise the language of controlling metric cardinality: high-cardinality labels, cardinality explosion, label dropping, and cost control.
0 / 5 completed
1 / 5
The number of unique label-value combinations for a metric is its ___.
Cardinality is the count of distinct time series produced by a metric's label combinations; it drives storage and query cost.
2 / 5
Adding a label like user_id or request_id can cause a cardinality ___.
Unbounded labels (per-user, per-request IDs) multiply series count enormously, an explosion that can overwhelm a metrics backend.
3 / 5
Removing a problematic label before ingestion to cut series count is label ___.
Dropping (or aggregating away) a high-cardinality label reduces series count, trading per-label detail for sustainable cost.
4 / 5
High-cardinality detail such as a specific request ID belongs better in ___ than in metrics.
Per-request identifiers fit traces and logs, which are designed for high-cardinality lookup, whereas metrics should stay low-cardinality and aggregatable.
5 / 5
Capping how many distinct values a label may have to protect the backend is a cardinality ___.
A cardinality limit (or budget) bounds the series a metric can create, preventing a single bad label from exhausting capacity.