tsuga-right-size-metric-cardinality

Fix high-cardinality OpenTelemetry metrics by reducing unique attribute combinations, such as moving user_id or request_id to span attributes, structured logs, or dropping them via SDK metric views to prevent time series explosions.

A metric cardinality explosion occurs when high-cardinality attributes like user_id or request_id generate excessive unique time series, driving up storage costs and degrading dashboard query performance in production observability environments.

Identify the offending metric attribute through an audit, confirm the unique count with aggregations, and relocate the high-cardinality value to a span attribute or structured log field to preserve observability without inflating metric time series.

Yes, SDK metric views can drop or bucket high-cardinality metric attributes, allowing you to reduce dimensional combinations while retaining the core metric signal in production services.

Safely refactor metrics by enforcing a mutation gate with explicit confirmation, checking downstream monitors and dashboards for breakage risk, and verifying the change by re-running metric audits after deployment.

Avoid using SDK metric views when the high-cardinality attribute is essential for the metric itself, as dropping or bucketing it may remove critical dimensional context needed by downstream dashboards and monitors.