Semantic conventions for RPC spans

Status: Experimental

This document defines how to describe remote procedure calls (also called “remote method invocations” / “RMI”) with spans.

Common remote procedure call conventions

A remote procedure calls is described by two separate spans, one on the client-side and one on the server-side.

For outgoing requests, the SpanKind MUST be set to CLIENT and for incoming requests to SERVER.

Remote procedure calls can only be represented with these semantic conventions, when the names of the called service and method are known and available.

Span name

The span name MUST be the full RPC method name formatted as:

$package.$service/$method

(where $service MUST NOT contain dots and $method MUST NOT contain slashes)

If there is no package name or if it is unknown, the $package. part (including the period) is omitted.

Examples of span names:

  • grpc.test.EchoService/Echo
  • com.example.ExampleRmiService/exampleMethod
  • MyCalcService.Calculator/Add reported by the server and MyServiceReference.ICalculator/Add reported by the client for .NET WCF calls
  • MyServiceWithNoPackage/theMethod

Common attributes

AttributeTypeDescriptionExamplesRequired
rpc.systemstringA string identifying the remoting system. See below for a list of well-known identifiers.grpcYes
rpc.servicestringThe full (logical) name of the service being called, including its package name, if applicable. [1]myservice.EchoServiceNo, but recommended
rpc.methodstringThe name of the (logical) method being called, must be equal to the $method part in the span name. [2]exampleMethodNo, but recommended
net.peer.ipstringRemote address of the peer (dotted decimal for IPv4 or RFC5952 for IPv6)127.0.0.1See below
net.peer.namestringRemote hostname or similar, see note below. [3]example.comSee below
net.peer.portintRemote port number.80; 8080; 443See below
net.transportstringTransport protocol used. See note below.ip_tcpSee below

[1]: This is the logical name of the service from the RPC interface perspective, which can be different from the name of any implementing class. The code.namespace attribute may be used to store the latter (despite the attribute name, it may include a class name; e.g., class with method actually executing the call on the server side, RPC client stub class on the client side).

[2]: This is the logical name of the method from the RPC interface perspective, which can be different from the name of any implementing method/function. The code.function attribute may be used to store the latter (e.g., method actually executing the call on the server side, RPC client stub method on the client side).

[3]: net.peer.name SHOULD NOT be set if capturing it would require an extra DNS lookup.

Additional attribute requirements: At least one of the following sets of attributes is required:

rpc.system has the following list of well-known values. If one of them applies, then the respective value MUST be used, otherwise a custom value MAY be used.

ValueDescription
grpcgRPC
java_rmiJava RMI
dotnet_wcf.NET WCF
apache_dubboApache Dubbo

For client-side spans net.peer.port is required if the connection is IP-based and the port is available (it describes the server port they are connecting to). For server-side spans net.peer.port is optional (it describes the port the client is connecting from). Furthermore, setting net.transport is required for non-IP connection like named pipe bindings.

Service name

On the server process receiving and handling the remote procedure call, the service name provided in rpc.service does not necessarily have to match the service.name resource attribute. One process can expose multiple RPC endpoints and thus have multiple RPC service names. From a deployment perspective, as expressed by the service.* resource attributes, it will be treated as one deployed service with one service.name. Likewise, on clients sending RPC requests to a server, the service name provided in rpc.service does not have to match the peer.service span attribute.

As an example, given a process deployed as QuoteService, this would be the name that goes into the service.name resource attribute which applies to the entire process. This process could expose two RPC endpoints, one called CurrencyQuotes (= rpc.service) with a method called getMeanRate (= rpc.method) and the other endpoint called StockQuotes (= rpc.service) with two methods getCurrentBid and getLastClose (= rpc.method). In this example, spans representing client request should have their peer.service attribute set to QuoteService as well to match the server’s service.name resource attribute. Generally, a user SHOULD NOT set peer.service to a fully qualified RPC service name.

Server attributes

AttributeTypeDescriptionExamplesRequired
net.host.ipstringLike net.peer.ip but for the host IP. Useful in case of a multi-IP host.192.168.0.1No
net.host.namestringLocal hostname or similar, see note below.localhostNo

Events

In the lifetime of an RPC stream, an event for each message sent/received on client and server spans SHOULD be created. In case of unary calls only one sent and one received message will be recorded for both client and server spans.

The event name MUST be message.

AttributeTypeDescriptionExamplesRequired
message.typestringWhether this is a received or sent message.SENTNo
message.idintMUST be calculated as two different counters starting from 1 one for sent messages and one for received message. [1]No
message.compressed_sizeintCompressed size of the message in bytes.No
message.uncompressed_sizeintUncompressed size of the message in bytes.No

[1]: This way we guarantee that the values will be consistent between different implementations.

message.type MUST be one of the following:

ValueDescription
SENTsent
RECEIVEDreceived

Distinction from HTTP spans

HTTP calls can generally be represented using just HTTP spans. If they address a particular remote service and method known to the caller, i.e., when it is a remote procedure call transported over HTTP, the rpc.* attributes might be added additionally on that span, or in a separate RPC span that is a parent of the transporting HTTP call. Note that method in this context is about the called remote procedure and not the HTTP verb (GET, POST, etc.).

gRPC

For remote procedure calls via gRPC, additional conventions are described in this section.

rpc.system MUST be set to "grpc".

gRPC Attributes

AttributeTypeDescriptionExamplesRequired
rpc.grpc.status_codeintThe numeric status code of the gRPC request.0Yes

rpc.grpc.status_code MUST be one of the following:

ValueDescription
0OK
1CANCELLED
2UNKNOWN
3INVALID_ARGUMENT
4DEADLINE_EXCEEDED
5NOT_FOUND
6ALREADY_EXISTS
7PERMISSION_DENIED
8RESOURCE_EXHAUSTED
9FAILED_PRECONDITION
10ABORTED
11OUT_OF_RANGE
12UNIMPLEMENTED
13INTERNAL
14UNAVAILABLE
15DATA_LOSS
16UNAUTHENTICATED

gRPC Status

The Span Status MUST be left unset for an OK gRPC status code, and set to Error for all others.

JSON RPC

Conventions specific to JSON RPC.

rpc.system MUST be set to "jsonrpc".

JSON RPC Attributes

AttributeTypeDescriptionExamplesRequired
rpc.jsonrpc.versionstringProtocol version as in jsonrpc property of request/response. Since JSON-RPC 1.0 does not specify this, the value can be omitted.2.0; 1.0If missing, it is assumed to be “1.0”.
rpc.jsonrpc.request_idstringid property of request or response. Since protocol allows id to be int, string, null or missing (for notifications), value is expected to be cast to string for simplicity. Use empty string in case of null value. Omit entirely if this is a notification.10; request-7; ``No
rpc.jsonrpc.error_codeinterror.code property of response if it is an error response.-32700; 100If missing, response is assumed to be successful.
rpc.jsonrpc.error_messagestringerror.message property of response if it is an error response.Parse error; User already existsNo
rpc.methodstringThe name of the (logical) method being called, must be equal to the $method part in the span name. [1]exampleMethodYes

[1]: This is always required for jsonrpc. See the note in the general RPC conventions for more information.