Enable by default or support ENV based configuration of EventLoggerProvider

[codefromthecrypt]

Is your feature request related to a problem?

Right now, to use instrumentation that relies on EventLogger, you cannot do a full zero-code approach. You have to add code like this to plumb the event logger:

from opentelemetry import _events
from opentelemetry.sdk._events import EventLoggerProvider
_events.set_event_logger_provider(EventLoggerProvider())

This assumes you have ENV like below:

OTEL_EXPORTER_OTLP_ENDPOINT=http://localhost:4318
OTEL_EXPORTER_OTLP_PROTOCOL=http/protobuf
OTEL_INSTRUMENTATION_GENAI_CAPTURE_MESSAGE_CONTENT=true
OTEL_PYTHON_LOGGING_AUTO_INSTRUMENTATION_ENABLED=true
OTEL_LOGS_EXPORTER=otlp_proto_http

Describe the solution you'd like

I would like the EventLoggerProvider to be enabled by default or driven by ENV variables, so that "zero code" works as expected for the other signal types.

Describe alternatives you've considered

paste the code, but it does end up with a warning log message

Additional Context

#4176 (comment) suggests this could be implemented in a PR

open-telemetry/opentelemetry.io#5575 is a blog which is more complicated as it relies on manual setup

Would you like to implement a fix?

None

[codefromthecrypt]

@lzchen @xrmx What's the chance of a patch release soon? The blog by @drewby heavily reviewed by @svrnm is currently in a non-ideal state as a lot of setup required for it to work has to be dispatched to documentation that has yet to be merged.

Instructions like this are misleading, because there is more to it to get events plumbed.

"Simply set the environment variable OTEL_INSTRUMENTATION_GENAI_CAPTURE_MESSAGE_CONTENT

If we release and document the blog as-is, I fear this is going to frustrate new users and be more difficult than alternatives out there today, such as langtrace and openllmetry. For example, existing otel-based SDKs typically have one line or two to setup, but that includes everything needed to get prompt/completion data. From a "quick start" perspective, it is a step back, not a step forward. Finding out what to do requires following links to code not explicitly said in the blog.

OTOH, if this patch is released, we can switch to "zero code". The zero code approach is even better than existing SDKs. Zero code gets everything plumbed with no code in the main.py, just env and requirements.txt. Zero code in the blog doesn't prevent linking advanced users to explicit setup instructions including event logger. However, it hides all that stuff from new audiences either new to otel or new to the log events subsystem.

My fear is that over one patch, we're on track to release a degraded first time experience, where the blog talks about log events and how they are important, but getting them to work is effortful vs after the patch. So, it seems worth asking.

Do you agree it is worth it? If not why? If so, when can we expect a patch release?

[Rutledge]

+1 to having this as part of the blog. @lzchen looking at the previous cadence it seems like we could expect it ~in the next week is that right?

[lzchen]

We are planning for a release at the end of November/Beginning of December. @codefromthecrypt is that too long of a gap do you think or would a patch be more preferred? @aabmass for visibility.

[codefromthecrypt]

hmm weird, I thought I replied. TL;DR; I think we should release ASAP

Main concern remains the official blog releasing before the next patch release due to not wanting to wait.

That said, others including me can make follow-up blogs when things work out of box early Dec, so if that happens we can correct later on other sites.

[codefromthecrypt]

#4276 should probably go in, or something similar, before a patch goes out. Things like this are expected being one of the first instrumentation to use the log events stuff.