Add Provider to the Event API#3878
Conversation
|
@martinkuba can you clarify what is the final intent? Do you plan to have an Events SDK that is configured separately from Logs SDK? Will Events SDK have its own pipeline of processors and exporters independently from Logs? Or is the plan to still rely on Logs SDK in some way? |
The intent is to remove the direct dependency on the Log API from the Event API. Introducing the provider is a first step, and as I understood the outcome of #3086. I agree that we need to specify how the API should be implemented as the next step. There were a few proposals in #3086. I think we do need to add a spec for Event SDK. My proposal would be to document that the default Event SDK should (or must) be implemented using the Log API. This would make it clear that, from OTel perspective, events are built on top of logs. And the Event SDK would not need to introduce any other concepts such as its own processors/exporters. I can add it to this PR, and I am also open to other suggestions. |
MrAlias
left a comment
MrAlias
left a comment
There was a problem hiding this comment.
There are structural specification issues with this PR that need to be addressed.
tedsuo
left a comment
tedsuo
left a comment
There was a problem hiding this comment.
Thank you for conforming to the spec and going with a Provider.
martinkuba
changed the title
breedx-splk
left a comment
breedx-splk
left a comment
There was a problem hiding this comment.
This seems like a good start to me.
Co-authored-by: jason plumb <[email protected]>
Fixes open-telemetry#3086 ## Changes The Event API will be used by instrumentations to generate events. Currently, the API takes an instance of a logger as a direct dependency. This means that instrumentations would need to be aware of the Log API, which is in conflict with the intent of using the Log API only to bridge logging frameworks. Furthermore, each instrumentation would need to construct an instance of an EventLogger, which is also inconsistent with the pattern of using a globally-registered provider. This PR adds the `EventLoggerProvider` class to the API, making it consistent with other APIs.
14 participants
Fixes #3086
Changes
The Event API will be used by instrumentations to generate events. Currently, the API takes an instance of a logger as a direct dependency. This means that instrumentations would need to be aware of the Log API, which is in conflict with the intent of using the Log API only to bridge logging frameworks. Furthermore, each instrumentation would need to construct an instance of an EventLogger, which is also inconsistent with the pattern of using a globally-registered provider.
This PR adds the
EventLoggerProviderclass to the API, making it consistent with other APIs.