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

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(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:

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.)

kube-state-metrics label propagation ⚠️

• kube_pod_labels{label_app_kubernetes_io_*=...} can carry dozens of metadata labels
• Each unique pod label combination is a new series
• Restrict at the source with kube-state-metrics' --metric-labels-allowlist — this controls what is ever emitted, so it's prevention, not destructive after-the-fact dropping

Source-Side Prevention: Where to Fix What

There are five levers, in order of preference:

1. Fix in the Application (best)

Bad labels emitted by the app are the root cause. Examples:

• HTTP paths: use templated routes (/users/:id) not raw paths
• Error metrics: use a small enum (error_type="timeout") not the error message string
• User-scoped metrics: don't include user_id — use exemplars to point to logs/traces
• Free-form input: never emit user-supplied strings as label values

If you control the code, this is always the right fix. It saves cost on every downstream system (Prometheus, remote_write, Mimir, Grafana Cloud).

2. relabel_configs (target-time relabeling)

Runs before the scrape. Used to:

• Set target labels (env, cluster, team) on discovered targets
• Drop entire targets you don't want to scrape
• Rewrite instance to a friendly value
• Add identity from service discovery metadata

3. Adaptive Metrics (Grafana Cloud — post-ingest, the safe way to reduce cardinality)

When the cardinality is structural and you can't fix it at the source — the label legitimately exists and makes series unique, you just don't need every value at full resolution — Adaptive Metrics is the correct tool, and the only safe way to reduce the cost of series that already exist.

It works after ingest, as aggregation rules applied in Grafana Cloud. Crucially, it aggregates series correctly:

• It handles counter resets properly, so rate() and increase() stay accurate.
• It records what was aggregated, so there's an audit trail — you can answer "why did this change?" later.
• It's reversible: drop a rule and the full-resolution series come back.

This is the difference between "the data is now cheaper" (Adaptive Metrics) and "the data is now wrong" (labeldrop at scrape). Route the user to the adaptive-metrics skill for rule design.

4. metric_relabel_configs (narrow, safe uses only)

Runs after the scrape, before storage.

⚠️ Do not use metric_relabel_configs (or Alloy prometheus.relabel) to drop a label that distinguishes series — pod, instance, user_id, path, anything. See The One Rule. It looks like a cardinality fix and silently breaks rate(), inflates DPM, and corrupts aggregations. Use the application code (lever 1) or Adaptive Metrics (lever 3) instead. The same caution applies to normalizing a label value (e.g. collapsing status_code to 2xx) at scrape — it merges distinct series and produces duplicate-sample errors; do that in code or via Adaptive Metrics, never here.

The genuinely safe uses are:

• Drop an entire metric you never want stored — you're discarding the whole metric, not collapsing distinct series into one:

  metric_relabel_configs:
    - source_labels: [__name__]
      regex: my_app_request_details
      action: drop
• Remove a label that exactly duplicates a target label. If the app emits its own cluster/instance that already comes from the scrape target, the target label still provides uniqueness, so removing the duplicate breaks nothing. Prefer fixing the app, but this is a safe stopgap.

That's the whole list. If you're reaching for metric_relabel_configs to bring down a series count, you almost certainly want Adaptive Metrics instead.

5. Recording Rules (query-time cardinality reduction)

Pre-aggregate expensive series into a lower-cardinality recorded series. Stored at the same data point density but with far fewer series.

groups:
  - name: http-requests-aggregates
    interval: 30s
    rules:
      # Drop pod/instance dimension; keep only service-level rollup
      - record: service:http_requests:rate5m
        expr: sum by (service, env, cluster, status_code) (rate(http_requests_total[5m]))

Queries that target the rollup are dramatically cheaper. The raw series still exist — recording rules don't reduce ingest cost (use Adaptive Metrics for that — not a scrape-time labeldrop). They reduce query cost.

Instrumentation Hygiene (for app developers)

If the user is writing instrumentation code, these are the rules:

Exemplars (the escape hatch)

Exemplars attach a trace_id (or any key-value pair) to specific samples without making it a label dimension. The ideal home for high-cardinality correlation data.

Requires OpenMetrics format, Prometheus 2.26+, scrape config:

scrape_configs:
  - job_name: my-app
    enable_protobuf_negotiation: true
    # Or for text-format:
    follow_redirects: true

And on the Prometheus server:

storage:
  exemplars:
    max_exemplars: 100000

Use exemplars for:

• trace_id correlation (Tempo, Jaeger)
• request_id for specific debug lookups
• Any sparse "useful when you need it" key

Query exemplars via Grafana's exemplars-on-graph feature, not via PromQL aggregation.

The 80/20 Rule

The most impactful improvements almost always come from these five changes:

1. Drop unbounded labels at the app layer — path (untemplated), user_id, error_message. Single biggest win.
2. Trim histogram label cardinality before anything else — 14× amplification on every histogram.
3. Don't emit pod/instance/node from application code — let them come from scrape targets, and add a stable workload target label to aggregate on. (Never drop the real pod at scrape to cut cardinality — if pod-level series are too expensive, use Adaptive Metrics.)
4. Use info metrics for version / git_sha / image_tag — eliminates deploy-driven churn.
5. Set target labels via relabel_configs, not app code — env, cluster, team, service should never be emitted by the application.

Focus on these before anything else.

Labels to Avoid — Quick Reference

When to Route Elsewhere

• "Reduce my Grafana Cloud bill" / "reduce cardinality on series already ingested" → engage adaptive-metrics skill (post-ingest aggregation rules — the safe, counter-reset-aware way; never labeldrop distinguishing labels at scrape)
• "Which metrics are driving my DPM?" → engage dpm-finder skill
• "My Prometheus is OOMing / scraping is failing right now" → engage prometheus-cardinality-troubleshooter skill
• "How do I write the query to find the bad metric?" → engage promql skill
• "How do I configure relabel rules in Alloy?" → engage alloy skill

This skill's lane is strategy and design. Other skills own diagnosis and operational remediation.