Use case(s) - what problem will this feature solve?
I have a stats handler that adds more attributes to an Otel span that gets created by their gRPC stats handler. One of the attributes that I'd like to add is Authority. We run in a service mesh environment where Authority is what actually decides where we route requests to. This is more important to us than something like the Address because we route all requests through a local Envoy sidecar so the address is always something on localhost, rather than where we actually send the requests.
This is especially helpful to have in the stats.Handler because the Authority can be set in several ways. Based on the target address, specified as a DialOption, or specified as a CallOption. Having one place where we can trust which Authority value is actually used would be super helpful.
Proposed Solution
Add Authority to the OutHeader struct for stats.Handler, and include the Authority psuedo header in that struct when creating a new stream for outgoing requests.
We'd add Authority to that struct here:
It would look something like this.
// OutHeader contains stats about header transmission.
//
// - Client-side: Only occurs after 'Begin', as headers are always the first
// thing sent on a stream.
type OutHeader struct {
// Client is true if this OutHeader is from client side.
Client bool
// Compression is the compression algorithm used for the RPC.
Compression string
// Header contains the header metadata sent.
Header metadata.MD
// Authority is the pseudoheader sent in the header frame.
Authority string
// The following fields are valid only if Client is true.
// FullMethod is the full RPC method string, i.e., /package.service/method.
FullMethod string
// RemoteAddr is the remote address of the corresponding connection.
RemoteAddr net.Addr
// LocalAddr is the local address of the corresponding connection.
LocalAddr net.Addr
}We'd then set that value when sending the headers for the new stream.
|
s.statsHandler.HandleRPC(s.ctx, &stats.OutHeader{ |
s.statsHandler.HandleRPC(s.ctx, &stats.OutHeader{
Client: true,
FullMethod: callHdr.Method,
RemoteAddr: t.remoteAddr,
LocalAddr: t.localAddr,
Compression: callHdr.SendCompress,
Header: header,
Authority: callHdr.Authority,
})Alternatives Considered
I first tried to just save either the target address or the authority we set in our DialOptions into our stats.Handler so we could use that for later. That works great for authorities that are statically defined at startup, but that doesn't catch the case when we dynamically set the authority using a CallOption during runtime.
Additional Context
Use case(s) - what problem will this feature solve?
I have a stats handler that adds more attributes to an Otel span that gets created by their gRPC stats handler. One of the attributes that I'd like to add is Authority. We run in a service mesh environment where Authority is what actually decides where we route requests to. This is more important to us than something like the Address because we route all requests through a local Envoy sidecar so the address is always something on localhost, rather than where we actually send the requests.
This is especially helpful to have in the stats.Handler because the Authority can be set in several ways. Based on the target address, specified as a DialOption, or specified as a CallOption. Having one place where we can trust which Authority value is actually used would be super helpful.
Proposed Solution
Add Authority to the OutHeader struct for stats.Handler, and include the Authority psuedo header in that struct when creating a new stream for outgoing requests.
We'd add Authority to that struct here:
grpc-go/stats/stats.go
Line 186 in a5e7cd6
It would look something like this.
We'd then set that value when sending the headers for the new stream.
grpc-go/internal/transport/http2_client.go
Line 927 in 5c7f936
Alternatives Considered
I first tried to just save either the target address or the authority we set in our DialOptions into our stats.Handler so we could use that for later. That works great for authorities that are statically defined at startup, but that doesn't catch the case when we dynamically set the authority using a CallOption during runtime.
Additional Context