Prometheus Label Strategy

Prometheus Label Strategy Evaluator

You are an expert in Prometheus label strategy. When asked to evaluate, audit, design, or improve a Prometheus label schema — or when a user asks how to prevent high cardinality at the source — use this guide to provide structured, actionable advice.

This skill is about preventing bad labels at the source — in application instrumentation and in scrape target labels — so they never enter storage. It is not about stripping labels off metrics after they've been emitted: removing a label that makes a series unique at scrape time silently breaks the data (see The One Rule below). For reducing the cost of series that already exist in Grafana Cloud, route the user to the adaptive-metrics skill. For diagnosing an active cardinality fire, route to prometheus-cardinality-troubleshooter.

The One Rule: Never Drop a Label That Makes a Series Unique

You cannot remove, at scrape time, any label that makes a series unique. Not pod, not instance, not anything that distinguishes one real series from another. This includes metric_relabel_configs with action: labeldrop and the equivalent prometheus.relabel rules in Alloy.

It looks like a cardinality win. It is not — it breaks the data, silently and permanently:

• Counter resets get mixed together. When two pods' counters collapse into one series, their independent restarts interleave on the merged series. rate() and increase() then return garbage — often absurdly high values, because every pod restart looks like a counter reset.
• DPM inflates instead of dropping. Multiple samples now land on the same series in the same scrape — duplicate samples, out-of-order errors, inflated samples-per-minute. People come back weeks later asking "why is my DPM so high?" or "why is rate() returning absurd numbers?" — and there is no evidence left in the data of where it broke.
• The aggregation is wrong, not just coarse. A sum over a label you dropped silently double-counts or under-counts depending on how the collapse happened.

The trap is that none of this errors at config time. The pipeline keeps running; the numbers are just quietly wrong, and the breakage point is invisible after the fact.

The right tools, in order:

1. Don't emit the bad label in the first place — fix the application code. This is the only place a label can be removed without consequence, because the series was never unique on it to begin with.
2. For series already flowing into Grafana Cloud that you can't fix at the source → Adaptive Metrics. This is exactly what it is for: it aggregates series correctly — counter-reset-aware, with a recorded audit trail, and reversible — instead of blindly stripping labels. Route the user to the adaptive-metrics skill.

metric_relabel_configs has a couple of narrow, safe uses (dropping an entire unwanted metric; removing a label that exactly duplicates a target label) — covered in Source-Side Prevention — but reducing cardinality by dropping a distinguishing label is never one of them.

Core Concepts

Series are the fundamental unit in Prometheus. Each unique combination of metric name plus label key-value pairs creates a new active series. Too many series = memory pressure, slow queries, ingest pressure, high bill.

Cardinality = the number of unique values a label can have. Total series for a metric ≈ the product of cardinalities across its labels. A metric with path (100 values), status_code (10 values), method (5 values), and instance (50 values) = 250,000 series per metric. Adding one more high-cardinality label often 10–100×s the count.

The dual impact rule: High-cardinality labels hurt on both paths:

• Ingestion path: More active series → larger head block, larger WAL, more memory, larger remote_write payloads, higher Grafana Cloud bill (Active Series + DPM)
• Query path: PromQL operators (sum by, rate, joins) must materialize matching series in memory. High cardinality balloons query memory and latency

Series churn is the silent killer. If a label value changes frequently (deploy version, pod name, ephemeral IDs), every change creates a new series while the old one continues to age out. Daily churn of 100% means you carry roughly 2× the steady-state series count for retention purposes.

The key question for any proposed label: "Will queries that use this metric reliably specify or aggregate on this label?" If no → it should NOT be a label.

Label Evaluation Framework

When auditing a label set, assess each label against these criteria.

Cardinality Scoring

Access Pattern Alignment

For each label, ask:

• Do queries on this metric reliably aggregate by or filter on this label?
• Does this label logically segment the metric the way users think about it?
• Would removing this label force users to use exemplars, logs, or traces instead — and would that be acceptable for the rare lookup case?

Static vs. Dynamic Label Values

• Static / target labels (set once per scrape target via relabel_configs, e.g., env=prod, cluster=us-east, team=payments) add cardinality proportional to targets, not requests. Cheap and high-value. Use freely.
• Dynamic / sample labels (emitted by the application per measurement, e.g., status_code, method, cache_hit) multiply cardinality by value count. Keep possible values in the single digits or low tens. The application code is the source of truth — fix it there, not in Prometheus.

Consistency Check

• Label names consistent across services? (status vs status_code vs http_status produces three separate label families — joins break)
• Label values normalized? (200 vs "200", GET vs get, Error vs error)
• Naming convention consistent? Prometheus convention is snake_case for both metric and label names
• Same concept, same name across services? (service vs svc vs app_name)

Histogram Bucket Discipline (critical, often missed)

Every histogram metric multiplies its base cardinality by (bucket count + 3) — buckets via _bucket{le="..."} plus _sum, _count, and _created (Prometheus 2.39+).

• Default prometheus.DefBuckets has 11 buckets → 14× multiplier
• A histogram with method, path, status already at 1,000 series becomes 14,000 series after adding histogram cardinality
• Always trim histogram label cardinality first — labels matter 14× more on histograms than on counters/gauges
• Consider native histograms (Prometheus 2.40+) which use a single sparse series instead of one-per-bucket — major cardinality reduction for high-resolution latency tracking

Info-Metric Pattern (for high-churn metadata)

When you want to know about a label (e.g., version, git_sha, image_tag) without paying for it on every metric, use an info metric:

# A single low-cardinality counter/gauge of value 1, with the metadata attached
app_build_info{app="payment-api", version="2.4.1", git_sha="a1b2c3"} 1

Then join at query time. The classic approach is a vector match with group_left:

sum by (version) (
  rate(http_requests_total{app="payment-api"}[5m])
  * on (app) group_left (version) app_build_info
)

The version label lives on exactly one series per build, not on every metric.

The info() function (simpler join)

PromQL's info() function (experimental, Prometheus 3.0+; enable with --enable-feature=promql-experimental-functions) automates the info-metric join so you don't have to hand-write the * on (...) group_left (...) match:

info(
  rate(http_requests_total{app="payment-api"}[5m]),
  {version=~".+"}
)

info(v, [labelselector]) takes a range/instant vector v and, for each series, finds matching info metrics and adds their labels. The optional second argument is a label-matcher restricting which info labels are attached (here, only version). By default info() joins against the conventional target_info metric and matches on identifying labels (e.g. instance, job), so it's especially ergonomic for OpenTelemetry-style target_info. For custom info metrics like app_build_info the explicit group_left form above is still the most portable.

Prefer info() when you're on Prometheus 3.x and joining against target_info; fall back to the explicit group_left match for older versions, custom info metrics, or when the experimental feature flag isn't enabled.

Evaluation Output Format

When auditing a label set, produce a report in this structure:

## Prometheus Label Strategy Audit

### Summary
[1-2 sentence overall assessment — total estimated active series, biggest risks]

### Per-Label Analysis
| Metric Family | Label | Cardinality | Used in Queries? | Verdict | Action |
|---|---|---|---|---|---|
| http_requests_total | path | Unbounded (raw URLs) | Sometimes | ❌ Remove | Template in code: `/users/:id` not `/users/12345` |
| http_requests_total | pod | High + churn | Rarely | ⚠️ Keep — makes the series unique | If too expensive, aggregate away with Adaptive Metrics; query by `workload` for the common case |

### Histogram-Specific Findings
[Highlight any histograms with high label cardinality — these are 14×+ amplified]

### Estimated Impact
- Active series reduction: [X series → Y series]
- DPM reduction: [X DPM → Y DPM]  (samples-per-minute = series × ~6 at 10s scrape)
- Memory impact: [if measurable]

### Recommended Label Set
[Final recommended labels per metric family]

### Implementation Plan
1. [Code changes — instrumentation hygiene: stop emitting bad labels at the source]
2. [Scrape target labels — relabel_configs (additive: env, cluster, team, workload)]
3. [Post-ingest cost reduction on series you can't fix at the source — Adaptive Metrics]
4. [Recording rules to materialize useful aggregates]

Recommended Common Target Labels

These should be set as target labels (via relabel_configs on the scrape job, NOT emitted by the app) — they're per-target, low cardinality, high query value:

These should NOT be re-emitted by the application. If the app emits a cluster label, it duplicates the target label and creates collisions / honor_labels decisions you don't want to make.

Kubernetes Patterns

Recommended Labels (from kubernetes_sd_configs)

Handling the pod Label

pod is high-cardinality and transient — it rolls on every deploy and restart, so it dominates churn and series count. But it is also a label that makes K8s series unique, and Kubernetes monitoring (per-pod resource attribution, kube-state-metrics joins) depends on it. The One Rule applies: do not drop pod at scrape time. Collapsing pods into one series mixes their counter resets and breaks rate().

Instead:

• Add workload ({controller_kind}/{controller_name}) as a target label via relabel_configs, so dashboards and alerts can aggregate on the stable workload identity (sum by (workload)) without touching pod. This is additive — it removes nothing.
• Don't emit pod from application code — let it come from Kubernetes service discovery, so there is exactly one source of truth (see below).
• If pod-level series are genuinely too expensive in Grafana Cloud, reduce them with Adaptive Metrics, which aggregates pod away correctly (post-ingest, counter-reset-aware, reversible) rather than corrupting the raw data at scrape. Route to the adaptive-metrics skill.

Don't Map Ephemeral Fields into Labels in the First Place

uid regenerates on every pod recreation and has no legitimate query use. The fix is to never map it into a label — leave it out of your relabel_configs. (It isn't in default kubernetes_sd_configs output unless you explicitly target it.) Don't try to labeldrop it after the fact — by then it's already distinguishing series, and removing it breaks the data exactly like dropping any other unique label.

One Source of Truth for Target Identity

instance, pod, node, and host should come from scrape target labels, not from application code. If the app also emits its own instance/node, you get duplicates and honor_labels collisions. The fix is in the application — stop emitting them — not a scrape-time labeldrop. (Removing a label that exactly duplicates a target label is the one narrow exception; see metric_relabel_configs.)