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:

AttributeTypeDescriptionExamplesRequirement Level
messaging.kafka.consumer.groupstringName of the Kafka Consumer Group that is handling the message. Only applies to consumers, not producers.my-groupRecommended
messaging.kafka.destination.partitionintPartition the message is sent to.2Recommended
messaging.kafka.message.keystringMessage 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. [1]myKeyRecommended
messaging.kafka.message.offsetintThe offset of a record in the corresponding Kafka partition.42Recommended
messaging.kafka.message.tombstonebooleanA boolean that is true if the message is a tombstone.Conditionally Required: [2]

[1]: 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.

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

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 |
Field or AttributeSpan Prod1Span Rcv1Span Proc1Span Prod2Span Rcv2
Span name"T1 publish""T1 receive""T1 process""T2 publish""T2 receive"
ParentSpan Prod1Span Rcv1Span Rcv1Span Prod2
Links
SpanKindPRODUCERCONSUMERCONSUMERPRODUCERCONSUMER
StatusOkOkOkOkOk
peer.service"myKafka""myKafka"
service.name"myConsumer1""myConsumer1""myConsumer2"
messaging.system"kafka""kafka""kafka""kafka""kafka"
messaging.destination.name"T1""T1""T1""T2""T2"
messaging.operation"process""receive"
messaging.client_id"5""5""5""8"
messaging.kafka.message.key"myKey""myKey""myKey""anotherKey""anotherKey"
messaging.kafka.consumer.group"my-group""my-group""another-group"
messaging.kafka.destination.partition"1""1""1""3""3"
messaging.kafka.message.offset"12""12""12""32""32"