You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This environment variable will be set to an entry point that when loaded and initialized returns a ChannelCredentials or Session object, the Configurator code will then pass that into the OTLP exporter(s). The OTLP exporters already accept these objects in their constructors.
ChannelCredentials and Session handle automatically setting and refreshing the Authorization header.
It’s already standard in the auto instrumentation code to use environment variables to configure the OTLP exporters, so I think this is the most straightforward option.
Describe alternatives you've considered
An alternative is to use the existing environment variables (OTEL_METRICS_EXPORTER, OTEL_TRACES_EXPORTER, OTEL_LOGS_EXPORTER) that inject metrics, traces, and log exporters. An initialized exporter with ChannelCredentials / Session could be passed to them. The code would have to be updated to accept class instance objects, instead of only Class objects.
This solution is fine, but it requires users to set multiple environment variables instead of only 1 in cases where they want to send multiple kinds of telemetry to google's API.
It also could be confusing for users that they need to specify an exporter that isn't the default OTLP exporter, when it is technically the default OTLP exporter that is being used under the hood.
Another alternative solution is to add a new environment variable (OTEL_EXPORTER_OTLP_CUSTOMIZER, and log/metric/trace equivalents) to the sdk. I prototyped this at #4452.
This environment variable will be set to an entry point that when loaded and initialized returns an ExporterCustomizer class which has a single configure_exporter function, that takes an OtlpExporter class, initializes it with whatever arguments it wants to (ex: passing in the Session or ChannelCredentials etc.), and returns the class instance.
This would allow vendors to customize the OTLP exporters for users instead of asking users to set 5 or 6 environment variables.
I'm fine with this approach too, but again it could be unclear to users what exactly the customizer is doing to their exporters.
There's an open PR in go (https://github.com/open-telemetry/opentelemetry-go/pull/6362/files) and a merged PR for Java (1, 2) to support dynamic headers in the OTLP exporter. Meaning the exporter take function(s) that get invoked on each export call to produce header(s) that are added to the request.
I proposed something like that in #4431, but it was pointed out that Session and ChannelCredentials exist and can do what I need.
Is your feature request related to a problem?
In order to authenticate to some Google APIs, we need the Authorization header to be added and then periodically refreshed in the OTLP exporter.
This is possibly by injecting ChannelCredentials (for grpc) or Session (for HTTP) into the OTLP exporters
Currently for auto instrumentation there's no way to inject these objects.
Describe the solution you'd like
Add new environment variables (OTEL_EXPORTER_OTLP_CREDENTIAL_PROVIDER, OTEL_EXPORTER_OTLP_LOGS_CREDENTIAL_PROVIDER, OTEL_EXPORTER_OTLP_METRICS_CREDENTIAL_PROVIDER,
OTEL_EXPORTER_OTLP_TRACES_CREDENTIAL_PROVIDER) to the sdk. These should be named
OTEL_PYTHON_...
according to https://opentelemetry.io/docs/specs/otel/configuration/sdk-environment-variables/#language-specific-environment-variables, but I'm not sure if python follows that guidance or not.I prototyped this solution here.
This environment variable will be set to an entry point that when loaded and initialized returns a ChannelCredentials or Session object, the Configurator code will then pass that into the OTLP exporter(s). The OTLP exporters already accept these objects in their constructors.
ChannelCredentials and Session handle automatically setting and refreshing the Authorization header.
It’s already standard in the auto instrumentation code to use environment variables to configure the OTLP exporters, so I think this is the most straightforward option.
Describe alternatives you've considered
An alternative is to use the existing environment variables (OTEL_METRICS_EXPORTER, OTEL_TRACES_EXPORTER, OTEL_LOGS_EXPORTER) that inject metrics, traces, and log exporters. An initialized exporter with ChannelCredentials / Session could be passed to them. The code would have to be updated to accept class instance objects, instead of only Class objects.
This solution is fine, but it requires users to set multiple environment variables instead of only 1 in cases where they want to send multiple kinds of telemetry to google's API.
It also could be confusing for users that they need to specify an exporter that isn't the default OTLP exporter, when it is technically the default OTLP exporter that is being used under the hood.
Another alternative solution is to add a new environment variable (OTEL_EXPORTER_OTLP_CUSTOMIZER, and log/metric/trace equivalents) to the sdk. I prototyped this at #4452.
This environment variable will be set to an entry point that when loaded and initialized returns an
ExporterCustomizer
class which has a singleconfigure_exporter
function, that takes anOtlpExporter
class, initializes it with whatever arguments it wants to (ex: passing in theSession
orChannelCredentials
etc.), and returns the class instance.This would allow vendors to customize the OTLP exporters for users instead of asking users to set 5 or 6 environment variables.
I'm fine with this approach too, but again it could be unclear to users what exactly the customizer is doing to their exporters.
Additional Context
How Java code does it: 1, 2.
Would you like to implement a fix?
Yes
The text was updated successfully, but these errors were encountered: