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. |
martinkuba
changed the title
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.
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.