Cardinality measures combinations, not request volume
A metric series is identified by a combination of attributes. A request counter labelled only by operation and outcome may have a manageable set of combinations. Adding a user ID, request ID or raw URL can create a new combination for nearly every request, increasing aggregation memory and backend series counts.
OpenTelemetry distinguishes measurement attributes from Resource information describing the entity producing telemetry. Service name and deployment identity usually describe the producer; an operation outcome describes the observation. Putting information in the correct place helps readers interpret the data, but does not remove the need for capacity planning.
Setup: write an attribute budget
Inventory attributes for the busiest instruments and estimate their distinct combinations from representative observations. Count combinations rather than multiplying theoretical values blindly, since some values never occur together. Identify attributes containing personal or secret information and remove them according to the organization's data-handling requirements.
Check the SDK, language and backend versions, their supported limits, and the treatment of Resource attributes. Current OpenTelemetry guidance describes a measurement-attribute cardinality limit and an overflow aggregation. That limit does not apply in the same way to Resource or instrumentation-scope attributes; moving a high-cardinality field there is not a sound workaround.
Inspect and reduce the source of series growth
- List attributes attached to the affected instrument and compare distinct values over a representative interval. Raw path segments, generated IDs and unbounded error messages deserve particular attention.
- Decide which dimensions answer an operational question. Replace raw URLs with supported route templates and move request-specific diagnostics to appropriately controlled logs or traces when suitable.
- Configure supported Views or instrumentation options to retain deliberate measurement attributes. Apply changes to a pilot and inspect both SDK aggregation behavior and the backend's newly created series.
- Review queries that filter on an attribute which may disappear in overflow. An apparently healthy filtered result can exclude measurements even while the total counter continues increasing.
Illustrative incident: total requests remain visible but failures disappear
In this illustrative scenario, a request metric combines a high-cardinality path with a boolean outcome. When the SDK's combination limit is reached, later observations enter an overflow aggregation that no longer retains the original outcome label. The total traffic chart continues to move, while an error alert filtered to the failure value misses those observations.
The team removes the unbounded path dimension and checks the affected alert using controlled requests. It keeps request-level detail in traces with deliberate access and retention controls. This example explains an instrumentation contract; it is not evidence of a real customer incident.
Diagnostic table
| Signal | Inspect | Meaning to establish |
|---|---|---|
| Rapid series creation | Attribute combinations by instrument | Unbounded measurement dimensions |
| SDK memory rises | Aggregation state and traffic shape | Cardinality-related resource cost |
| Filtered alert disagrees with total | Overflow observations and retained labels | Filter may omit measurements |
| Backend count remains high after a fix | Retention and historical series | New limits do not erase old data |
Verification and operating checks
Generate a test set with known operations and outcomes, including more varied input paths than the pilot normally sees. Compare expected observations, exported totals, overflow state and filtered queries. Confirm that reducing attributes preserves the dimensions needed for incident diagnosis.
The SOP should name owners for attribute schemas and resource identity, record SDK limits, and require a cardinality review for new instrumentation. Monitor accepted and rejected telemetry, aggregation memory and backend series growth. Treat a dashboard's visible totals as one check, not proof that every filtered SLI still represents the intended population.
See Clouvenix observability monitoring for implementation and operational handover.
Technical reference
Official reference 1; Official reference 2. Documentation checked 19 October 2026; confirm behavior for your deployed edition and version.