Refactor messaging attributes and specify per-message attributes

[lmolkova]

The final round of #2763

Changes

Messaging instrumentation SIG is working on spec changes and this change is one of the first steps to bring the consensus we reached in SIG to the spec.

This change introduces different namespace for different kinds of attributes:

• messaging.message for message properties (e.g. message id or payload size)
• messaging.destination for producers to describe publish operations (e.g. queue name)
• messaging.source for consumers to describe receive/deliver/process operations (e.g. queue name)
• messaging.batch for to describe batch properties (e.g. message count)
• messaging.consumer for to describe consumer properties (e.g. consumer id)

It also introduces guidance for specific systems on namespaces.

Here's the list of breaking changes (attribute renames):

• messaging.protocol: net.app.protocol.name
• messaging.protocol_version: net.app.protocol.version
• messaging.destination: messaging.destination.name
• messaging.temp_destination: messaging.destination.temporary
• messaging.destination_kind: messaging.destination.kind
• messaging.message_id: messaging.message.id
• messaging.conversation_id: messaging.message.conversation_id
• messaging.message_payload_size_bytes: messaging.message.payload_size_bytes
• messaging.message_payload_compressed_size_bytes: messaging.message.payload_compressed_size_bytes
• messaging.rabbitmq.routing_key: messaging.rabbitmq.message.routing_key
• messaging.kafka.message_key: messaging.kafka.message.key
• messaging.kafka.partition: messaging.kafka.message.partition
• messaging.kafka.tombstone: messaging.kafka.message.tombstone
• messaging.rocketmq.message_type: messaging.rocketmq.message.type
• messaging.rocketmq.message_tag: messaging.rocketmq.message.tag
• messaging.rocketmq.message_keys: messaging.rocketmq.message.keys

It also adds the messaging.batch.message_count attribute which intends to:

• denote a batching operation
• record number of messages sent/received/processed - since links can be dropped or there can be some other links not describing messages, link count is not a reliable indicator of batch size. Assuming a high-scale scenario, users might want to opt-out from per-message tracing, but then batch_size would still be useful

Related OTEP(s) #

• Stabilize messaging semantic conventions for tracing oteps#192
• Span structure for messaging scenarios oteps#220

[joaopgrassi]

Did a first pass on the yaml file, looking great! I will take a look at the rest later and submit a new review then.

[joaopgrassi]

I wanted to do another pass before the meeting, but only got around it today.

[pyohannes]

@lmolkova Can you please rebase? This should fix the failing markdown-link build job.