Clarification on what an Event is, and what the event.domain and event.name attributes represent #2848
Conversation
This came up in open-telemetry/opentelemetry-collector-contrib#14474 where it was highlighted that just `name` is not sufficient to provide for uniqueness of a Kubernetes Event. The attribute `event.domain` is only meant to be a logical separation across different event systems, so it allows for similar looking names in different domains but with a completely different purpose. However, within each domain we don't have to have any uniqueness constraints on the `name` and leave it to whatever is idiomatic to the particular event system the domain represents.
scheler
changed the title
scheler
changed the title
|
This PR was marked stale due to lack of activity. It will be closed in 7 days. |
|
@open-telemetry/specs-logs-approvers please review. |
|
@scheler please fix the build. |
|
@tigrannajaryan the build is fixed now. Regarding the 2 attributes being on the LogAttributes in the Event definition, it's already mentioned that way in the spec, see here. Given that we are moving in this direction with the proposal for Events API layered on top of Logger API #2917, maybe it's ok to keep this language as is. |
I would still prefer to remove it from this PR until we agree that event.domain moves from the Scope to LogRecord and update the spec everywhere. We don't have such an agreement. |
@tigrannajaryan made the change. Updated with the description from https://github.com/open-telemetry/opentelemetry-specification/pull/2863/files |
|
@open-telemetry/specs-logs-approvers please review. |
|
As agreed in the Log SIG we are merging this as is. A separate PR will be created to move event.domain to the LogRecord. @scheler will you do that? |
Changes
This PR provides clarification on what an Event is, and what the
event.domainandevent.nameattributes represent.This PR also removes the text around
event.namebeing unique in a domain, as it is wrongly worded and is not required. This came up in open-telemetry/opentelemetry-collector-contrib#14474. The attributeevent.domainis meant to provide a logical separation across different event systems, so it allows for similar looking names in different domains but with a completely different purpose. However, within each domain we don't have to have any uniqueness constraints onevent.nameand leave it to whatever is idiomatic to the particular event system the domain represents.For non-trivial changes, follow the change proposal
process and link to the related issue(s)
and/or OTEP(s), update the
CHANGELOG.md, and also be sure to updatespec-compliance-matrix.mdif necessary.Related issues #
Related OTEP(s) #