Consider moving `LoggingHandler` out of the SDK and into an instrumentation

[aabmass]

LoggingHandler is a Python stdlib logging.Handler implementation that bridges stdlib logging to the Logs SDK.

Some reasoning:

• It is not something that is specified in the SDK
• Will need to follow SDK versioning
• As a separate package, users could simply uninstall it if they don't want logging logs captured at all (or use OTEL_PYTHON_DISABLED_INSTRUMENTATIONS).
• Consider that opentelemetry-instrumentation-urllib is separate even though urllib is part the python standard library.
• There are other logging APIs like structlog.

Arguments against:

• A high percentage of users want to set it and forget it and this adds an extra step

[xrmx]

We already have a logging instrumentation btw.

The argument against is valid for every other instrumentation :sweat_smile:

[aabmass]

The argument against is valid for every other instrumentation 😅

True just trying to present some counterargument.

Existing logging instrumentation confusion aside, are you in favor or against moving LoggingHandler out of the SDK?

[lzchen]

I believe java already uses this convention for different logging libraries. Happy to discuss this in the SIG @aabmass

[xrmx]

The argument against is valid for every other instrumentation 😅

True just trying to present some counterargument.

Existing logging instrumentation confusion aside, are you in favor or against moving LoggingHandler out of the SDK?

I'm in favor, it would be a lot less confusing to me :)

[tammy-baylis-swi]

Arguments against:

• A high percentage of users want to set it and forget it and this adds an extra step

SDK's _init_logging function will need an additional installation and import from opentelemetry.instrumentation.logging -- is it too cyclical this way? _init_logging is used by the default OpentelemetryConfigurator and distro for zero-code instrumentation (so maybe not more cyclical than it is already). Some vendors' custom distros likely depend on this. Users will need decent notice of this change.

These logging configuration examples in docs/example and otel.io would also need an added install and import of instrumentation. Users not necessarily doing zero-code will need to install instrumentation even if only wanting to use the SDK i.e. the "extra step". Kinda weird if it's a key component of the logs bridge, but I don't think it's a huge deal.

[aabmass]

Thanks for the feedback Tammy. I was thinking we can just copy the handler into a new package and leave the old one around for a while with deprecation notice. We don't need to update it after that and can remove it in say 1 year.

Do you think this is a bad idea overall?

[tammy-baylis-swi]

we can just copy the handler into a new package and leave the old one around for a while with deprecation notice. We don't need to update it after that and can remove it in say 1 year.

I think it's fine with that ample planned notice and transition time. 👍 The eventual consistency outweighs what I last brought up imo.