RPC: should we merge rpc.service and rpc.method into one fully qualified rpc.method.name #3196
Description
Some data points:
Dashboards/alerts
Is there a point in breaking things down by service name only?
I don't think it's the main use-case. Method within the same service could have quite different perf characteristics.
If we merge service/method, it should still be possible to have startwith / regex filters on attribute value for corner cases where it makes sense.
Consistency with other semantic conventions
RPC service + method is analogous to http.route which is fully qualified.
We deprecated function.namespace and function.name in favor of fully-qualified code.function.name
gRPC:
OTel Java gRPC instrumentation splits full method name into parts: https://github.com/open-telemetry/opentelemetry-java-instrumentation/blob/fcf9a9ad2b577b9bf7d6ad2c0cf8ec463684f4c8/instrumentation/grpc-1.6/library/src/main/java/io/opentelemetry/instrumentation/grpc/v1_6/GrpcRpcAttributesGetter.java#L27
Official gRPC tracing plugin doesn't set either of those attributes, but populates span name
There are no formal docs that would consider service and method to be independent and interesting without each other
Connect RPC
no otel instrumentations(?), it's based on and is compatible with gRPC
Dubbo:
method name and interface name are different https://github.com/open-telemetry/opentelemetry-java-instrumentation/blob/fcf9a9ad2b577b9bf7d6ad2c0cf8ec463684f4c8/instrumentation/apache-dubbo-2.7/library-autoconfigure/src/main/java/io/opentelemetry/instrumentation/apachedubbo/v2_7/DubboRpcAttributesGetter.java#L20
JSON-RPC
method is fully qualified, no notion of service https://www.jsonrpc.org/specification#request_object