-
Notifications
You must be signed in to change notification settings - Fork 889
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
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.
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 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
@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? |
…t.name attributes represent (open-telemetry#2848) * Remove language around uniqueness of event names within a domain 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.
Changes
This PR provides clarification on what an Event is, and what the
event.domain
andevent.name
attributes represent.This PR also removes the text around
event.name
being 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.domain
is 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.name
and 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.md
if necessary.Related issues #
Related OTEP(s) #