Thanks for stopping by to let us know something could be better!

PLEASE READ: If you have a support contract with Google, please create an issue in the support console instead of filing on GitHub. This will ensure a timely response.

Is your feature request related to a problem? Please describe.
Currently, the google-cloud-rust client libraries do not provide tracing for the underlying unary gRPC network requests. This makes it difficult to get a complete picture of request latency and to diagnose
network-level issues, as only the higher-level client operation is traced. We need visibility into each gRPC attempt.

Describe the solution you'd like
Implement client-side tracing for unary gRPC requests made by the client libraries. This involves creating a span for each gRPC network attempt.

The span should include:

• Standard RPC attributes (rpc.system, rpc.service, rpc.method, net.peer.name, net.peer.port).
• gRPC specific attributes (rpc.grpc.status_code).
• Error information on failure.
• Client library-specific attributes (gcp.client.service, gcp.client.version, etc.) to identify the calling library.

This will be achieved by adding a custom Tonic interceptor (tower::Layer) within the google-cloud-gax-internal crate. Tracing for streaming gRPC calls is out of scope for this issue.

Describe alternatives you've considered

1. Using existing Tonic tracing crates: Existing crates lack the flexibility to add our custom gcp.client.* attributes.
2. Modifying Tonic directly: Upstreaming changes would be time-consuming and might not align with Tonic's goals.
3. Passing all metadata via request extensions: This would require more extensive changes to the code generator and add complexity.

The chosen interceptor approach allows for targeted changes within our GAX layer.

Additional context
This work is part of a larger effort to enhance observability within the Google Cloud client libraries for Rust. This specific feature request addresses the network span requirement for unary gRPC.