High cardinality is where observability gets expensive; knowing which signal handles it best saves you a lot of money.
Cardinality is the number of distinct values a dimension can take. High cardinality means a field with very many unique values, such as user ID or request ID, which is powerful for debugging but expensive to store and index in metrics systems.
In a metrics system, every unique combination of label values is a separate time series to store and index. A label like user_id with millions of values explodes the series count, which is why high-cardinality dimensions are costly, and sometimes prohibited, in metrics backends.
High-cardinality context is genuinely useful for debugging (which user, which request, which build). The trick is putting it where it is cheap: attributes on traces and structured logs handle high cardinality far better than metric labels do. A good design keeps metric labels low-cardinality and pushes the unique detail onto traces and logs.
TelemetryOps is built for high-cardinality telemetry at scale, so the context that makes an incident diagnosable is available to Sentinel AI without blowing up cost.
Because each unique label-value combination is a separate time series; high-cardinality labels multiply the series count and the cost to store and query them.
Keep metric labels low-cardinality and put unique identifiers on traces and structured logs, which are designed to handle high cardinality efficiently.
Ops Singularity turns open telemetry into autonomous, governed resolution. See it on your own stack.