Cardinality can explode quickly, especially in cloud environments where instances are short lived and requests are highly variable. That creates many more unique series than the system was designed to hold, which increases storage pressure, makes querying harder, and turns routine monitoring into expensive operational noise.
Why This Matters for Security Teams
High-cardinality labels turn observability from a control into a liability when they are applied to metrics that should remain stable over time. Request IDs, instance IDs, pod names, and similar values can multiply series counts faster than platform teams expect, especially in autoscaling or ephemeral cloud environments. That extra volume affects cost, query latency, alert quality, and the ability to spot real change. The NIST Cybersecurity Framework 2.0 is useful here because it reinforces the broader discipline of governance, monitoring, and operational resilience, even though it is not an observability-specific standard.
The security problem is not just expense. When dashboards become noisy, teams stop trusting them, and that weakens detection, incident triage, and capacity planning. Metrics that were meant to provide a stable signal can become difficult to compare across releases, environments, or attack conditions. That matters in cloud-native systems where short-lived infrastructure is normal and where identity-heavy telemetry, such as service accounts or workload identities, can already be complex. In practice, many security teams discover metric cardinality problems only after storage bills spike or alerts go blind during an incident, rather than through intentional observability design.
How It Works in Practice
Every distinct combination of metric name and label set creates a new time series. That is normal for low-variation dimensions such as environment, region, or service name. It becomes problematic when teams attach high-entropy values that change per request or per container lifecycle. A label like request_id can create one unique series per transaction, which defeats aggregation and overwhelms back-end storage and indexing. Similar issues appear with instance IDs in autoscaled fleets, where the number of active series keeps shifting as nodes churn.
Operationally, the impact shows up in a few ways:
- queries slow down because the system must scan far more series than intended
- alerts become harder to interpret because each event may look unique instead of comparable
- retention costs rise because the platform stores many low-value or one-off series
- dashboards lose trend value because the data no longer groups into meaningful buckets
Good practice is to keep metric labels bounded and reusable, then push per-request detail into logs or traces where that granularity belongs. Use metrics to answer state questions such as error rate, latency, saturation, and availability. Use traces or logs for event-level context. Teams also benefit from explicit label governance, including allowlists for approved dimensions and reviews for exporters, libraries, and service templates that may introduce uncontrolled labels. Guidance from the NIST Cybersecurity Framework 2.0 aligns with that control mindset because the aim is to preserve observability as a reliable operational signal.
These controls tend to break down when platform teams allow application developers to emit arbitrary labels in multi-tenant, autoscaled environments because the growth rate outpaces review and enforcement.
Common Variations and Edge Cases
Tighter label controls often increase developer friction, requiring organisations to balance observability richness against system stability and cost. There is also a real tradeoff between debuggability and metric hygiene: some teams want every request tagged so they can search quickly, but that is usually the wrong place for that level of detail. Current guidance suggests keeping metrics intentionally coarse and moving deep identifiers into traces, logs, or sampled debug telemetry.
Edge cases appear when a seemingly dynamic field is actually bounded and useful, such as a small set of deployment zones, customer tiers, or critical service classes. Those labels can be acceptable if the value set is stable and known in advance. By contrast, labels derived from user input, timestamps, UUIDs, container IDs, or ephemeral infrastructure names are usually poor candidates. In regulated or high-assurance environments, teams should also consider whether label content could expose sensitive operational detail, especially when telemetry is shared across tools or vendors.
The practical rule is simple: if the value is not useful for aggregation across many events, it probably does not belong in a metric label. For teams managing large cloud estates, that boundary should be documented in platform standards and enforced in code review, instrumentation libraries, or telemetry pipelines.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 provides the primary governance reference for this topic.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OV-01 | Telemetry governance is needed to stop unbounded metric growth. |
Define observability standards that approve bounded labels and reject high-cardinality telemetry at design time.
Related resources from NHI Mgmt Group
- How do security teams decide whether to keep Cognito-like tools in scope?
- Why do request IDs and user IDs create problems in Prometheus metrics?
- How should security teams keep pull request reviews effective when changes touch multiple parts of a codebase?
- How should security teams keep static analysis fast enough to run in pull request workflows?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 1, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
