Revisit messaging.destination|source.kind attributes requirement level #3249
Assignees
Labels
Comments
lmolkova
added
area:semantic-conventions
carlosalberto
pushed a commit
that referenced
this issue
Mar 21, 2023
… values (#3214) Fixes #3170, #3265, #3249 ## Changes ~~We currently allow `topic` or `queue` on `messaging.destination.kind`. While it's common in messaging world to have one or another, messaging semantic conventions can be applied to AMPQ communication (which does not have topic/queue terminology), [socket.io](https://socket.io/), and potentially other less traditional messaging use-cases.~~ It's unclear how `messaging.destination.kind` and `messaging.source.kind` could be used. The distinction between queue and topic is significant for messaging and distributed systems, but not for tracing. In either case, tracing backends should expect to process traces from 0+ messaging and 0+ messaging consumers. In either case, message consumers can be simultaneous or consequent and there could be many of them. The only known case (Solace) where it could be useful is when messaging system allows having queues and topic with the same name on the same broker, and it could be used to distinguish one from another. Based on messaging SIG discussion, the attributes are removed for the time being until we understand if and how they are useful. Depending on messaging system queues or topics behavior vary a lot and in future it would makes more sense to represent actual behavior with individual attributes such as: - auto-settlement (at-most-once or at least once guarantees) - settlement for individual messages or offsets - broadcast or unicast - etc
|
closed in #3214 |
carlosalberto
pushed a commit
to carlosalberto/opentelemetry-specification
that referenced
this issue
Oct 31, 2024
… values (open-telemetry#3214) Fixes open-telemetry#3170, open-telemetry#3265, open-telemetry#3249 ## Changes ~~We currently allow `topic` or `queue` on `messaging.destination.kind`. While it's common in messaging world to have one or another, messaging semantic conventions can be applied to AMPQ communication (which does not have topic/queue terminology), [socket.io](https://socket.io/), and potentially other less traditional messaging use-cases.~~ It's unclear how `messaging.destination.kind` and `messaging.source.kind` could be used. The distinction between queue and topic is significant for messaging and distributed systems, but not for tracing. In either case, tracing backends should expect to process traces from 0+ messaging and 0+ messaging consumers. In either case, message consumers can be simultaneous or consequent and there could be many of them. The only known case (Solace) where it could be useful is when messaging system allows having queues and topic with the same name on the same broker, and it could be used to distinguish one from another. Based on messaging SIG discussion, the attributes are removed for the time being until we understand if and how they are useful. Depending on messaging system queues or topics behavior vary a lot and in future it would makes more sense to represent actual behavior with individual attributes such as: - auto-settlement (at-most-once or at least once guarantees) - settlement for individual messages or offsets - broadcast or unicast - etc
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
messaging.destination|source.kindattributes are conditionally required and MUST be populated if operation is done against queue or topic.The distinction between queue and topic could be important, but it rarely is on a producer side.
From the observability backend side, queues and topics might look the same: topic can have one consumer and queue message can be processed multiple times by different consumers.
So requiring the presence of one or another does not seem that critical and backends should be able to provide a good experience without this information.
Also, some systems only support one of them (e.g. kafka only supports topics).
What did you expect to see?
I'd propose to set requirement level to
recommendedand suggest that system-specific extensions should specify default value. E.g. for kafkatopicis assumed, so no need to populate this redundant information.The text was updated successfully, but these errors were encountered: