[Proposal] Adding Log/Event name in LogRecord structure

[lalitb]

What happened?

This is in continuation to the PR #1346 which propagates event name to the exporters by populating it in the attributes.

The tokio tracing library has recently added support for users to customize the name metadata using logging macros. Eg.

event!(name: "some_info", Level::INFO, "something has happened!");

For logging prospective, this can be used to uniquely identify the category of events (e.g. exception, authorization etc.). It would be good to be able to propagate this field to logging backend, where it can be further used for end-users to filter events based on their category. The PR #2699 does this by populating this field to attributes, with the already existing attribute with same key name taking precedence. The proposal is to do additive changes in the LogRecord API/structure for this. So the structure will look like:

pub struct LogRecord {

    /// Event name. Optional as not all the logging API support it.
   pub event_name: Option<Cow<'static, str>>,

    /// Record timestamp
    pub timestamp: Option<SystemTime>,

    /// Timestamp for when the record was observed by OpenTelemetry
    pub observed_timestamp: SystemTime,

    /// Trace context for logs associated with spans
    pub trace_context: Option<TraceContext>,

    /// The original severity string from the source
    pub severity_text: Option<Cow<'static, str>>,
    /// The corresponding severity value, normalized
    pub severity_number: Option<Severity>,

    /// Record body
    pub body: Option<AnyValue>,

    /// Additional attributes associated with this record
    pub attributes: Option<Vec<(Key, AnyValue)>>,

}

This will allow us to

• Directly propagate this field to exporters, without touching the attributes, and worrying about the key collision.
• Allow adding any custom filtering logic based on event_name and other fields in LogProcessor (in future). Iterating the attributes in general would be performance heavy.
• And also, achieve better performance for exporters who may want to retrieve this field, process and send upstream. Again, iterating the attributes in general would be performance heavy.
• Bringing more parity between tracing and otel, with tracing being one of the most widely used tracing library across rust ecosystem.

This would be the additive change in the LogRecord structure, even though it is not part of specification. Please note that the Otel Specification also have the Event API, which has event_name as the field, so we are not totally out of sync to specs.

API Version

0.21.0

SDK Version

0.21.0

What Exporters are you seeing the problem on?

N/A

Relevant log output

No response

[bIgBV]

I've picked this up

[bIgBV]

Now that the event_name field is being propagated, we can get the next steps started out. I'll start looking into the existing exporters to see if the field can be used directly.

[lalitb]

This should be good to close. None of the core exporters support the event_name field as of now.