The number of unique combinations created by metric or log attributes. High-cardinality fields, such as user IDs or request IDs, can multiply storage cost and make observability data harder to manage without improving investigative value.
What Telemetry Cardinality Means in Observability
telemetry cardinality describes how many unique value combinations appear in metrics or log fields. It is a data-shape property, not a security control, but it directly affects how usable, expensive, and noisy observability data becomes.
Low-cardinality telemetry is easier to aggregate and trend because the same label sets repeat often. High-cardinality telemetry creates many distinct series or log variants, which can make dashboards slow, storage expensive, and searches harder to interpret.
This is why cardinality is usually discussed alongside metric design and log schema design. A field such as service name often stays manageable, while fields such as user ID, request ID, or session token can explode the number of unique combinations when attached to every event.
Why Cardinality Matters Operationally
Cardinality changes the operational shape of observability systems. When unique combinations rise sharply, back-end indexing, retention, query latency, and alert quality can all degrade even if the underlying application is healthy.
The practical trade-off is visibility versus cost. Rich, highly specific attributes can help with debugging a single trace or request, but they are often a poor choice for long-lived metrics because they multiply the number of distinct time series without improving most trends.
Good telemetry design therefore distinguishes between attributes that are valuable for troubleshooting and attributes that are safe to aggregate over time. That distinction is central to keeping observability useful at scale.
Common Sources of High Cardinality
High cardinality often comes from values that are naturally unique per event or per actor. Request identifiers, transaction IDs, user identifiers, device identifiers, full URLs with query strings, and unbounded error messages are typical examples.
Another common cause is allowing too many dimensions onto the same metric or log event. Even if each field looks harmless alone, the combination can create a much larger set of unique series than intended.
Cardinality can also rise accidentally when teams copy diagnostic fields into production metrics. A label that helps during incident response may become costly and noisy once it is emitted at very high volume.
How to Interpret Telemetry Cardinality in Practice
Cardinality is not inherently bad. It is a signal that helps engineers decide whether a data field belongs in a metric, a log, a trace, or only in short-lived diagnostic output. The question is whether the unique values improve common analysis enough to justify the operational cost.
Observability teams usually treat stable attributes as good metric labels and volatile attributes as better candidates for logs or traces. That keeps trend data compact while preserving the ability to drill into individual events when needed.
For reliable analysis, the goal is not to eliminate uniqueness altogether, but to place it where it adds value without overwhelming the storage and query layer.
Risk and Threat Considerations
High-cardinality telemetry can become a resilience and cost problem when it is generated at scale, because expensive series growth and noisy logs can consume storage, indexing, and query capacity faster than teams expect. It also increases the chance that important signals are buried in low-value uniqueness.
Failure mechanism: A field that seems useful for debugging, such as an ID, token-derived label, or full request path, gets attached to high-volume telemetry and creates an explosion in distinct series or log keys. The observability platform then pays the penalty in aggregation, retention, and search performance.
Impact: Teams may face slower incident investigation, higher platform cost, reduced alert fidelity, and weaker visibility into the signals that matter most. In extreme cases, the telemetry pipeline itself becomes harder to operate than the systems it is supposed to observe.
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, NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.PO-01 — Policies, Processes and Procedures | Telemetry cardinality affects observability policy and data-handling rules. |
| Recommendation — Set telemetry data standards that limit unbounded labels in production metrics. | ||
| NIST SP 800-53 Rev 5 | AU-6 — Audit Record Review, Analysis, and Reporting | High-cardinality logs affect how audit and monitoring data can be reviewed and analyzed. |
| SI-4 — System Monitoring | Cardinality directly shapes monitoring fidelity, storage burden, and detection usability. | |
| Recommendation — Tune log fields so audit analysis remains searchable and operationally useful. Design monitoring data to preserve actionable signals without creating excessive series growth. | ||
| ISO/IEC 27001:2022 | A.8.16 — Monitoring activities | Telemetry cardinality changes the efficiency and quality of security monitoring. |
| Recommendation — Define monitoring data practices that keep observability scalable and dependable. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | Telemetry schema choices influence log volume, retention, and reviewability. |
| Recommendation — Manage log fields to reduce unnecessary uniqueness and preserve usable audit trails. | ||
Related resources from NHI Mgmt Group
- What breaks when high-cardinality telemetry tags are not controlled?
- Why do high-cardinality labels create problems in agent-generated telemetry?
- How should teams stop high-cardinality telemetry from creating runaway Datadog cost?
- When should organisations treat runtime telemetry as a primary control?