Add event processors to the Event SDK

[tedsuo]

This PR changes the EventProvider SDK constructor to take a list of EventProcessors, to match the way that the tracing and logging providers are configured.

The three types of event processors included in this PR cover the features requested durning the August 23rd meeting of the Event SIG.

The log processor and the span event processor can be composed together:

# Configure the event provider to record each event
# as both a LogRecord and a SpanEvent.
event_provider:
  processors:
    - log
    - span_events

Alternatively, a language-specific logging processor could be used to send events directly to another logging system:

# Configure the event provider send the events to
# a language-specific logging system.
event_provider:
  processors:
    - python_logger

Log bridge processor

This processor passes the event's LogRecord to the Log SDK.

Span event processor

This processor converts the event's LogRecord into a SpanEvent on the current span. If there is no current span, this is a no-op.

If the event's LogRecord has a body, it MUST be json-serialized to a SpanEvent
attribute named event.body.

Event processors for language-specific logging libraries

These processors turn the Event API into "sugar" for popular logging libraries by sending the events directly to that 3rd-party logger's API. This is helpful for users who want to ensure that the LogRecords created via the Event API are processed in the same pipeline as their application logs.

For example, in Python the default logging library is very popular. A PythonLoggerProcessor would allow users to turn events directly into python logs. Any further processing is managed through the python logging system, including sending it to the LogBridge API if they want to record their logs in Otel.

[cijothomas]

For logs,traces, a different approach is used where the next processor(s) are always called. Filtering there would require one to make wrapping processors.

I think this approach makes it easier to do filtering. Wondering if there were some discussions comparing the approaches for their pros/cons? The PR description only says "list of EventProcessors, to match the way that the tracing and logging providers are configured."

[jack-berg]

Is there a prototype for this?

[trask]

maybe this should be a log processor instead, so that it will apply also to events emitted directly via language-specific loggers?

[jack-berg]

The TC discussed and think we should agree / resolve open-telemetry/oteps#265 before proceeding with this, since the outcome may change the strategy of the spec and cause churn.

[tedsuo]

Makes sense, I've marked this PR as draft for the time being.

[github-actions]

This PR was marked stale due to lack of activity. It will be closed in 7 days.

[github-actions]

Closed as inactive. Feel free to reopen if this PR is still being worked on.