Metric Cardinality and Labeling Best Practices
Learn how labels create cardinality, why high cardinality breaks metric systems, and how to design label schemes that stay fast and affordable.
Metric Cardinality and Labeling Best Practices is a free System Observability: Logging, Metrics & Tracing (ELK + OpenTelemetry) lesson on CoddyKit — lesson 4 of 4. You can read the complete lesson below for free — then practise it hands-on in the browser with a built-in code editor and a 24/7 AI tutor. It is part of the System Observability: Logging, Metrics & Tracing (ELK + OpenTelemetry) learning path, one of 4 lessons in the course, and your progress syncs across the web and the CoddyKit app.
What Is Cardinality?
Cardinality is the number of unique time series produced by a metric. Each distinct combination of a metric name and its label values is a separate series.
http_requests_total{method="GET"}is one series- Adding
status="200"multiplies the count
Labels Multiply
Cardinality grows by the product of the number of values per label. Three methods times five status codes times ten endpoints equals 150 series for one metric.
method: 3 values
status: 5 values
endpoint: 10 values
=> 3 * 5 * 10 = 150 seriesWhy High Cardinality Hurts
Each series consumes memory, disk, and index space. Unbounded labels can explode a single metric into millions of series, slowing queries and crashing collectors.
- Memory pressure on the TSDB
- Slow dashboards and alerts
- Higher storage cost
The Classic Anti-Pattern
Putting unbounded values like user IDs, request IDs, or full URLs into labels is the most common mistake. These create one series per unique value.
http_requests_total{user_id="48213"}
http_requests_total{request_id="a9f...c1"}Bounded vs Unbounded Labels
Good labels have a small, finite set of values.
- Bounded:
method,status_class,region - Unbounded:
user_id,session_id,email
Keep unbounded data in logs or traces, not metric labels.
Normalize Before Labeling
Reduce cardinality by bucketing values. Replace exact status codes with classes and template dynamic path segments.
status=503 -> status_class="5xx"
/users/48213 -> route="/users/:id"Estimating Series Count
Before adding a label, estimate its impact. Multiply the existing series count by the number of new label values.
existing = 200 series
new label region: 4 values
=> 200 * 4 = 800 seriesAggregation Removes Detail
When you query, aggregations like sum by (status_class) collapse series. Design labels so the dimensions you aggregate by are exactly the ones you need.
sum by (status_class) (rate(http_requests_total[5m]))Limits and Guardrails
Most TSDBs let you cap cardinality.
- Prometheus:
sample_limitper scrape - OpenTelemetry: cardinality limit on aggregations
- Alert when series counts spike
Dropping Bad Labels
If a noisy label slips in, drop or relabel it at ingestion rather than storing it.
metric_relabel_configs:
- source_labels: [user_id]
action: labeldropA Healthy Label Set
Aim for a handful of bounded labels per metric. This example stays well under a few hundred series.
orders_total{region="eu", status_class="2xx", channel="web"}Quick Check
Identify the riskiest label choice.
Recap
You learned that cardinality is the count of unique series, that labels multiply it, and that unbounded values like IDs must stay out of labels. Bucket and template values, estimate impact before adding labels, and enforce guardrails to keep metrics fast and cheap.
Frequently asked questions
Is the “Metric Cardinality and Labeling Best Practices” lesson free?
Yes — the full text of “Metric Cardinality and Labeling Best Practices” is free to read here on the web, and the System Observability: Logging, Metrics & Tracing (ELK + OpenTelemetry) course includes 4 lessons in total. To practise it interactively (a built-in code editor and a 24/7 AI tutor) and unlock the rest of the System Observability: Logging, Metrics & Tracing (ELK + OpenTelemetry) course, upgrade to CoddyKit PRO.
What will I learn in “Metric Cardinality and Labeling Best Practices”?
Learn how labels create cardinality, why high cardinality breaks metric systems, and how to design label schemes that stay fast and affordable. You practise System Observability: Logging, Metrics & Tracing (ELK + OpenTelemetry) with hands-on code you run directly in the browser, and a 24/7 AI tutor answers your questions as you work through the lesson.
Do I need any experience to start System Observability: Logging, Metrics & Tracing (ELK + OpenTelemetry)?
No prior experience is required. System Observability: Logging, Metrics & Tracing (ELK + OpenTelemetry) on CoddyKit is structured for beginners through advanced learners; this is — lesson 4 of 4, so you can start here or from the beginning and move at your own pace.
How long does the “Metric Cardinality and Labeling Best Practices” lesson take?
Most CoddyKit lessons take about 5–10 minutes. Each one is bite-sized and interactive, so you make steady progress and pick up exactly where you left off across the web and the app.
Can I write and run code in this System Observability: Logging, Metrics & Tracing (ELK + OpenTelemetry) lesson?
Yes. Every System Observability: Logging, Metrics & Tracing (ELK + OpenTelemetry) lesson includes a built-in code editor, so you write and run real code right in your browser and get instant AI feedback — no local setup required.
All lessons in this course
- Types of Metrics Explained
- Metric Collection Strategies
- Metric Visualization and Alerting
- Metric Cardinality and Labeling Best Practices