Support OTEL_METRIC_EXPORT_INTERVAL and OTEL_METRIC_EXPORT_TIMEOUT

[pellared]

Fixes #3417.

Changes

The MetricReaderOptions defaults can be overridden using
OTEL_METRIC_EXPORT_INTERVAL and OTEL_METRIC_EXPORT_TIMEOUT
environmental variables as defined in the
specification.

This change applies to all metrics exporters that use PeriodicExportingMetricReaderHelper.CreatePeriodicExportingMetricReader

• OTLP
• Console
• InMemory

I think it is not possible to implement it for all instances of PeriodicExportingMetricReader without changing and breaking its public API (assuming that the value in "options" has precedence over the environmental variable which is the currently followed pattern).

For significant contributions please make sure you have completed the following items:

• Appropriate CHANGELOG.md updated for non-trivial changes
• Design discussion issue #
• Changes in public API reviewed
  • I added default values to CreatePeriodicExportingMetricReader that match the OTel spec

[codecov]

Codecov Report

Merging #3424 (0a0d734) into main (bc4f788) will increase coverage by 0.10%.
The diff coverage is 94.44%.

@@            Coverage Diff             @@
##             main    #3424      +/-   ##
==========================================
+ Coverage   86.20%   86.30%   +0.10%     
==========================================
  Files         263      263              
  Lines        9545     9550       +5     
==========================================
+ Hits         8228     8242      +14     
+ Misses       1317     1308       -9     

Impacted Files	Coverage Δ
...Telemetry/Metrics/PeriodicExportingMetricReader.cs	78.18% <75.00%> (+5.45%)	⬆️
...nTelemetryProtocol/OtlpMetricExporterExtensions.cs	80.76% <100.00%> (-1.38%)	⬇️
...ry/Internal/PeriodicExportingMetricReaderHelper.cs	100.00% <100.00%> (ø)
...ZPages/Implementation/ZPagesExporterEventSource.cs	56.25% <0.00%> (-6.25%)	⬇️
src/OpenTelemetry/Metrics/MetricReader.cs	88.13% <0.00%> (+1.69%)	⬆️
...emetry.Api/Internal/OpenTelemetryApiEventSource.cs	82.35% <0.00%> (+5.88%)	⬆️
src/OpenTelemetry/ProviderExtensions.cs	90.90% <0.00%> (+9.09%)	⬆️
...tation/OpenTelemetryProtocolExporterEventSource.cs	85.00% <0.00%> (+10.00%)	⬆️

[pellared]

Side note:

These failures are awkward: https://github.com/open-telemetry/opentelemetry-dotnet/runs/7217170744?check_suite_focus=true

Did anyone encounter the same problem? Looks like some strange side-effect - I have not analyzed it.

[joaopgrassi]

Looks good to me :) Just left one small question about the readme changes.

[cijothomas]

LGTM.

[reyang]

The environment variables are still marked as Experimental
https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/sdk-environment-variables.md, what's the plan here (e.g. push the change to a feature branch; wait until the spec becomes stable, merge in the main branch and do not release stable until the spec becomes stable)?

[reyang]

#3424 (comment)

[cijothomas]

The environment variables are still marked as Experimental https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/sdk-environment-variables.md, what's the plan here (e.g. push the change to a feature branch; wait until the spec becomes stable, merge in the main branch and do not release stable until the spec becomes stable)?

Did not realize that https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/sdk-environment-variables.md#periodic-exporting-metricreader was still experimental!

Will 1st check if Metrics Spec is close to marking this stable, and based on that device a plan for support in the SDK.

[pellared]

@cijothomas @reyang
These env vars are to my best knowledge already supported by OTel Java, Python, and PHP. See here and here. I think the probability that this part of the spec would change is close to 0. Of course, double-checking with Metrics SIG would be good 😉

I guess that OTEL_METRICS_EXEMPLAR_FILTER env var is the "more experimental" env var. This is the only reason why I am not creating a PR in the OTel spec 😉

EDIT: I decided to create open-telemetry/opentelemetry-specification#2658

Spec issue resolved.

[reyang]

LGTM.