master · Module 3.4
Cardinality & Cost Control
Learning Objectives
- Compute active series growth as a product of services, base metrics, and dynamic tag values.
- Estimate RAM and monthly bill from active series count.
- Use metric_relabel_configs to drop high-cardinality labels at scrape time.
Key Concepts
Cardinality is multiplicative
Active series roughly equals services x base metrics x product of dynamic tag value counts. Adding one unbounded tag (device_ip) multiplies, not adds — this is why cardinality explodes so fast.
Series -> RAM -> bill
Each active series consumes memory in the TSDB head and drives storage/ingest cost. The Cardinality sandbox makes activeSeries, ramBytes, and monthlyBillUsd move together and monotonically with inputs.
Dropping labels at scrape
metric_relabel_configs with an action: labeldrop or a drop rule removes offending labels before ingestion, collapsing millions of series back to a handful.
Warning
A single rogue label like user_uuid on a hot metric can 100x your bill overnight. Guard new labels in review.
Insight
The cheapest series is the one you never create. Prefer exemplars/traces for per-request detail instead of high-cardinality metric labels.
Knowledge Check
1. Why does adding one unbounded label (e.g., device_ip) explode active series?
2. How do active series, RAM, and monthly bill relate as inputs grow?
3. What is the right tool to remove a high-cardinality label before ingestion?