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
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.
Alternatively add 2 new environment variables OTEL_EXPORTER_OTLP_GRPC_CREDENTIAL_PROVIDER for the GRPC OTLP exporters, and OTEL_EXPORTER_OTLP_HTTP_CREDENTIAL_PROVIDER for the HTTP OTLP exporters. These should actually be named OTEL_PYTHON_... according to https://opentelemetry.io/docs/specs/otel/configuration/sdk-environment-variables/#language-specific-environment-variables because they aren't part of the official environment variable spec.
This environment variable will be set to an entry point that when loaded and initialized returns a ChannelCredentials (for grpc) or Session (for HTTP) object, auto instrumentation code will then pass that into the OTLP exporter(s). The OTLP exporters already accept these objects in their constructors. We could load these in the OTLP exporter classes OR in the configurator class. The exporters currently don’t use the entry_points API at all, which is needed for this approach to work.
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.
Alternatively add 2 new environment variables OTEL_EXPORTER_OTLP_GRPC_CREDENTIAL_PROVIDER for the GRPC OTLP exporters, and OTEL_EXPORTER_OTLP_HTTP_CREDENTIAL_PROVIDER for the HTTP OTLP exporters. These should actually be named
OTEL_PYTHON_...
according to https://opentelemetry.io/docs/specs/otel/configuration/sdk-environment-variables/#language-specific-environment-variables because they aren't part of the official environment variable spec.This environment variable will be set to an entry point that when loaded and initialized returns a ChannelCredentials (for grpc) or Session (for HTTP) object, auto instrumentation code will then pass that into the OTLP exporter(s). The OTLP exporters already accept these objects in their constructors. We could load these in the OTLP
exporter
classes OR in theconfigurator
class. The exporters currently don’t use the entry_points API at all, which is needed for this approach to work.I prototyped this solution here.
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: