Log stabilization current PRs overview

[xrmx]

PR/issue	impact	alternatives	notes
#4676	Removal of sdk LogData (no substitute) and LogRecord (now ReadableLogRecord and ReadWriteLogRecord). Change of typing in LogRecordProcessor.on_emit, in LogExporter.export
#4654	deprecations of _events, typechecking issues for users
#4647	Renames a bunch of sdk and exporter Log related classes, some of the sdk classes are touched in #4676 . Most if not all the old classes names are kept around with a deprecation notice
open-telemetry/opentelemetry-python-contrib#3628	none		t, nlu
open-telemetry/opentelemetry-python-contrib#3626	none		t, nlu
open-telemetry/opentelemetry-python-contrib#3625	none		t, nlu
open-telemetry/opentelemetry-python-contrib#3624	none		t, nlu
#4319	this contains a suggestion to change the signature of Logger.emit to take separated params instead of a a LogRecord, this can break all the genai instrumentations	we can do an implementation having both LogRecord and deprecate it later? e.g. #4737
#4330	When moving the loggingHandler from sdk to separate instrumentation, people without the logging instrumentation installed will lose the functionality		No PR yet
open-telemetry/opentelemetry-python-contrib#3687	Removal of out of spec attributes from opentelemetry-instrumentation-logging		No PR yet

nlu = introduce a new direct users for _logs api
t = can be used as testbed for out of tree users

[aabmass]

I don't think any of the contrib issues are strictly needed for stabilization. We should address #4330 IMO.

FYI we have a label "log-breaking-changes" (issues) to track as well.

[xrmx]

I don't think any of the contrib issues are strictly needed for stabilization. We should address #4330 IMO.

Added the LoggingHandler move to the table. I've listed the contrib changes because they are users of some of the code we are touching and so helpful to reason about the impact.

FYI we have a label "log-breaking-changes" (issues) to track as well.

The other labeled issue is fixed by a PR listed in the table (#4647)

[xrmx]

So here's a try at serializing all these PRs:

• find some downstream users that may be interested in checking their stuff against OTel git. Do we have big downstream users of Events? openllmetry, we should ask them to test the events deprecation branch then :)
• decide if we want to do the Logger.emit interface change Logs API: not possible to use without SDK #4319, if so start with a version that keeps backward compat and find a way to add the deprecations for the older interface
• merge a PR moving from events to logs for a single genai instrumentation and release it, see if any issues arise
• merge events api deprecation Mark events API/SDK as deprecated #4654 and evaluate how annoying it's for the other instrumentations, seek feedback from the downstream people, discuss and adapt accordingly - Dylan suggested to wait for this because users of the instrumentations don't have options
• if first conversion from events to logs worked fine convert the others
• merge the PR doing the renames [logs-api/sdk] Rename several classes from Log to LogRecord #4647 to double check that the old names are still around.
• adapt to the new names internally and seek for downstream user feedback. This a good time to check the documentation we have around (also in opentelemetry.io) and update that too
• now think really hard on the effects of [logs-sdk] Remove LogData and extend SDK LogRecord to have instrumentation scope #4676, again downstream users can check if something breaks for them
• Unnecessary/noncompliant attributes added via logging instrumentation opentelemetry-python-contrib#3687 should be easy to do, sorry for your query if you were using them :)
• Let's move the handler in Consider moving LoggingHandler out of the SDK and into an instrumentation #4330, this is a good chance to review the logging instrumentation code for other issues
• tag a release breaking everything, YOLO
• expect people complaining and issues reported :)

[DylanRussell]

Merging one of the gen AI PRs migrating off events SGTM if we want to play it super safe. I updated all those PRs to require v1.37 of the SDK/API which has your change attaching resource on emit, so they should be good to go..

We may want to wait on the events deprecation stuff for all the gen AI PRs migrating off events to go through, because people using those instrumentations will not be able to do anything about those warnings