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.

[MSNev]

I think we should reword the "two events" definition, as now it reads (to me) more specific than the previous trailing "two events"... Perhaps something like
(really just removing the "two" qualification as someone is likely to ask the question of what about if three, four, five events etc.)

"Unless the EventName property value matches, any fields or values within event bodies that share the same name or path should not be considered comparable."

With maybe a qualifier "Unless explicitly called out by the specific event definition" (or we can leave this out as edge cases (which they are).

And maybe a general follow up qualification about case-sensitivity (although I'm assuming that by keeping the above comments about Event names are subject to the same rules as [attribute names](/docs/general/attribute-naming.md) this "should" avoid this question... (Hopefully)

[lmolkova]

I've updated the text, ptal

[lmolkova]

spec 1.40.0 release is pending, let's wait for it to land