Choose and fix metric labels on Grafana Labs

Use bounded labels

Thu, 06 Aug 2026 10:05:27 -0400

Use bounded labels

A metric label should be a dimension you aggregate or filter by, with a bounded set of values.

The single most important rule is that label values must be bounded. A label like env has a handful of values forever. A label like user_id is an unbounded label: it grows without limit, and every new value creates another active series that’s billed and indexed.

Never use these as metric label values:

User, customer, or session IDs
Request or trace IDs
IP addresses
Email addresses
Timestamps

Each of these creates a new series per unique value, and the combinations multiply against every other label on the metric.

Before you add a label

Thu, 06 Aug 2026 10:05:27 -0400

Before you add a label

For every label, ask:

Will I aggregate or filter by it? If nobody queries by this dimension, it’s pure cost.
Is the value set bounded? Think tens of values, not thousands.
How does it multiply? Check the label against the labels already on the metric. Three bounded labels can still combine into thousands of series.

Where the mistakes happen

Thu, 06 Aug 2026 10:05:27 -0400

Where the mistakes happen

Cardinality problems usually enter a stack at ingestion setup, not in application code reviews. Enabling an integration with an app or service with default settings, such as the Kubernetes Monitoring Helm chart across all your clusters, can turn on thousands of metrics and labels at once. That visibility is valuable, but only if your budget expects it. When you set up a new integration:

Review what metrics the defaults send before pushing them to production.
Use allowlists to keep only the metrics and labels you’ll use.
Check the Cardinality tab after enabling anything new, and watch for New badges.

Control labels at the source

Thu, 06 Aug 2026 10:05:27 -0400

Filter at the source

You can keep unnecessary series from ever leaving your infrastructure with relabeling rules in Prometheus, Alloy, or your collector.

Allowlisting: keep an explicit set of important metrics and labels and drop everything else. For example, for Prometheus metrics, use keep and labelkeep actions.
Denylisting: drop an explicit set of high-cardinality metrics and labels and keep everything else. For example, for Prometheus metrics, use drop and labeldrop actions.

For the full relabeling reference and examples, refer to Reduce metrics costs by filtering collected and forwarded metrics.

Enforce your strategy at a gateway

Relabeling rules only help if you control the collectors that apply them. In larger organizations, many teams send telemetry, and the team that pays the bill often can’t control every client. In that case, route telemetry through a tier of gateway collectors that your platform or admin team owns, and apply your labeling and filtering policies at that layer. Whatever upstream teams send, your rules run at the gateway before data reaches Grafana Cloud.

Fleet Management helps you run this pattern at scale by giving you centralized control over your collector configurations, so you can roll out and update gateway policies from one place instead of editing collectors one by one.

Reduce cardinality you already have

Thu, 06 Aug 2026 10:05:27 -0400

Reduce cardinality you already have

If the Cardinality tab already shows high-cardinality or unused metrics, you don’t have to reinstrument anything to fix it. Adaptive Metrics reduces cardinality from inside Grafana Cloud by aggregating away the labels nobody uses, while keeping the metric itself.

How Adaptive Metrics helps

Adaptive Metrics analyzes how your organization uses its metrics across dashboards, alerts, recording rules, and queries. It then recommends aggregating underutilized metrics into lower-cardinality versions. Applying a recommendation doesn’t delete the metric, rather it aggregates away unused label dimensions, and your existing dashboards, rules, and queries continue to work without modification. If usage changes later, you can remove the aggregation and the metric is stored at full cardinality again.

Unnecessary series are stopped before they’re persisted, without modifying your collector configuration.

To set up and manage recommendations end to end, follow the Optimize metrics with Adaptive Metrics learning path.

Review your recommendations

Thu, 06 Aug 2026 10:05:27 -0400

Interactive guide: Review your recommendations

Reduce existing metrics cardinality with Adaptive Metrics aggregation recommendations, without touching your ingestion pipeline.

Reduce your metrics cardinality

Complete this interactive guide directly in your Grafana Cloud stack with an interactive learning experience.

Open in Grafana Cloud

Remediate in the right order

The recommended order to remediate cardinality:

Address unused metrics: metrics with the Unused badge in the Cardinality tab add cost with no value.
Assess high-cardinality labels on used metrics: aggregate away the label dimensions nobody queries, and keep the ones they do.
Protect what matters: define exemptions in allowlists for metrics that must never be aggregated.

Resources

Thu, 06 Aug 2026 10:05:27 -0400

Choose and fix metric labels on Grafana Labs

Use bounded labels

Use bounded labels

Before you add a label

Before you add a label

Where the mistakes happen

Where the mistakes happen

Control labels at the source

Filter at the source

Enforce your strategy at a gateway

Reduce cardinality you already have

Reduce cardinality you already have

How Adaptive Metrics helps

Review your recommendations

Interactive guide: Review your recommendations

Reduce your metrics cardinality

Remediate in the right order

Resources

Documentation

Community