Semantic conventions for Apache Dubbo

Status: Release Candidate, unless otherwise specified

The Semantic Conventions for Apache Dubbo extend and override the RPC Semantic Conventions.

Spans

Client

Status: Release Candidate

This span represents an outgoing Remote Procedure Call (RPC).

rpc.system.name MUST be set to "dubbo" and SHOULD be provided at span creation time.

Span name: refer to the Span Name section.

Span kind MUST be CLIENT.

Span status Refer to the Recording Errors document for details on how to record span status. See also rpc.response.status_code attribute for the details on which values classify as errors.

Attributes:

KeyStabilityRequirement LevelValue TypeDescriptionExample Values
rpc.methodRelease CandidateRequiredstringThe fully-qualified logical name of the method from the RPC interface perspective. [1]com.example.ExampleService/exampleMethod; EchoService/Echo; _OTHER
rpc.response.status_codeRelease CandidateRequiredstringThe string representation of the Dubbo response status code returned by the server or generated by the client. [2]OK; DEADLINE_EXCEEDED; SERVER_ERROR
error.typeStableConditionally Required If and only if the operation failed.stringDescribes a class of error the operation ended with. [3]DEADLINE_EXCEEDED; java.net.UnknownHostException; -32602
rpc.method_originalRelease CandidateConditionally Required If and only if it’s different than rpc.method.stringThe original name of the method used by the client.com.myservice.EchoService/catchAll; com.myservice.EchoService/unknownMethod; InvalidMethod
server.addressStableConditionally Required If available.stringA string identifying a group of RPC server instances request is sent to. [4]192.168.1.100; api.example.com
server.portStableConditionally Required [5]intServer port number. [6]20880; 50051
network.peer.addressStableRecommendedstringPeer address of the network connection - IP address or Unix domain socket name. [7]10.1.2.80; /tmp/my.sock
network.peer.portStableRecommended If network.peer.address is set.intPeer port number of the network connection.65123
rpc.request.metadata.<key>DevelopmentOpt-Instring[]RPC request metadata, <key> being the normalized RPC metadata key (lowercase), the value being the metadata values. [8]["1.2.3.4", "1.2.3.5"]
rpc.response.metadata.<key>DevelopmentOpt-Instring[]RPC response metadata, <key> being the normalized RPC metadata key (lowercase), the value being the metadata values. [9]["attribute_value"]

[1] rpc.method: The method name MAY have unbounded cardinality in edge or error cases.

Some RPC frameworks or libraries provide a fixed set of recognized methods for client stubs and server implementations. Instrumentations for such frameworks MUST set this attribute to the original method name only when the method is recognized by the framework or library.

When the method is not recognized, for example, when the server receives a request for a method that is not predefined on the server, or when instrumentation is not able to reliably detect if the method is predefined, the attribute MUST be set to _OTHER. In such cases, tracing instrumentations MUST also set rpc.method_original attribute to the original method value.

If the RPC instrumentation could end up converting valid RPC methods to _OTHER, then it SHOULD provide a way to configure the list of recognized RPC methods.

The rpc.method can be different from the name of any implementing method/function. The code.function.name attribute may be used to record the fully-qualified method actually executing the call on the server side, or the RPC client stub method on the client side.

[2] rpc.response.status_code: All status codes except OK SHOULD be considered errors.

Status codes reference:

[3] error.type: If the RPC fails with an error before status code is returned, error.type SHOULD be set to the exception type (its fully-qualified class name, if applicable) or a component-specific, low cardinality error identifier.

If a response status code is returned and status indicates an error, error.type SHOULD be set to that status code. Check system-specific conventions for the details on which values of rpc.response.status_code are considered errors.

The error.type value SHOULD be predictable and SHOULD have low cardinality. Instrumentations SHOULD document the list of errors they report.

If the request has completed successfully, instrumentations SHOULD NOT set error.type.

[4] server.address: Instrumentations SHOULD populate server.address (along with server.port) based on the configuration used when creating the Dubbo client and SHOULD NOT use actual network-level connection information for this purpose to ensure low cardinality.

The Dubbo registry address SHOULD NOT be used as server.address. Instead, use the address of the actual server being called.

  • Given the target URL dubbo://192.168.1.100:20880/com.example.DemoService, expected attributes:
    • server.address: "192.168.1.100"
    • server.port: 20880
  • Given the target URL tri://api.example.com:50051/com.example.GreeterService, expected attributes:
    • server.address: "api.example.com"
    • server.port: 50051
  • Given the target URL tri://api.example.com/com.example.GreeterService (port not specified), expected attributes:
    • server.address: "api.example.com"
    • server.port: not set

When the address is an IP address, instrumentations SHOULD NOT do a reverse proxy lookup to obtain a DNS name and SHOULD set server.address to the IP address provided.

[5] server.port: if server.address is set and if the port is supported by the network transport used for communication.

[6] server.port: See the server.address for details on parsing the target string.

[7] network.peer.address: If a RPC involved multiple network calls (for example retries), the last contacted address SHOULD be used.

[8] rpc.request.metadata.<key>: Instrumentations SHOULD require an explicit configuration of which metadata values are to be captured. Including all request metadata values can be a security risk - explicit configuration helps avoid leaking sensitive information.

For example, a property my-custom-key with value ["1.2.3.4", "1.2.3.5"] SHOULD be recorded as rpc.request.metadata.my-custom-key attribute with value ["1.2.3.4", "1.2.3.5"]

[9] rpc.response.metadata.<key>: Instrumentations SHOULD require an explicit configuration of which metadata values are to be captured. Including all response metadata values can be a security risk - explicit configuration helps avoid leaking sensitive information.

For example, a property my-custom-key with value ["attribute_value"] SHOULD be recorded as the rpc.response.metadata.my-custom-key attribute with value ["attribute_value"]

The following attributes can be important for making sampling decisions and SHOULD be provided at span creation time (if provided at all):


error.type 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.

ValueDescriptionStability
_OTHERA fallback error value to be used when the instrumentation doesn’t define a custom value.Stable

Server

Status: Release Candidate

This span represents an incoming Remote Procedure Call (RPC).

rpc.system.name MUST be set to "dubbo" and SHOULD be provided at span creation time.

Span name: refer to the Span Name section.

Span kind MUST be SERVER.

Span status Refer to the Recording Errors document for details on how to record span status. See also rpc.response.status_code attribute for the details on which values classify as errors.

Attributes:

KeyStabilityRequirement LevelValue TypeDescriptionExample Values
rpc.response.status_codeRelease CandidateRequiredstringThe string representation of the Dubbo response status code returned by the server. [1]OK; SERVER_ERROR; SERVER_THREADPOOL_EXHAUSTED_ERROR
error.typeStableConditionally Required If and only if the operation failed.stringDescribes a class of error the operation ended with. [2]DEADLINE_EXCEEDED; java.net.UnknownHostException; -32602
rpc.methodRelease CandidateConditionally Required if available.stringThe fully-qualified logical name of the method from the RPC interface perspective. [3]com.example.ExampleService/exampleMethod; EchoService/Echo; _OTHER
rpc.method_originalRelease CandidateConditionally Required If and only if it’s different than rpc.method.stringThe original name of the method used by the client.com.myservice.EchoService/catchAll; com.myservice.EchoService/unknownMethod; InvalidMethod
server.addressStableConditionally Required If available.stringA string identifying a group of RPC server instances request is sent to. [4]example.com; 10.1.2.80; /tmp/my.sock
server.portStableConditionally Required [5]intServer port number. [6]80; 8080; 443
client.addressStableRecommendedstringClient address - domain name if available without reverse DNS lookup; otherwise, IP address or Unix domain socket name. [7]client.example.com; 10.1.2.80; /tmp/my.sock
client.portStableRecommendedintClient port number. [8]65123
network.peer.addressStableRecommendedstringPeer address of the network connection - IP address or Unix domain socket name. [9]10.1.2.80; /tmp/my.sock
network.peer.portStableRecommended If network.peer.address is set.intPeer port number of the network connection.65123
rpc.request.metadata.<key>DevelopmentOpt-Instring[]RPC request metadata, <key> being the normalized RPC metadata key (lowercase), the value being the metadata values. [10]["1.2.3.4", "1.2.3.5"]
rpc.response.metadata.<key>DevelopmentOpt-Instring[]RPC response metadata, <key> being the normalized RPC metadata key (lowercase), the value being the metadata values. [11]["attribute_value"]

[1] rpc.response.status_code: For Dubbo2, the following status codes SHOULD be considered errors:

  • SERVER_ERROR
  • SERVER_THREADPOOL_EXHAUSTED_ERROR
  • SERVER_TIMEOUT
  • SERVICE_ERROR

For Dubbo3 Triple protocol, the following status codes SHOULD be considered errors:

  • DATA_LOSS
  • DEADLINE_EXCEEDED
  • INTERNAL
  • UNAVAILABLE
  • UNIMPLEMENTED
  • UNKNOWN

Status codes reference:

[2] error.type: If the RPC fails with an error before status code is returned, error.type SHOULD be set to the exception type (its fully-qualified class name, if applicable) or a component-specific, low cardinality error identifier.

If a response status code is returned and status indicates an error, error.type SHOULD be set to that status code. Check system-specific conventions for the details on which values of rpc.response.status_code are considered errors.

The error.type value SHOULD be predictable and SHOULD have low cardinality. Instrumentations SHOULD document the list of errors they report.

If the request has completed successfully, instrumentations SHOULD NOT set error.type.

[3] rpc.method: The method name MAY have unbounded cardinality in edge or error cases.

Some RPC frameworks or libraries provide a fixed set of recognized methods for client stubs and server implementations. Instrumentations for such frameworks MUST set this attribute to the original method name only when the method is recognized by the framework or library.

When the method is not recognized, for example, when the server receives a request for a method that is not predefined on the server, or when instrumentation is not able to reliably detect if the method is predefined, the attribute MUST be set to _OTHER. In such cases, tracing instrumentations MUST also set rpc.method_original attribute to the original method value.

If the RPC instrumentation could end up converting valid RPC methods to _OTHER, then it SHOULD provide a way to configure the list of recognized RPC methods.

The rpc.method can be different from the name of any implementing method/function. The code.function.name attribute may be used to record the fully-qualified method actually executing the call on the server side, or the RPC client stub method on the client side.

[4] server.address: May contain a DNS name, an endpoint and path in the service registry, local socket name or an IP address. Semantic conventions for individual RPC systems SHOULD document how to populate this attribute. When address is an IP address, instrumentations SHOULD NOT do a reverse DNS lookup to obtain a DNS name and SHOULD set server.address to the provided IP address.

[5] server.port: if server.address is set and if the port is supported by the network transport used for communication.

[6] server.port: When observed from the client side, and when communicating through an intermediary, server.port SHOULD represent the server port behind any intermediaries, for example proxies, if it’s available.

[7] client.address: When observed from the server side, and when communicating through an intermediary, client.address SHOULD represent the client address behind any intermediaries, for example proxies, if it’s available.

[8] client.port: When observed from the server side, and when communicating through an intermediary, client.port SHOULD represent the client port behind any intermediaries, for example proxies, if it’s available.

[9] network.peer.address: If a RPC involved multiple network calls (for example retries), the last contacted address SHOULD be used.

[10] rpc.request.metadata.<key>: Instrumentations SHOULD require an explicit configuration of which metadata values are to be captured. Including all request metadata values can be a security risk - explicit configuration helps avoid leaking sensitive information.

For example, a property my-custom-key with value ["1.2.3.4", "1.2.3.5"] SHOULD be recorded as rpc.request.metadata.my-custom-key attribute with value ["1.2.3.4", "1.2.3.5"]

[11] rpc.response.metadata.<key>: Instrumentations SHOULD require an explicit configuration of which metadata values are to be captured. Including all response metadata values can be a security risk - explicit configuration helps avoid leaking sensitive information.

For example, a property my-custom-key with value ["attribute_value"] SHOULD be recorded as the rpc.response.metadata.my-custom-key attribute with value ["attribute_value"]

The following attributes can be important for making sampling decisions and SHOULD be provided at span creation time (if provided at all):


error.type 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.

ValueDescriptionStability
_OTHERA fallback error value to be used when the instrumentation doesn’t define a custom value.Stable

Metrics

Dubbo instrumentations SHOULD collect metrics according to the general Semantic Conventions for RPC Metrics.

rpc.system.name MUST be set to "dubbo".