Add EventName to Log and Event Record in data model

[pellared]

This is a proposal to add EventName of type string as a field in the data model instead of having it just a event.name string attribute defined in semantic conventions.

Related to:

• Add EventName parameter to Logger.Enabled #4220
• Add Event Enabled operation to Logger #4263
• Add EmitEvent to Logs API #4259

Consequences

• Currently, we have no control what type of value would be set to event.name (e.g. by log bridges). Promoting it to a field with a concrete type would make the design more type-safe. So far my understanding is that most people would like to have it as string. On the other hand, there are some cases where users would like to have something different or more lightweight. Personally, I think settling on a concrete "type" is better than having something very generic and abstract. I think that having EventId of any type is nothing better than having event.name defined in semantic conventions. I would consider having EventId of an integer type (instead of EventName as string) for performance reasons; yet this can be tracked separate issue.

It is very important (actually the EventId, the numerical, machine friendly version of EventName that is most important to do ultra fast checks!) for scenarios we are working on in OTel Rust, C++. I don't know if it is something every language/implementation cares about. Given spec does not prohibit an implementation from allowing more parameters, I am totally okay if spec does not mention it, as OTel C++/Rust can offer this as extras.

Originally posted by @cijothomas in #4203 (comment)

• Having event name as a field would make adding some events processing functionalities to the Logs SDK easier (e.g. filtering based on event name)

I am against this proposal as I do not think that handling event.name for Enabled is more important than for other attributes. Passing all attributes "destroys" the idea of Enabled which is supposed to be used by the user to check whether it makes sense to build and emit a log records (performance tuning). The parameters accepted by Logger.Enabled should be "cheap" to construct.

The SDK's Enabled implementation would get the context, severity level, instrumentation scope that should be enough.

Side note: I think that instrumentation libraries emitting events could add a event.namespace instrumentation scope attribute instead of putting the namespace to each event.name value as a prefix. EDIT: I created #4239

If "event.name" is an attribute, then I totally agree!
(Which is why OTel .NET, C++, Rust all decided to put EventName as a top-level field in LogRecord, and not inside Attributes)

Originally posted by @cijothomas in #4220 (comment)

• Bridges for logging libraries that do not have a concept of log record identifier would need to have some convention to map event.name attribute into EventName field. This mapping could be configurable. Therefore, people who do not want to emit events using logging libraries may disable this mapping behavior.

• Emitting events would need to be done by calling Emit Event on Logger (see Add EmitEvent to Logs API #4259) (unless optional parameter EventName is added to Logger.Emit). Log bridges would have to call Emit Event when they would want to produce events

Remark

The main question is whether we want to promote the event.name attribute to a LogRecord EventName string field. The decision on the desired field's name and type can be tracked as a separate issue.

[pellared]

I think this change is important from design perspective, if we want to make sure that we have separate APIs for emitting log records and events.

It allows as to make it impossible to emit an event using Emit a LogRecord - assuming we will not add an optional EventName parameter.

The events would have to be emitted using Emit an Event by both instrumentation code (applications, instrumentation libraries) and bridges (it should be possible as marked in OTEP - maybe it could an opt-in functionality of a bridge) and the parameters could be more constraint than the one for Emit a Record e.g.:

• SeverityNumber is required
• Attributes as "standard attributes" type (instead of log attributes)

[tedsuo]

I would be in favor of this!

I have concerns around supporting 3rd party loggers wanting to create events. Those loggers would not have a name field, so they would need to use something like an event.name attribute. As long as we think these events can be caught and transformed properly before entering into any Otel pipeline then this is not a problem. If we cannot have this expectation, then any pipeline processor would have to check two places for the event name – the event.name attribute and the Name field. That would be annoying, I would prefer we avoid this scenario.

[tedsuo]

But I do think the Name field should be added as an option onto the EmitLogRecord function. In part for the reasons described in the comment above: there may be bridges to loggers that are creating events in some way. But also because it seems wrong to hide it.

[pellared]

there may be bridges to loggers that are creating events in some way

The bridges can use Emit a Record when they want to emit an event and not a regular log record. See #4260 (comment)