Skip to content

oss_11_m2_per_reader_cardinality_limit#44

Open
ocelotl wants to merge 1 commit into
oss_11_m1_metric_cardinality_limitfrom
oss_11_m2_per_reader_cardinality_limit
Open

oss_11_m2_per_reader_cardinality_limit#44
ocelotl wants to merge 1 commit into
oss_11_m1_metric_cardinality_limitfrom
oss_11_m2_per_reader_cardinality_limit

Conversation

@ocelotl

@ocelotl ocelotl commented Jul 22, 2026

Copy link
Copy Markdown
Owner

Closes #41

Per-MetricReader default cardinality limit (Linear OSS-11, finding M2), layered on the M1 base limit. Optional cardinality_limit on MetricReader / PeriodicExportingMetricReader / InMemoryMetricReader, threaded through the pipeline into _ViewInstrumentMatch; unset falls back to the M1 base default (2000); non-positive raises ValueError.

Stacked on oss_11_m1_metric_cardinality_limit (PR #17) — this PR's base is that branch, so its diff shows only the M2 delta. Retarget to the fork default branch once M1 merges.

Validation: M2 delta scope contained to opentelemetry-sdk + changelog; full metrics suite 310 passed.

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

@ocelotl

ocelotl commented Jul 22, 2026

Copy link
Copy Markdown
Owner Author

🔒 Internal (dash0) — not for upstream.

@ocelotl

ocelotl commented Jul 22, 2026

Copy link
Copy Markdown
Owner Author

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

Title: Add per-MetricReader default cardinality limit

What

Adds an optional cardinality_limit parameter to MetricReader and its concrete subclasses (PeriodicExportingMetricReader, InMemoryMetricReader). When set, the limit is threaded through the SDK pipeline (SynchronousMeasurementConsumerMetricReaderStorage_ViewInstrumentMatch) and applied to every metric stream produced through that reader's pipeline. When unset, the existing base default cardinality limit is used. A non-positive limit raises ValueError.

Why

The base cardinality limit is fixed and cannot be tuned per reader; different export pipelines often need different cardinality/memory trade-offs. This aligns with the spec's configurable cardinality limits and the reader-level defaults in Go (sdk/metric/pipeline.go) and Java (CardinalityLimitSelector).

Spec / references

specification/metrics/sdk.md — Cardinality limits; Go sdk/metric/pipeline.go; Java CardinalityLimitSelector.

Notes

Builds on the base cardinality-limit change (_DEFAULT_CARDINALITY_LIMIT + the otel.metric.overflow series in _ViewInstrumentMatch). This adds only the per-reader override; when a reader sets no limit, behavior is unchanged.

Tests

New integration tests: a reader with a small limit overflows at that limit; no overflow below the reader's limit; unset falls back to the base default; non-positive limits are rejected. Existing metrics tests pass (310).

Add an optional cardinality_limit parameter to MetricReader and the concrete
readers (PeriodicExportingMetricReader, InMemoryMetricReader). When set, the
limit is threaded through the SDK pipeline (SynchronousMeasurementConsumer ->
MetricReaderStorage -> _ViewInstrumentMatch) so that every metric stream
produced through that reader's pipeline overflows into the single
otel.metric.overflow series at the reader's limit instead of the base default.
When unset, the base default cardinality limit still applies. A non-positive
limit is rejected with ValueError.
@ocelotl
ocelotl force-pushed the oss_11_m2_per_reader_cardinality_limit branch from b2a00b4 to e579430 Compare July 22, 2026 13:41
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant