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#3266
## Changes
Kubernetes doesn't have a formal way to identify a cluster, but a
pseudo-id can be derived by taking the `uid` of the `kube-system`
namespace. This PR adds a convention for `k8s.cluster.uid` to be set to
the `kube-system` namespace uid.
Fixes#3132, #3133
## Changes
In semantic conventions for hardware metrics:
* Updated network adapter description
* Changed `type` to `hw.error.type` for the `hw.errors` metric
These places were removed when #3188 in its original form removed
faas.id without replacement and weren't added back after changing it to
introduce cloud.resource_id instead.
Editorial change, no CHANGELOG or issue.
Supersedes #3350
Clarifies the parameters for emitting a log record.
Context was particularly confusing. Context is not a property of the
`LogRecord` data model. Cleans up section of bridge API spec that seems
to suggest that Context is a field of `LogRecord`. Also, clarifies that
Context can be associated with an emitted LogRecord. We have similar
language in the trace API that leaves room for languages to achieve this
in an idiomatic way. See
d25734a47e/specification/trace/api.md?plain=1#L365-L370
---------
Co-authored-by: Reiley Yang <reyang@microsoft.com>
Fixes#597
## Changes
- Add a section for "generic attributes" to the log semconv
- Add an attribute `log_record.id` making use of ULID as discussed in
#597
Some additional notes:
- I kept the PR small, so I left out some other potential attributes,
e.g. something for pre-existing ID (like windows event logs) or for
storing the used logging/eventing system or even something like a
"signature" that might be worth discussing, etc.
- I followed the structure of "generic attributes" from the spans
semconv
- I took some of the existing wording from #597 &
https://github.com/open-telemetry/oteps/pull/97#discussion_r421865344 to
describe the field
---------
Signed-off-by: svrnm <neumanns@cisco.com>
Co-authored-by: Joao Grassi <joao@joaograssi.com>
Co-authored-by: jack-berg <34418638+jack-berg@users.noreply.github.com>
Co-authored-by: Tigran Najaryan <4194920+tigrannajaryan@users.noreply.github.com>
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
## Changes
Add `toc` for metric http semconv markdown file
Signed-off-by: Peter Liu <lpfvip2008@gmail.com>
Co-authored-by: Reiley Yang <reyang@microsoft.com>
Josh Suereth