Document OTEL_EXPORTER_OTLP_METRICS_TEMPORALITY_PREFERENCE environment variable

[pichlermarc]

Feature Request

Is your feature request related to a problem? Please describe.
Currently the OTEL_EXPORTER_OTLP_METRICS_TEMPORALITY_PREFERENCE enviornment variable is not used to configure the export temporality (see here).

The spec states that:

If a language provides a mechanism to automatically configure a
MetricReader to pair with the associated
Exporter (e.g., using the OTEL_METRICS_EXPORTER environment
variable),
then by default:

• The exporter MUST be paired with a periodic exporting
  MetricReader.
• The exporter MUST configure the default aggregation temporality on the
  basis of instrument kind using the
  OTEL_EXPORTER_OTLP_METRICS_TEMPORALITY_PREFERENCE variable as described
  below.
• The exporter MUST configure the default aggregation on the basis of instrument kind using
  the OTEL_EXPORTER_OTLP_METRICS_DEFAULT_HISTOGRAM_AGGREGATION variable as described below if it is implemented.

Describe the solution you'd like
Allow configuration of aggregation temporality via OTEL_EXPORTER_OTLP_METRICS_TEMPORALITY_PREFERENCE

Additional context
As this is a MUST requirement in the spec, this might also be a bug.

[pellared]

Thanks for reporting the issue. I created a similar one in the OTel .NET SDK: open-telemetry/opentelemetry-dotnet#3756

[pichlermarc]

Hi, @pellared thanks for creating the issue in the core repo. 🙂

I was not sure if here is the right place, or if I should open it in the core repo, but as the condition part of this spec

If a language provides a mechanism to automatically configure a MetricReader to pair with the associated Exporter (e.g., using the OTEL_METRICS_EXPORTER environment variable), then by default

is implemented in this repo, I opted to open the issue here instead. 🙂

If there's a consensus where this feature belongs then I can also dedicate some time to implement this if necessary. 🙂

[Kielek]

@pichlermarc, we have a plan release 0.4.0-beta shortly. If it is important feature for you we can include it into this code base. If it can wait it should be implemented in the api/sdk repository.

Upgrade path for OTel API/SDK 1.4.0 will be more complicated and it will take more time.

If there's a consensus where this feature belongs then I can also dedicate some time to implement this if necessary. 🙂

Sounds great!

[pellared]

If there's a consensus where this feature belongs then I can also dedicate some time to implement this if necessary. 🙂

It is fine to implement it here before it is supported via the SDK 👍 We are open to your contribution 🎉

[pellared]

@pichlermarc Are you working on it? Do you need any help?

[pichlermarc]

@pellared, sorry, I did not get around to doing this yet. :/
I'll comment here when I get to working on it.

[RassK]

This PR adds a workaround for a moment missing direct configuration option.
#1542

[pichlermarc]

Hi, I just went over old issues I created and this seems to be already implemented.

I just tried this out using the automatic instrumentation docs on opentelemetry.io, switched the exporter to OTLP and set up the environment variable.

Big thanks to the person who took care of that 🙂

[pellared]

Reopening as the environment variable is not documented.