Open cijothomas opened 1 month ago
I think it is better to have the _OTLP_
and also other exporters would also have its own _[NAME]_
as it would allow better granularity when multiple exporters are used.
Moreover, the current env vars are stable.
Therefore, I would rather propose defining equivalent env vars for other exporters than removing _OTLP_
.
I would rather propose defining equivalent env vars for other exporters than removing OTLP.
@cijothomas which other metric exporters are you wanting to define this for?
I would rather propose defining equivalent env vars for other exporters than removing OTLP.
@cijothomas which other metric exporters are you wanting to define this for?
For example, stdout - https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/metrics/sdk_exporters/stdout.md
There are also other exporters not part of the spec, that won't be able to leverage this env variable today as its tied to OTLP Exporter.
Other env variables like the one controlling Exemplars are not tied to OTLPExporter. However OTEL_EXPORTER_OTLP_METRICS_DEFAULT_HISTOGRAM_AGGREGATION
is another which seems tied to OTLPExporter.
does it make sense to look at this proposal under declarative configuration (instead of introducing any new env vars)?
@cijothomas any comments on @trask's question?
What are you trying to achieve? Trying to influence Metric aggregation temporality, aggregation for histograms when using non-otlp exporting.
What did you expect to see?
A MeterProvider/MetricReader env variable to control the same. However, the existing env variables are tied to OTLP Exporter only, and does not work when other exporting is used: https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/metrics/sdk_exporters/otlp.md#additional-environment-variable-configuration
I think these variables should be respected by the SDK (after changing the name to remove "OTLP" from them).