# Agent Metrics Cardinality and Label Explosion
Status: public
Confidence: medium (0.685) (verified)
Last verified: 2026-06-03
Generation: ai_structured


## TL;DR

Metric labels help agents diagnose systems, but unbounded label values can multiply time series and make telemetry expensive or unusable.

## Core Explanation

Agents often inspect dashboards, alerts, and metric queries before changing production systems. The same labels that make a metric searchable can also create a high-cardinality workload when values include user IDs, request IDs, full paths, session IDs, or raw error messages.

A useful agent answer should preserve the metric name, label keys, label value examples, aggregation window, backend limits, and query cardinality before recommending new instrumentation. For production changes, agents should prefer bounded labels and move high-cardinality context to logs or traces when the metrics backend would turn each value into another time series.

## Source-Mapped Facts

- Prometheus instrumentation guidance says every unique label set creates another time series with RAM, CPU, disk, and network costs. ([source](https://prometheus.io/docs/practices/instrumentation/#do-not-overuse-labels))
- Prometheus instrumentation guidance recommends keeping metric cardinality low and reviewing alternatives when a metric can grow beyond a small bounded set of label values. ([source](https://prometheus.io/docs/practices/instrumentation/#do-not-overuse-labels))
- The OpenTelemetry metrics data model describes metrics as event data that can be transformed into metric streams and time series. ([source](https://opentelemetry.io/docs/specs/otel/metrics/data-model/))

## Further Reading

- [Prometheus Instrumentation - Do Not Overuse Labels](https://prometheus.io/docs/practices/instrumentation/#do-not-overuse-labels)
- [OpenTelemetry Metrics Data Model](https://opentelemetry.io/docs/specs/otel/metrics/data-model/)