Gate PeriodicMetricReader self-observability by internal telemetry version

[Debashismitra01]

What was changed

• Added support for configuring PeriodicMetricReader with an InternalTelemetryVersion.
• Updated MetricExporterConfiguration to propagate the configured telemetry version when creating PeriodicMetricReader.
• Gated metric reader self-observability initialization based on the configured telemetry version.
• Preserved existing SDK behavior by defaulting PeriodicMetricReaderBuilder to InternalTelemetryVersion.LATEST.

Why?

PeriodicMetricReader always emitted otel.sdk.metric_reader.collection.duration whenever a real MeterProvider was available, regardless of OTEL_EXPERIMENTAL_SDK_TELEMETRY_VERSION.

Tracing and logging already gate SDK self-observability using InternalTelemetryConfiguration.getVersion(config). This change aligns metric reader self-observability with the existing behavior while preserving the default behavior for direct SDK users.

Fixes #8566

[otelbot]

⚠️ API changes detected — additional maintainer review required

@jack-berg @jkwatson

This PR modifies the public API surface area of the following module(s):

• opentelemetry-sdk-metrics

Please review the changes in docs/apidiffs/current_vs_latest/ carefully before approving.

[codecov]

Codecov Report

❌ Patch coverage is 91.66667% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 91.62%. Comparing base (fef8fdb) to head (8eda1c0).
⚠️ Report is 8 commits behind head on main.

Files with missing lines	Patch %	Lines
...metry/sdk/metrics/export/PeriodicMetricReader.java	75.00%	0 Missing and 1 partial ⚠️

Additional details and impacted files

@@            Coverage Diff            @@
##               main    #8597   +/-   ##
=========================================
  Coverage     91.62%   91.62%           
- Complexity    10321    10345   +24     
=========================================
  Files          1013     1013           
  Lines         27287    27361   +74     
  Branches       3203     3215   +12     
=========================================
+ Hits          25001    25069   +68     
- Misses         1559     1565    +6     
  Partials        727      727           

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[jkwatson]

I'm ok with the API change in this PR

[jack-berg]

My position has been that we should only add the setInternalTelemetryVersion once a component supports multiple telemetry versions. And if a component only supports a single telemetry version like LATEST and the resolved version is LEGACY, then we set the meter provider to a noop. For example:

opentelemetry-java/sdk-extensions/autoconfigure/src/main/java/io/opentelemetry/sdk/autoconfigure/LoggerProviderConfiguration.java

Lines 50 to 53 in 9118446

	InternalTelemetryVersion telemetryVersion = InternalTelemetryConfiguration.getVersion(config);
	if (telemetryVersion != InternalTelemetryVersion.LEGACY) {
	loggerProviderBuilder.setMeterProvider(() -> meterProvider);
	}

This accomplishes the same thing but avoids adding public API surface area which may imply that the component supports different telemetry versions when it doesn't. A debateable win since it also means we have inconsistent APIs across our components, some with setInternalTelemetryVersion, some without.

PeriodicMetricReader is a special case though because it does not have a setMeterProvider method, and so there is no way to disable internal telemetry when the version is set to LEGACY.

That's why this PR makes sense. And now I'm warming up to going further and adding setInternalTelemetryVersion on all components, and documenting the versions supported by each component in javadoc. Of course, we would do that in a separate PR.

A couple of minor comments, but looks good. Thanks!

[opentelemetry-pr-dashboard]

This PR has review comments. Review suggestions, whether from maintainers or automated reviewers, aren't always correct or required. Please evaluate each comment on its merits, then make sure each thread has a clear outcome.

For example, link to the commit if you applied a suggestion, explain why it wasn't applied, or ask a follow-up question.

Automation flags a PR for human review once every review thread has a reply or is marked as resolved.

Status across open PRs is visible on the pull request dashboard.

[Debashismitra01]

Done, thanks @jack-berg ! I updated the declarative configuration path as well by propagating the internal telemetry version to PeriodicMetricReaderBuilder via DeclarativeConfigContext, mirroring the autoconfigure path.

[otelbot]

Thank you for your contribution @Debashismitra01! 🎉 We would like to hear from you about your experience contributing to OpenTelemetry by taking a few minutes to fill out this survey.