OpenTelemetry cardinality is a reliability budget
Recent OpenTelemetry guidance notes that SDKs limit cardinality to protect memory when a metric receives too many attribute combinations. The limit prevents local collapse, but may also drop series the team expected to investigate.
- Editorial date
- 2026-08-20
- Scope
- OpenTelemetry metrics · cardinality and cost
- Nature
- Daily edition recovered on 24 August 2026; facts anchored to the publication date
- Verified
- 24 August 2026
In brief
Recent OpenTelemetry guidance notes that SDKs limit cardinality to protect memory when a metric receives too many attribute combinations. The limit prevents local collapse, but may also drop series the team expected to investigate. Set a per-metric budget from the operating question and deny attributes without a bounded population and clear use. user_id, request_id, free-form URL, or error message can turn a useful metric into a near-unbounded dimension.
- Cardinality is the product of value combinations, not only the number of attribute names.
- Set a per-metric budget from the operating question and deny attributes without a bounded population and clear use.
- inventorying metrics, attributes, estimated population, and the query each supports.
- The dashboard should show accepted and dropped series, memory, cost, and lost investigative value per metric.
The signal and the facts that change the decision
Recent OpenTelemetry guidance notes that SDKs limit cardinality to protect memory when a metric receives too many attribute combinations. The limit prevents local collapse, but may also drop series the team expected to investigate.
Cardinality is the product of value combinations, not only the number of attribute names. Limits and behaviour vary by SDK and version; configuration must be verified in the implementation in use.
Logs and traces can carry high-cardinality identifiers that do not belong in aggregated metrics. user_id, request_id, free-form URL, or error message can turn a useful metric into a near-unbounded dimension.
Operating window
- 08-20Signal confirmed
Recent OpenTelemetry guidance notes that SDKs limit cardinality to protect memory when a metric receives too many attribute combinations. The limit prevents local collapse, but may also drop series the team expected to investigate.
- AGORAFix the scope
Cardinality is the product of value combinations, not only the number of attribute names.
- GATEMake the decision
Set a per-metric budget from the operating question and deny attributes without a bounded population and clear use.
- FECHORetain the proof
The dashboard should show accepted and dropped series, memory, cost, and lost investigative value per metric.
Decision, limits, and stop condition
Set a per-metric budget from the operating question and deny attributes without a bounded population and clear use.
user_id, request_id, free-form URL, or error message can turn a useful metric into a near-unbounded dimension.
Operating gate
An unknown answer keeps the item open and owned.
| Question | Decision | Proof |
|---|---|---|
| Is the asset in scope? | Cardinality is the product of value combinations, not only the number of attribute names. | Limits and behaviour vary by SDK and version; configuration must be verified in the implementation in use. |
| Does the risk change priority? | Set a per-metric budget from the operating question and deny attributes without a bounded population and clear use. | Logs and traces can carry high-cardinality identifiers that do not belong in aggregated metrics. |
| Can the action be closed? | user_id, request_id, free-form URL, or error message can turn a useful metric into a near-unbounded dimension. | The dashboard should show accepted and dropped series, memory, cost, and lost investigative value per metric. |
Execution and proof of completion
Execution should start by inventorying metrics, attributes, estimated population, and the query each supports. Then, generating realistic-cardinality load and observing memory, drops, and backend cost. Closure requires moving identifiers to exemplars, logs, or traces where appropriate.
The dashboard should show accepted and dropped series, memory, cost, and lost investigative value per metric.
- inventorying metrics, attributes, estimated population, and the query each supports.
- generating realistic-cardinality load and observing memory, drops, and backend cost.
- moving identifiers to exemplars, logs, or traces where appropriate.
- The dashboard should show accepted and dropped series, memory, cost, and lost investigative value per metric.
Sources consulted
Consulted on the stated update date.
Opens in a new window.- 01What can you do with OpenTelemetry entity events?OpenTelemetry · SYS-OTEL
- 02Metric cardinality limits in OpenTelemetryOpenTelemetry · SYS-OTEL
- 03OpenTelemetry resources semantic conventionsOpenTelemetry · SYS-OTEL
- 04OpenTelemetry Collector scalingOpenTelemetry · SYS-OTEL
- 05OpenTelemetry troubleshootingOpenTelemetry · SYS-OTEL
- 06Cybersecurity Framework 2.0NIST · GL-NIST
Participate
Share the analysis. Add context.
Distribute the article through your channel or leave an observation connected to the topic.
Comments
Loading the conversation.