[dashpole]

Note: This PR is blocked on #5444 and should wait until after it merges to be reviewed.

Description

Implements experimental support for the Metrics API OptIn instrument advisory parameter (_opt_in_advisory: bool | None = None) and the Metrics SDK View enabled configuration parameter (enabled: bool | None = None) per open-telemetry/opentelemetry-specification#4809 (tracking issue: open-telemetry/opentelemetry-specification#5384).

Summary of Changes

• opentelemetry-api:
  • Generalized _MetricsAdvisory (retaining _MetricsHistogramAdvisory as an alias) to support opt_in: bool | None = None alongside explicit_bucket_boundaries.
  • Added _validate_opt_in_advisory to validate that _opt_in_advisory is a bool (logging a warning and ignoring invalid values).
  • Added keyword-only *, _opt_in_advisory: bool | None = None to Meter.create_*, _ProxyMeter.create_*, NoOpMeter.create_*, and instrument constructors across all 7 metric instrument types (Counter, UpDownCounter, Histogram, Gauge, ObservableCounter, ObservableUpDownCounter, ObservableGauge), forwarding _opt_in_advisory when _ProxyMeter upgrades to a real Meter.
  • Included _MetricsAdvisory in Meter._register_instrument duplicate instrument conflict checks across all instrument types.
• opentelemetry-sdk:
  • Threaded _opt_in_advisory through Meter.create_* and SDK instrument classes (_Synchronous, _Asynchronous, _Histogram).
  • Added enabled: bool | None = None to View.__init__.
  • Updated _ViewInstrumentMatch so that:
    • Instruments with _opt_in_advisory=True default to DropAggregation() unless matched by a View with enabled=True.
    • Matching a View with enabled=False resolves to DropAggregation() regardless of opt_in or aggregation.
    • Matching a View with enabled=True enables opt_in instruments using the view's configured aggregation (or the instrument's default aggregation when DefaultAggregation is used).
  • Skipped view-instrument aggregation compatibility warnings in MetricReaderStorage._check_view_instrument_compatibility when view._enabled is False, and avoided false-positive metric identity conflict warnings when either stream uses _DropAggregation.

How Has This Been Tested?

• Added unit tests in:
  • opentelemetry-api/tests/metrics/test_meter.py
  • opentelemetry-api/tests/metrics/test_meter_provider.py
  • opentelemetry-sdk/tests/metrics/test_view.py
  • opentelemetry-sdk/tests/metrics/test_metrics.py
  • opentelemetry-sdk/tests/metrics/test_metric_reader_storage.py
• Added end-to-end integration tests in opentelemetry-sdk/tests/metrics/integration_test/test_opt_in_and_view_enabled.py covering all 7 instrument types with _opt_in_advisory, View(enabled=True/False/None), multiple matching views, and _ProxyMeter upgrade forwarding.

[opentelemetry-pr-dashboard]

Pull request dashboard status

Waiting on the author · refreshed 2026-11-02 18:30 UTC

Move out of draft to request review.

Status above doesn't look right?

• Just replied or pushed? Anything around or after the refresh time above may not be picked up yet — give it a few minutes.
• Anything look wrong? Report it with what you expected; it helps us improve the dashboard.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has insufficient remaining quota.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has insufficient remaining quota.

[Copilot]

🟡 Changes recommended

Disabled streams still create real per-attribute aggregations instead of using the resolved aggregation factory, incurring unnecessary aggregation and exemplar-sampling costs despite discarding their output.

1 open issue

• Use the resolved factory for per-attribute aggregations · New

_{Review effort: Balanced}

[herin049]

Thanks for adding this. FYI, we still have a PR in-progress (#5444) for adding advisory attributes and we have been going back and forth a bit on how we can do this without introducing API breakage. #5444 makes several sweeping changes to how we handle advisory attributes, so it is probably best to wait for #5444 to get merged before proceeding here.

[dashpole]

Thanks for adding this. FYI, we still have a PR in-progress (#5444) for adding advisory attributes and we have been going back and forth a bit on how we can do this without introducing API breakage. #5444 makes several sweeping changes to how we handle advisory attributes, so it is probably best to wait for #5444 to get merged before proceeding here.

Sounds good, I will wait for #5444 to merge before proceeding here.

[herin049]

Thanks for adding this. FYI, we still have a PR in-progress (#5444) for adding advisory attributes and we have been going back and forth a bit on how we can do this without introducing API breakage. #5444 makes several sweeping changes to how we handle advisory attributes, so it is probably best to wait for #5444 to get merged before proceeding here.

Sounds good, I will wait for #5444 to merge before proceeding here.

Thanks! We'll try to wrap this up ASAP to not block you.