High cardinality describes metric labels or fields that generate a very large number of unique values. It is not inherently wrong, but it becomes a problem when dynamic identifiers, user specific paths, or instance IDs create excessive time series and drive cost and performance issues.
Expanded Definition
High cardinality describes fields or labels that produce many distinct values, especially in observability, logging, and telemetry pipelines. In practice, the issue is not the presence of unique values by itself, but the scale at which those values explode the number of time series, index entries, or query paths. A metric labeled with request IDs, user IDs, full URLs, or instance names can look useful at first, yet it often creates noisy data that is expensive to store and difficult to aggregate. The concept is most relevant when teams rely on labels for filtering and dashboards, because cardinality directly affects query speed, retention cost, and the stability of monitoring systems. Guidance varies across vendors on where acceptable limits sit, so there is no single threshold that fits every platform. For governance, the NIST Cybersecurity Framework 2.0 is useful as a higher-level reference for managing visibility and operational resilience, even though it does not define cardinality itself. The most common misapplication is treating every unique identifier as a harmless label, which occurs when engineering teams prioritize debugging convenience over telemetry scale and retention impact.
Examples and Use Cases
Implementing telemetry rigorously often introduces a tradeoff between diagnostic precision and system cost, requiring organisations to weigh short-term troubleshooting convenience against long-term observability stability.
- Application metrics that label every request by full URL path can fragment dashboards and create thousands of distinct time series, especially when path parameters are not normalised.
- Infrastructure monitoring that includes per-container or per-pod IDs may help trace short-lived workloads, but it can overwhelm storage if the platform retains those labels for too long.
- Security logging that records user-specific or session-specific fields can improve investigations, yet it may also raise indexing costs and make broad trend analysis harder.
- Distributed tracing systems sometimes capture dynamic service identifiers or tenant IDs, which is valuable for debugging multi-tenant environments but can become operationally expensive at scale.
- Schema design in data pipelines may need field bucketing or controlled dimensionality to keep queries performant while still preserving enough detail for detection and response.
For teams building practical telemetry policies, the NIST Cybersecurity Framework 2.0 can help frame the broader need for reliable monitoring and resilient operations.
Why It Matters for Security Teams
High cardinality matters because observability is only useful when the platform remains fast, affordable, and searchable under real operational load. Security teams depend on logs, metrics, and traces to detect anomalies, investigate incidents, and support auditability, but excessive label diversity can cause dropped data, slow queries, and budget pressure that quietly reduces coverage. That creates blind spots at exactly the moment defenders need dependable telemetry. The issue also intersects with identity and access governance when security tools store user, device, or workload identifiers as labels without restraint. In those cases, the data model can unintentionally turn identity detail into an operational burden, especially in multi-tenant or ephemeral environments. The right response is usually not to eliminate detail altogether, but to standardise dimensions, normalise dynamic fields, and reserve high-cardinality data for targeted investigation paths rather than default dashboards. Organisations typically encounter the impact only after storage bills spike, queries stall, or critical alerts stop appearing, at which point high cardinality becomes operationally unavoidable to address.
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 term.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | DE.CM-1 | Continuous monitoring depends on telemetry that remains usable at scale. |
Keep metrics and logs queryable so monitoring stays effective under production load.
Related resources from NHI Mgmt Group
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
