feat(api-core): Opentelemetry tracing support for gRPC transports in google-api-core - #18069
feat(api-core): Opentelemetry tracing support for gRPC transports in google-api-core#18069chalmerlowe wants to merge 12 commits into
Conversation
chalmerlowe
changed the title
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request introduces OpenTelemetry tracing support for gRPC channels. It adds a tracer_provider option to ClientOptions, integrates the OpenTelemetry gRPC client interceptor in grpc_helpers.create_channel when tracing is enabled, and discards the configuration parameter in the async helper to prevent runtime errors. The reviewer identified a critical bug where the code incorrectly attempts to call intercept_channel from the opentelemetry.instrumentation.grpc module instead of the standard grpc module, which would cause a runtime crash. Actionable suggestions and corresponding test updates were provided to resolve this issue.
| "grpcio-status >= 1.75.1, < 2.0.0; python_version >= '3.14'", | ||
| ] | ||
| tracing = [ | ||
| "opentelemetry-instrumentation-grpc >= 0.46b0, < 1.0.0", |
There was a problem hiding this comment.
Is this tracing extra required for customers to use tracing? Could we move the otel-api dependency into this extra?
| def test_create_channel_with_custom_tracer_provider( | ||
| monkeypatch, mock_otel_grpc, config_factory | ||
| ): | ||
| """Verify that create_channel passes custom tracer_provider to OTel interceptor.""" |
There was a problem hiding this comment.
I think a more robust test with less stubbing could be:
- add a tracer provider via the configure API
- make a gRPC request to a fake endpoint that just returns success
- ensure the tracer provider has received a span
| tracer_provider = None | ||
| if configuration is not None: | ||
| if isinstance(configuration, dict): | ||
| tracer_provider = configuration.get("tracer_provider") | ||
| else: | ||
| tracer_provider = getattr(configuration, "tracer_provider", None) |
There was a problem hiding this comment.
can all of this and is_tracing_enabled be resolved in a function on ClientOptions?
It isn't clear how ClientOptions are connecting to the kwargs["configuration"] here, or why we wouldn't pass ClientOptions directly to this function.
2 participants
Problem
Currently, users of Google Cloud Python client libraries cannot specify a custom OpenTelemetry Tracer Provider for gRPC transports.
Solution
This Pull Request introduces the foundational plumbing in
google-api-coreto support custom tracer providers for gRPC transports.tracer_provideras a recognized parameter inClientOptions.grpc_helpers.create_channelto extract thetracer_providerfrom the configuration (supporting both dictionary and object formats) and pass it to the OpenTelemetry gRPC client interceptor.grpc_helpers_async.create_channelto safely discard theconfigurationparameter. This preventsTypeErrorwhen generated async code passes it down, ensuring generated code does not fail. To keep PR size down, async tracing is deferred to a future PR in this project.Notes to Reviewers
grpc_helpers.pycontinues to fail open. If theopentelemetry-instrumentation-grpcpackage is not installed, tracing is skipped quietly without failing the transport creation.grpc_helpers_async.pyare strictly defensive to prevent runtime errors when generated code tries to pass configuration down.