-
Notifications
You must be signed in to change notification settings - Fork 893
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
Align log sdk naming with api #2768
Align log sdk naming with api #2768
Conversation
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.
Thanks for working on this!
887d74e
to
9b7fb20
Compare
I will keep this open for a bit to allow time to review the last changes. |
Events require the `event.domain` attribute. The API MUST not allow creating an | ||
Event if the Logger instance doesn't have `event.domain` scope attribute. |
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.
Events require the
event.domain
attribute. The API MUST not allow creating an
Event if the Logger instance doesn't haveevent.domain
scope attribute.
Can you clarify for me what to do in the case of missing event.domain
to the EmitEvent call? Is it a no-op or a throw? Do I generate a log to alert the user?
Also, is it valid if name
is passed as null
or empty?
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.
@CodeBlanch both domain
and name
are required for an Event
and also cannot be empty or null. So EmitEvent call should throw an error if event.domain
attribute is missing or is null/empty. Same with name
- if it is null or empty, EmitEvent should return failure or throw an error.
Resolves open-telemetry#2752. This aligns log SDK and API concepts which have diverged after the merged of open-telemetry#2676. This PR brings alignment to the log API and SDK, and in brings the log signal into alignment with tracing and metrics where there is conceptual overlap. There shouldn't be any new concepts introduced here. - Rename `../logs/logging-library-sdk.md` to `../logs/sdk.md` - Remove wording from SDK that implies that an API doesn't exist, like [this](https://github.com/open-telemetry/opentelemetry-specification/blame/main/specification/logs/logging-library-sdk.md#L60-L62). - Move [How to Create Log4j Style Appender](https://github.com/open-telemetry/opentelemetry-specification/blame/main/specification/logs/logging-library-sdk.md#L219) to `api.md` since it describes an API use case. - Move [Implicit / Explicit Context Injection](https://github.com/open-telemetry/opentelemetry-specification/blame/main/specification/logs/logging-library-sdk.md#L270-L288) sections to `api.md` since they describe API level considerations. - Rename Logger [create](https://github.com/open-telemetry/opentelemetry-specification/blame/main/specification/logs/api.md#L133) method to be emit, to align with SDK concept of `LogRecordProcessor#onEmit(..)`. - Rename `LogProcessor`, `LogExporter` to `LogRecordProcessor`, `LogRecordExporter`. - Fill in various SDK level TODOs related to shutdown and flushing. The language from these was taken directly from the metrics / tracing SDK - no new concepts were introduced.
Resolves #2752.
This aligns log SDK and API concepts which have diverged after the merged of #2676. This PR brings alignment to the log API and SDK, and in brings the log signal into alignment with tracing and metrics where there is conceptual overlap. There shouldn't be any new concepts introduced here.
../logs/logging-library-sdk.md
to../logs/sdk.md
api.md
since it describes an API use case.api.md
since they describe API level considerations.LogRecordProcessor#onEmit(..)
.LogProcessor
,LogExporter
toLogRecordProcessor
,LogRecordExporter
.