Add attributes defining the settlement intent for messaging

[pyohannes]

Relates to open-telemetry/semantic-conventions#1162

A settlement operation for messages can be triggered with different objectives, e. g.:

• Telling the intermediary that the message was processed successfully and shouldn't be processed by other consumers ("completed"?).
• Telling the intermediary that the message wasn't processed and should be delivered to other consumers for processing ("retry"?).
• Telling the intermediary that the message can't be processed and should be moved to a dead-letter queue ("abandon"?).
• Other possible scenarios.

This settlement intent is important for interpreting traces and should be visible as an attribute on settlement spans and possibly also in the span name for settlement spans.

[pyohannes]

As a first step we'll collect information about what "settlement intents" different messaging systems support.

cc @lmolkova @joaopgrassi

[michaelklishin]

As someone who works on a data service that supports five different protocols, I'm inclined to suggest something very generic:

• acknowledged (settled) with an optional label of a reasonable length
• negatively acknowledged (rejected) with an optional label

This way any messaging system or protocol would be able to provide some context (e.g. "rejected to be requeued" or "rejected to be discarded" or "rejected for dead lettering" or "rejected as a poison message").

Finding a common denominator between all the reasonably popular messaging and streaming protocols can be harder than it sounds.

Just my 2ç.

[stebet]

This feels to me like it should be handled very similar to http.response.status_code and set on deliver/receive spans. messaging.message.delivery_status = ack/nack?

[lmolkova]

Settlement is an individual operation (a network call) and should be expressed as a span. Receive/delivery are not guaranteed to last until settlement happens.

We have different terminology:

• RabbitMQ, Google PubSub, JMS: acknowledgment/nack

• AMQP 1.0 calls it settlement/disposition

• Kafka: commit

• Azure EventHubs: checkpoint

• SQS, Azure Queues: deletion, changing visibility

Option 1: we can come up with a generic terminology (that's helpful for one or two, but not other systems) Option 2:

• we'll let individual systems use their terminology.
• we'll ask them to name spans accordingly
• we'll add a generic attribute that's an extendable enum to describe the kind of operation.

there are no conclusion that need to be drawn on the tracing backend (that I can think of) that need values of this attribute to be known.

Users at the same time can easily understand what's going on in their system by looking at traces.