Merge event's domain and name #3749
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
patrickhousley
changed the title
|
This PR was marked stale due to lack of activity. It will be closed in 7 days. |
3 tasks
jack-berg
reviewed
Nov 7, 2023
There was a problem hiding this comment.
Note that this change should be made in tandem with open-telemetry/semantic-conventions#473.
jsuereth
added
spec:logs
Co-authored-by: jack-berg <[email protected]>
carlosalberto
approved these changes
Nov 27, 2023
|
Now that #3749 has been merged, is this ready to go? |
tigrannajaryan
approved these changes
Nov 27, 2023
tigrannajaryan
changed the title
jack-berg
added a commit
that referenced
this pull request
Dec 1, 2023
In the 11/17/23 Event SIG we discussed and reached agreement on a number of things related to the Event API and how its parameters should manifest on resulting log record: - Some, but not all the parameters of [emit a logRecord](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/logs/bridge-api.md#emit-a-logrecord) should be exposed in the Event API - [LogRecord#SeverityText](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/logs/data-model.md#field-severitytext) should not be exposed as an Event API parameter. The SeverityText is used to record the original severity as recorded in the original log framework. The Event API is not for bridging log frameworks and this this field does not make sense to expose. The Event API implementation should leave SeverityText blank. - [LogRecord#ObservedTimestamp](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/logs/data-model.md#field-observedtimestamp) should not be as exposed as an Event API parameter. The semantics of ObservedTimestamp are defined as "Time when the event was observed by the collection system". For the Event API, the ObserveTimestamp is always when the Event is emitted. - The Event Payload, which conforms to the well defined schema for a particular `event.name` (event.domain is going away in #3749) should be an [AnyValue](https://github.com/open-telemetry/opentelemetry-proto/blob/ea449ae0e9b282f96ec12a09e796dbb3d390ed4f/opentelemetry/proto/common/v1/common.proto#L28) and recorded to the log record body. - We need some way to sample / filter Events based on the notion of priority / severity. We decided to use the [LogRecord#SeverityNumber](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/logs/data-model.md#field-severitynumber) field for this purpose rather than introducing a new concept. LogRecord#SeverityNumber is optional, and we want the equivalent Event API parameter to be optional as well. Therefore, I've indicated that Event API implementations should set a default SeverityNumber of 10. Without choosing a default, future sampling strategies that are based on SeverityNumber will filter away all Events which do not explicitly set a SeverityNumber, which is not desirable. Note that there is going to be a corresponding PR in `semantic-conventions` which says that Events put their payload in the LogRecord#Body field. --------- Co-authored-by: Carlos Alberto Cortez <[email protected]> Co-authored-by: Armin Ruech <[email protected]>
1 task
carlosalberto
pushed a commit
to carlosalberto/opentelemetry-specification
that referenced
this pull request
Oct 31, 2024
Fixes open-telemetry#2994 ## Changes Merging the `domain` and `name` fields for events and modifying language to refer to the first part of the name as `namespace`
carlosalberto
added a commit
to carlosalberto/opentelemetry-specification
that referenced
this pull request
Oct 31, 2024
…3772) In the 11/17/23 Event SIG we discussed and reached agreement on a number of things related to the Event API and how its parameters should manifest on resulting log record: - Some, but not all the parameters of [emit a logRecord](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/logs/bridge-api.md#emit-a-logrecord) should be exposed in the Event API - [LogRecord#SeverityText](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/logs/data-model.md#field-severitytext) should not be exposed as an Event API parameter. The SeverityText is used to record the original severity as recorded in the original log framework. The Event API is not for bridging log frameworks and this this field does not make sense to expose. The Event API implementation should leave SeverityText blank. - [LogRecord#ObservedTimestamp](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/logs/data-model.md#field-observedtimestamp) should not be as exposed as an Event API parameter. The semantics of ObservedTimestamp are defined as "Time when the event was observed by the collection system". For the Event API, the ObserveTimestamp is always when the Event is emitted. - The Event Payload, which conforms to the well defined schema for a particular `event.name` (event.domain is going away in open-telemetry#3749) should be an [AnyValue](https://github.com/open-telemetry/opentelemetry-proto/blob/ea449ae0e9b282f96ec12a09e796dbb3d390ed4f/opentelemetry/proto/common/v1/common.proto#L28) and recorded to the log record body. - We need some way to sample / filter Events based on the notion of priority / severity. We decided to use the [LogRecord#SeverityNumber](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/logs/data-model.md#field-severitynumber) field for this purpose rather than introducing a new concept. LogRecord#SeverityNumber is optional, and we want the equivalent Event API parameter to be optional as well. Therefore, I've indicated that Event API implementations should set a default SeverityNumber of 10. Without choosing a default, future sampling strategies that are based on SeverityNumber will filter away all Events which do not explicitly set a SeverityNumber, which is not desirable. Note that there is going to be a corresponding PR in `semantic-conventions` which says that Events put their payload in the LogRecord#Body field. --------- Co-authored-by: Carlos Alberto Cortez <[email protected]> Co-authored-by: Armin Ruech <[email protected]>
carlosalberto
pushed a commit
to carlosalberto/opentelemetry-specification
that referenced
this pull request
Oct 31, 2024
"merge conflict" between open-telemetry#3749 and open-telemetry#3772.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #2994
Changes
Merging the
domainandnamefields for events and modifying language to refer to the first part of the name asnamespace