Deprecate event.name attribute in favor of EventName on the log record

[lmolkova]

Part of open-telemetry/opentelemetry-specification#4260

Logs SIG is working on migrating from event.name attribute to EventName field on LogRecord. This is a WIP that depends on the

• Change event.name attribute into top-level event name field opentelemetry-specification#4320
• Add event_name to logs proto opentelemetry-proto#600

Creating it to socialize the proposal and gather high-level feedback.

Semantic conventions that depend on event.name (over-the-wire):

• gen-ai events and corresponding python instrumentation
• az.resource.log and the corresponding collector receiver
• device.app.lifecycle event - did not find any instrumentations in otel org.
• feature_flag.evaluation aka feature_flag event - no instrumentations in otel org
• exception and rpc.message are span events - they should not populate event.name and should not be affected at all

Transition

event.name is an experimental attribute and de-facto is used by new-ish conventions and instrumentation libraries.

So we (Logs SIG) believe no common transition/migration plan is necessary, but individual instrumentation libraries can provide back-compat story.

• Instrumentations that produce events using explicit event.name attribute can do a breaking change and start using LogRecord.EventName property instead of the attribute. It's up to each instrumentation component to provide (or not provide) transition story.
• Telemetry consumers should expect to receive deprecated event.name attribute, new LogRecord.EventName property or both. When both are present, the LogRecord.EventName should be used as a source of truth.

Future

Instead of deprecating event.name, we might want to reserve it for bridges similarly to otel.status_code. E.g. when users want to report event using logging bridge and the logging facade does not have a notion of event name, the event.name attribute maybe used by the end users and translated to top-level LogRecord property by the adapter.

Deprecating the attribute is reversible, so I'd prefer to do it now and tackle compatibility with external logging libs separately.

Merge requirement checklist

• CONTRIBUTING.md guidelines followed.
• Change log entry added, according to the guidelines in When to add a changelog entry.
  • If your PR does not need a change log, start the PR title with [chore]
• schema-next.yaml updated with changes to existing conventions.

[breedx-splk]

I know it's still just draft, but this seems fine.

[breedx-splk]

Onward! 🚀