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#3260
(a first try at least)
## Changes
Splits `net.*` attributes into two sections, and adds this warning to
the attributes in the first section:
> **Warning** Most of the attributes in this section are in use by the
HTTP semantic conventions.
Once the HTTP semantic conventions are declared stable, changes to the
attributes in this section will only be allowed
if they do not cause breaking changes to HTTP semantic conventions.
Co-authored-by: Liudmila Molkova <limolkova@microsoft.com>
Co-authored-by: Carlos Alberto Cortez <calberto.cortez@gmail.com>
Co-authored-by: Tigran Najaryan <4194920+tigrannajaryan@users.noreply.github.com>
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
Fixes#3273
## Changes
Clarifies that if an HTTP client request is explicitly made to an IP
address, e.g. `http://x.x.x.x:8080`, then
`net.peer.name` SHOULD be the IP address `x.x.x.x`.
## Changes
As per the discussion on #3188, we determined it is better to move
rather than remove as this attribute is still important for some systems
despite it containing duplicated information.
This PR clarifies semantic conventions for HTTP retries and redirects and defines a span structure and linking as well as span attributes for retries. Changes were discussed recently at Instrumentation SIG meetings.
This change addresses a scenario which is in the scope for bringing the existing HTTP semantic conventions for tracing to an initial stable state, see related [otep #174](https://github.com/open-telemetry/oteps/pull/174).
Trask Stalnaker