Fixes#2015
## Changes
Based on discussions in the messaging workgroup and in issue #2015, this
PR proposes to remove `messaging.consumer.id`, and to replace both
`messaging.kafka.client_id` and `messaging.rocketmq.client_id` with a
generic `messaging.client_id`.
`messaging.consumer.id` is defined to always be set to the `client_id`
of the used messaging system, except for Kafka, where it was defined to
be a combination of `messaging.kafka.client_id` and
`messaging.kafka.consumer.group`, or just the latter if
`messaging.kafka.client_id` is not available. With this definition, the
semantics of `consumer.id` are different between messaging systems, and
even different for different Kafka scenarios.
The proposed `messaging.client_id` has consistent semantics ("an unique
client id, when it is available"), and can be used instead of
`messaging.consumer.id` in almost all cases.
In addition to have consistent semantics, this also simplifies the
semantic conventions, as instead of
`messaging.consumer.id`
`messaging.kafka.client_id`
`messaging.rocketmq.client_id`
there is now just:
`messaging.client_id`.
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
* Use MUST consistently instead of shall.
* Update specification/trace/semantic_conventions/messaging.md
Co-authored-by: Christian Neumüller <christian+github@neumueller.me>
Co-authored-by: Christian Neumüller <christian+github@neumueller.me>
* Adapt messaging semantic conventions to include the operation in the span name
* Specify that the operation name must match the respective attribute if the suggested span name format is used
* Update span names in examples
* Consolidate definition of operation names into a separate section
* Consolidate capitalization
* Reference Conversation ID definition
* Consolidate MD syntax
* Organize definitions
* Organize definitions
* Reference definitions
* Allow artificial destinations as span name if neither destination name nor conversation ID are suitable
* Do not use conversation IDs for span name
* Wording
Co-authored-by: Christian Neumüller <christian.neumueller@dynatrace.com>
* Fix typo
* Add more links and guidance on messaging.operation
* Fix changelog
Co-authored-by: Christian Neumüller <christian.neumueller@dynatrace.com>
I'm not sure what this should have to do with vendors, according to the examples, this would be the actual system names themselves. Otherwise the vendor for kafka would probably be "Apache", for example.
Johannes Tax