Messaging: rename `settle` operation to `acknowledge|ack`

[lmolkova]

From https://github.com/open-telemetry/semantic-conventions/pull/634#discussion_r1503109882

Acknowledgement/ack is a common terminology used in different systems:

• rabbitmq (ack, nack)
• google pubsub (ack, nack)
• pulsar (ack, nack, individual or batch)
• jms (no nack, just ack, individual or batch)
• NATS (ack, nack, term, individual or batch)

AMQP uses settlement term, but it's a wider one and applies on the protocol level rather than logical message settlement

Per-offset systems (like Kafka, Azure EventHubs) use different terminology (commit or checkpoint), however their JMS connectors use acknowledge for those as well. Pulsar and NATS also support ack all mode where they allow to ack all messages before N.

Proposal:

I'd like to entertain the idea of renaming settle to ack and add an messaging.message.ack_type (ack_status|kind|etc) to generalize ack type which will have system-specific set of values.

Note: ack_mode would not work since acknowledgement mode is frequently means a config option on the topic/client (ack on delivery vs ack each message explicitly vs ack batch)

Pros:

• more popular terminology for per-message settlement systems

Concens/cons:

• messaging.operation=ack may create a false impression that it already indicates a positive acknowledgement

[lmolkova]

Somehow it feels that messaging.operation=acknowledgement and messaging.message.acknowledgement_type would do not create false impression

[pyohannes]

Some thoughts (in favor or keeping the existing terminology):

• One of the benefits of the "settlement" term is that it's very generic: while it's not used by any particular messaging system, it covers and can substitute the common terms "acknowledge", "commit", or "checkpoint".
• "Acknowledge" is usually associated with per-message settlement (with the exception of JMS, which you noted).
• All systems you listed (except JMS) have both ack and nack. I imagine it would be confusing for those systems to have the operation name ack also for nack operations. It is true that this can be tackled by adding an additional ack_type attribute. However, I see all of those systems adding overrides for our default span name pattern, as <queue name> ack might be misleading for nack cases.

[lmolkova]

I agree with your reasoning @pyohannes

My worry though that having terminology that works for no-one prevents some systems from adopting the spec.

Essentially, if Google PubSub would report ack and nack as operation names, it would mean that settle does not work.

As a way around it, I'm suggesting a solution here https://github.com/open-telemetry/semantic-conventions/pull/634#discussion_r1503224386 that allows to keep broker-specific terminology and also use standard operation names:

span name = "topic_name ack"
messaging.operation = "settle"
messaging.{?}.message.settlement_status = "ack"

With generic messaging.message.settlement_status = ack|nack or system-specific ~messaging.gcp_pubsub.message.ack_status it would also bring broker-specific flavor to metrics.

If this solution would not work for GCP PubSub, I'd like to revisit this and put more thought into settlement.

[pyohannes]

As a way around it, I'm suggesting a solution here https://github.com/open-telemetry/semantic-conventions/pull/634#discussion_r1503224386 that allows to keep broker-specific terminology and also use standard operation names:

This approach makes sense to me, there are benefits of limit messaging.operation to a smaller set of clearly defined mutually exclusive values.

Related to this we also have https://github.com/open-telemetry/semantic-conventions/issues/431, and we agreed to discuss this post-stability. This works for spans, as we could exclude all settlement-related attributes from stability, however, we can't apply the same approach to metrics: if we want settlement-related attributes on metrics and we continue to follow our approach of not allowing adding attributes to stable metrics, we'd need to clarify all open questions before stability.

[lmolkova]

settlement metrics would also come post-stability, so it should not be a blocker either way.

[lmolkova]

closing, based on the discussion above