Semantic Conventions for Kafka

Status: Experimental

The Semantic Conventions for Apache Kafka extend and override the Messaging Semantic Conventions that describe common messaging operations attributes in addition to the Semantic Conventions described on this page.

messaging.system MUST be set to "kafka".

Span attributes

For Apache Kafka, the following additional attributes are defined:

Attribute	Type	Description	Examples	Requirement Level	Stability
messaging.kafka.message.tombstone	boolean	A boolean that is true if the message is a tombstone.		Conditionally Required [1]
messaging.destination.partition.id	string	String representation of the partition id the message (or batch) is sent to or received from.	1	Recommended
messaging.kafka.consumer.group	string	Name of the Kafka Consumer Group that is handling the message. Only applies to consumers, not producers.	my-group	Recommended
messaging.kafka.message.key	string	Message keys in Kafka are used for grouping alike messages to ensure they’re processed on the same partition. They differ from messaging.message.id in that they’re not unique. If the key is null, the attribute MUST NOT be set. [2]	myKey	Recommended
messaging.kafka.message.offset	int	The offset of a record in the corresponding Kafka partition.	42	Recommended

[1]: If value is true. When missing, the value is assumed to be false.

[2]: If the key type is not string, it’s string representation has to be supplied for the attribute. If the key has no unambiguous, canonical string form, don’t include its value.

For Apache Kafka producers, peer.service SHOULD be set to the name of the broker or service the message will be sent to. The service.name of a Consumer’s Resource SHOULD match the peer.service of the Producer, when the message is directly passed to another service. If an intermediary broker is present, service.name and peer.service will not be the same.

messaging.client_id SHOULD be set to the client-id of consumers, or to the client.id property of producers.

Examples

Apache Kafka with Quarkus or Spring Boot Example

Given is a process P, that publishes a message to a topic T1 on Apache Kafka. One process, CA, receives the message and publishes a new message to a topic T2 that is then received and processed by CB.

Frameworks such as Quarkus and Spring Boot separate processing of a received message from producing subsequent messages out. For this reason, receiving (Span Rcv1) is the parent of both processing (Span Proc1) and producing a new message (Span Prod2). The span representing message receiving (Span Rcv1) should not set messaging.operation to receive, as it does not only receive the message but also converts the input message to something suitable for the processing operation to consume and creates the output message from the result of processing.

Process P:  | Span Prod1 |
--
Process CA:              | Span Rcv1 |
                                | Span Proc1 |
                                  | Span Prod2 |
--
Process CB:                           | Span Rcv2 |