oss_11_m2_per_reader_cardinality_limit

[ocelotl]

Metric cardinality limits M2: per-MetricReader default cardinality limit, layered on the M1 base limit (Linear OSS-11, finding M2). Stacked on the M1 branch.

Branch / worktree: oss_11_m2_per_reader_cardinality_limit

Stacked on: oss_11_m1_metric_cardinality_limit (PR #17) — this PR's base is that branch, per the stacked-PR rule for dependent work.

Linear issue: https://linear.app/dash0/issue/OSS-11/m1-m3-metric-cardinality-limits-base-per-reader-per-view

[ocelotl]

🔒 Internal (dash0) — not for upstream.

• Linear: https://linear.app/dash0/issue/OSS-11/m1-m3-metric-cardinality-limits-base-per-reader-per-view (finding M2)
• Slug/branch/worktree: oss_11_m2_per_reader_cardinality_limit
• Commit: b2a00b40d · PR: oss_11_m2_per_reader_cardinality_limit #44 (STACKED, base = oss_11_m1_metric_cardinality_limit)
• Validation: M2 delta scope sdk + changelog; full metrics suite 310 passed.
• Reviewer note: M3 (per-view override) will stack on this branch. When M1 (PR oss_11_m1_metric_cardinality_limit #17) merges, retarget this PR to the fork default branch.

[ocelotl]

📣 Public-facing draft — to be opened upstream in open-telemetry/opentelemetry-python. No internal references; copy verbatim.

Title: Support a per-MetricReader default cardinality limit

Description

The metrics SDK enforces a base default aggregation cardinality limit (2000) that bounds distinct attribute sets per metric stream, folding excess into a single otel.metric.overflow=true series. That limit is fixed and cannot be configured per reader. The spec allows a configurable cardinality limit, and reference implementations provide a reader-level default:

• Spec: specification/metrics/sdk.md — Cardinality limits.
• Go: sdk/metric/pipeline.go wires a reader-level default into each pipeline.
• Java: CardinalityLimitSelector configures the limit per reader/instrument kind.

Without this, users who need different memory/cardinality trade-offs per export pipeline (e.g. a high-cardinality debugging reader vs. a tightly-bounded production reader) cannot configure it.

Proposed fix

Add an optional cardinality_limit parameter to MetricReader and the concrete readers (PeriodicExportingMetricReader, InMemoryMetricReader). Thread it through the pipeline (MeterProvider → measurement consumer → MetricReaderStorage → _ViewInstrumentMatch) so a reader configured with a limit applies it to all its metric streams; when unset, the base default (2000) applies. Reject non-positive limits.