Cardinality explosion occurs when metric dimensions take many distinct values or combinations, multiplying the number of time series a time-series database must ingest, store, and query. Bounded dimensions such as HTTP status codes are usually manageable; unbounded dimensions such as user IDs can become extremely expensive and slow queries. section 2.4.3 section 5.3
A user ID label
A request metric such as myapp_http_requests_total{code="200", handler="/ex1"} uses relatively bounded dimensions. Adding uid="9876" creates a separate series for that user; at hundreds of thousands or millions of users, one metric can require hundreds of thousands of stored series. section 2.4.3 section 5.3
Control cardinality by considering these operational consequences:
- Keep metric dimensions bounded; avoid labels whose possible values can grow with users or other large populations. section 2.4.3 section 5.3
- Expect storage costs and query times to rise as the time-series database inspects more series across a time range. section 5.3
- For high-cardinality signals and use cases, consider columnar data stores and formats rather than forcing every dimension into metrics. section 5.7
Table 2.2 Overview of the costs of metrics (view table figure)
| Prometheus, OpenTelemetry collector, and OpenMetrics as emerging standard |
||
Use the metric-cost overview to compare instrumentation, agent collection, destination cardinality, retention, long-term storage, and federation considerations. section 2.4.3
