RPC semconv stability project proposal

[trask]

Marking as ready for review, but it's not ready for approvals yet since we haven't lined up the necessary staffing yet.

[lmolkova]

Based on the discussion during SemConv call on 4/21/25, adding a few large topics I'd like to figure out in the scope of this group:

1. What's an RPC system? Graph QL, WebSockets , SSE over HTTP, MCP, SignalR, WCF, etc? Are logical operations like AWS SDK calls (REST over HTTP) RPC calls?

2. Which benefits does the abstraction bring?

   • Generic span conventions would cover almost everything there is in common between RPC systems - span name includes low-cardinality routes, span kind shows the side, server/client/network/error attributes cover generic networking concerns.

     • we still need a rpc.system (rpc.protocol.name) attribute
     • we still need some generic or protocol-specific attributes (gRPC status code)

   • Metrics - having a common call duration makes it easy to build a generic dashboard

     • such metric would have server/client/network, error.type attributes and a common operation name
     • but what does this metric show? All my remote (out-of-process) calls? No, it doesn't cover HTTP, sql low-level, etc

3. Streaming: should we do any effort to define generic conventions? can we?

   • context propagation over individual messages
   • correlated request/response events or spans
   • streaming-related metrics (number of messages, time-between-messages, etc)

One potential outcome of p1 and p2 that we might decide that we can't define RPC system and/or can't define enough of a useful abstractions effectively limiting the scope of the group to a few attributes that remain necessary.

[lmolkova]

/cc @JamesNK in case he's interested in sharing his experience instrumenting gRPC and SignalR

[danielgblanco]

I've approved pending comment on staffing.

[alolita]

Excited to see this work takeoff! Lgtm.