RPC Semantic Conventions diverge from HTTP Semantic conventions for similar metrics

[jsuereth]

Background

RPC semantic conventions were based on theOpenCensus gRPC specification. This was 13 motnhs ago when the OpenTelemetry Metrics API and SDK were still unstable and the View specification was not known. In particular, the OpenCensus specification (due to its stats API) was able to strike a balance where:

• Instrumentation recorded many attributes (more than any user would want)
• Views would refine these attributes to a reasonable cardinality for every day usage.

In the OpenTelemetry semantic conventions, we only have the instrumentation component, which is likely to lead to cardinality issues (as we store net.peer.ip on server-side latency metrics).

HTTP Semantic Conventions

Currently the HTTP semantic conventions strike a balance where effectively latency metrics (both sever + client) attempt to record the server identity as best as possible (via http.url, http.host_name, http.target, etc.)

Likely we should take an initial (conservative) approach for RPC metrics to prevent cardinality issues where specifying required Views (something common in OpenCensus) is not in OpenTelemetry (where views default based on instrument).

Proposal

We update the RPC semantic conventions so that:

• Client metrics use net.peer.name (or if unavailable net.peer.ip).
• Server metrics use host.name (or if unavailable host.ip).

[trask]

@jsuereth just checking that this would also require updating the RPC semantic conventions for span attributes as well (so that metric attributes continue to be a subset of span attributes)

[jsuereth]

@trask Sorry for long delays - IIRC the RPC semantic conventions for span included both end-points on both sides, so I THINK this should be ok, or am I missing something?

[trask]

hey @jsuereth, I don't see net.host.name or net.host.ip mentioned in the rpc tracing semantic conventions