Plumb target to OpenTelemetry per-call metrics (1.64.x backport) #11182
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This will be used for gRFC A66's OTel per-RPC metric label: > `grpc.target` : Canonicalized target URI used when creating gRPC > Channel, e.g. "dns:///pubsub.googleapis.com:443", > "xds:///helloworld-gke:8000". Canonicalized target URI is the form > with the scheme included if the user didn't mention the scheme > (`scheme://[authority]/path`). The majority of the changes are to move target computation from ManagedChannelImpl into the builder. A small hack API was added to ManagedChannelBuilder to get the target to create an interceptor.
As defined by gRFC A66, the target is on all client-side per-call metrics (both call and attempt).
temawi
approved these changes
May 8, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
You'll probably want to look at the two commits separately. I am sending them in one PR because the second commit shows "what the heck Eric is doing." Each commit has a useful commit message.
I can't say I'm wild about this solution at the current state, but there are some options for getting us out of this strangeness. We need to have a team discussion, and the only thing we guarantee here that might be hard to undo is "when you configure a channel with opentelemetry, that dictates the interceptor order." Which seems appropriate for all solutions.
Backport of #11153