Skip to content

Support passing otelhttp.Option and otelgrpc.Option for OpenTelemetry instrumentation of clients #3138

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
surik opened this issue May 5, 2025 · 5 comments
Assignees
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.

Comments

@surik
Copy link

surik commented May 5, 2025

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 or otelgrpc.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 and otelgrpc.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

  • Using a global tracer provider. This doesn’t allow for per-client or per-subsystem customization.
  • Wrapping the HTTP transport manually using 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.
  • For gRPC, manually configuring interceptors is possible using 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 new WithOpenTelemetryOpts helper.

Example for HTTP:

import (
    "context"
    "go.opentelemetry.io/contrib/instrumentation/net/http/otelhttp"
    "cloud.google.com/go/bigquery"
    "google.golang.org/api/option"
    sdktrace "go.opentelemetry.io/otel/sdk/trace"
)

func newBigQueryClient(ctx context.Context) (*bigquery.Client, error) {
    tp := sdktrace.NewTracerProvider()

    client, err := bigquery.NewClient(ctx, "my-project-id",
        option.WithOpenTelemetryOpts(
            otelhttp.WithTracerProvider(tp),
        ),
    )
    if err != nil {
        return nil, err
    }
    return client, nil
}
@surik surik added 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. labels May 5, 2025
@quartzmo
Copy link
Member

quartzmo commented May 5, 2025

@surik Thank you for opening this feature request. Can you expand it to also somehow include go.opentelemetry.io/contrib/instrumentation/google.golang.org/grpc/otelgrpc.Option?

@quartzmo quartzmo assigned quartzmo and unassigned codyoss May 5, 2025
@surik surik changed the title Support custom otelhttp.Option for OpenTelemetry in clients via option.WithOpenTelemetryOpts Support passing otelhttp.Option and otelgrpc.Option for OpenTelemetry instrumentation of clients May 6, 2025
@surik
Copy link
Author

surik commented May 6, 2025

@quartzmo expanded. I haven't looked at how to implement for otelgrpc, but I believe this will be very similar to otelhttp

@quartzmo
Copy link
Member

quartzmo commented May 6, 2025

@surik Thank you! I will try to move this forward.

@quartzmo
Copy link
Member

quartzmo commented May 8, 2025

@surik We can move forward with trying to find a solution for this. An important constraint will be to avoid exporting the dependency on any go.opentelemetry.io packages from the google.golang.org/api/option package. Do you think WithOpenTelemetryOpts could accept a variadic of empty interface type, the contents of which would be later typecast to either otelhttp or otelgrpc options?

@surik
Copy link
Author

surik commented May 12, 2025

@quartzmo, please take a look at this commit 334fb10

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
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.
Projects
None yet
Development

No branches or pull requests

3 participants