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>
Josh Suereth