Support passing otelhttp.Option and otelgrpc.Option for OpenTelemetry instrumentation of clients #3138
Labels
priority: p3
Desirable enhancement or fix. May not be included in next release.
type: feature request
‘Nice-to-have’ improvement, new feature or different behavior or design.
Is your feature request related to a problem? Please describe.
Currently, OpenTelemetry is enabled by default, but there is no way to pass a custom slice of
otelhttp.Option
orotelgrpc.Option
, such as a custom tracer provider. This limits flexibility for applications that must integrate with specific OpenTelemetry configurations (e.g., having multiple providers, custom propagators, or tailored span settings for gRPC or HTTP separately).Describe the solution you’d like
Allow users to pass slices of both
otelhttp.Option
andotelgrpc.Option
when creating a Google API client, enabling customization of the OpenTelemetry instrumentation across both HTTP and gRPC transports. This would allow configuration of tracer providers, propagators, span name formatters, and more, per transport layer.Describe alternatives you’ve considered
option.WithHTTPClient
is technically possible. Doing so requires re-implementing other pieces like authentication, retry logic, and context propagation, which introduces boilerplate and increases the chance of errors.option.WithGRPCDialOption
, but requires users to understand and reconstruct internal dialing logic, making it error-prone.Additional context
I’ve submitted a pull request that adds this functionality for HTTP: #3130.
It adds support for passing
otelhttp.Option
via a newWithOpenTelemetryOpts
helper.Example for HTTP:
The text was updated successfully, but these errors were encountered: