Because metrics are meant to aggregate behaviour across populations, while those identifiers describe single events or single actors. A request ID or user ID can create a new time series for every request or user, which turns a useful metric into an unbounded cost driver. They belong in forensic data stores, not in metric labels.
Why This Matters for Security Teams
Prometheus metrics are designed to support aggregation, alerting, and trend analysis. When request IDs or user IDs are added as labels, the data stops representing system behaviour and starts representing individual events. That creates high-cardinality time series, which can inflate memory use, slow queries, and make dashboards harder to trust. The security impact is not just operational cost. It also weakens observability during incident response because noisy metrics can hide genuine anomalies.
This issue often appears when teams try to make metrics “more useful” by attaching everything they know about a request. The better pattern is to keep metrics coarse and move per-request or per-user detail into logs or traces, where the data model is built for that level of uniqueness. Guidance from the NIST Cybersecurity Framework 2.0 supports disciplined telemetry management as part of broader resilience and detection capability.
In practice, many security teams encounter this problem only after a burst of traffic or a production incident has already caused cardinality to explode.
How It Works in Practice
Prometheus stores each unique label combination as a separate time series. That design is powerful when labels describe stable dimensions such as service name, endpoint, region, or status code. It breaks down when labels contain identifiers that vary per request or per person. A request ID changes every call, and a user ID can grow without bound in large systems, so both create continuous series churn.
Teams usually discover the impact in one of three ways: scrape latency increases, memory pressure rises on the Prometheus server, or queries become too expensive to run routinely. The fix is architectural, not cosmetic. Metrics should answer questions like “How many errors are happening?” or “Which service is under stress?” Per-entity questions should be handled elsewhere.
- Use labels for low-cardinality dimensions only.
- Keep request IDs in logs and distributed traces, not metric labels.
- Aggregate user behaviour into bounded categories such as plan type, region, or role, if that dimension is genuinely needed.
- Review metric schemas before deployment so new labels are assessed for cardinality risk.
For telemetry strategy, the Prometheus naming and labeling guidance is useful because it reinforces the principle that metric labels should stay controlled and predictable. For security operations, that discipline helps preserve detection quality and avoids turning observability into a storage and performance problem. These controls tend to break down in multi-tenant SaaS platforms with per-customer personalization because teams conflate business identity with metric dimensions.
Common Variations and Edge Cases
Tighter label discipline often improves reliability, but it can reduce convenience for developers who want fast filtering by request or user. That tradeoff is real: the more you expose high-precision identifiers in metrics, the easier it becomes to debug one event, but the harder it becomes to operate the monitoring stack at scale.
There is no universal standard for every telemetry design, so current guidance suggests using identifiers sparingly and only when the number of possible values is tightly bounded. In regulated or privacy-sensitive environments, user IDs also raise data minimisation concerns because metric pipelines may be retained longer than application logs are intended to be. That is one reason many organisations keep identity-linked evidence in log management or SIEM platforms and reserve metrics for service health.
Where identity and access patterns matter, a safer option is to aggregate into stable categories such as authenticated versus unauthenticated, internal versus external, or role tier, rather than raw identity values. For broader control mapping, the NIST Cybersecurity Framework 2.0 can help teams connect telemetry design to detection and governance outcomes, while security analytics benefit from keeping high-cardinality data in systems built for investigation. Current guidance suggests that raw identifiers should stay out of metrics unless there is a narrowly defined, short-lived operational need.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATLAS and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | DE.CM-01 | Telemetry must support monitoring without degrading detection quality. |
| MITRE ATLAS | AML.T0011 | Attackers can abuse high-cardinality telemetry to conceal malicious activity. |
| NIST AI RMF | MAP | Data quality and pipeline integrity matter when telemetry informs AI-driven ops. |
| OWASP Agentic AI Top 10 | LLM02 | Agentic systems can emit excessive identifiers into tool and metrics pipelines. |
Limit attacker-controlled identifiers in observability paths to preserve signal quality.
