otelconnect is using the protocol from the request to dynamically generate attributes.

This is inconsistent and inconvenient when checking how many total requests the server has received. Imagine we have three types of clients using three types of protocol, grpc, grpc-web, and connectrpc. otelconnect will generate these three types of attributes for each client:

• rpc.grpc.status_code for grpc client.
• rpc.grpc_web.status_code for grpc web client.
• rpc.connect_rpc.error_code for connect client.

In order to show how many requests the server has handled for certain status codes, we have to sum all three values by filtering status_code for each attribute. This situation is quite common to happen, especially in the process of migrating gRPC to connect RPC.

This is also not a common approach to generating attributes. Imagine we are using HTTP 1 and HTTP 2 client sending requests to a HTTP server, and the HTTP server would populate http.http1.status_code and http.http2.status_code for different HTTP clients. This looks strange.

Proposal

We could always populate

• rpc.connect_rpc.error_code (I have another proposal to change this to rpc.connect_rpc.status_code [Question] Why not use the status code? connect-go#842) AND
• rpc.grpc.status_code to keep grpc compatibility, so users don't need to manually write another interceptor to keep their grpc dashboard working.

If users don't want rpc.grpc.status_code (this is a connect rpc repo, after all), then they can use filter https://pkg.go.dev/connectrpc.com/otelconnect#WithFilter to filter out all grpc attributes.

I think we could drop attributes for grpc_web, as we can filter these specific requests by filtering rpc.system = grpc_web.

I am happy to create the PR if there are objections.