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 |
||
|---|---|---|
| .vscode | ||
| internal/tools | ||
| schemas | ||
| semantic_conventions | ||
| specification | ||
| .gitattributes | ||
| .gitignore | ||
| .markdown_link_check_config.json | ||
| .markdownlint.yaml | ||
| .nvmrc | ||
| .yamllint | ||
| LICENSE | ||
| Makefile | ||
| docfx.json | ||
| package.json | ||