Drop log Name field

[jack-berg]

Fixes #2074.

Changes

Drop the Log name field.

[tigrannajaryan]

The mappings that previously used the Name field may require more discussion, but because in this document the mappings are Examples I am fine with merging this PR as is and if necessary future PRs can make further changes to the example mappings.

After this is merged we need a corresponding change in the proto repository and it will be followed by a change in the Collector.

@open-telemetry/collector-approvers @open-telemetry/collector-contrib-approvers please review and comment if you believe your receiver/exporter absolutely needs this field to stay for some reason and cannot substitute it by an attribute with a format-specific semantic convention.

[tigrannajaryan]

@jkwatson @pmm-sumo please review.

[tigrannajaryan]

Let's keep this open for a few more days, don't merge yet. I want to make sure more people are aware of the change.

[bogdandrutu]

Not sure about the impact, but I think the example of using "Attributes" to model different "schemas" for the logs is not very robust. I am ok removing it, but I would feel bad about using attributes to define "schema"

[tigrannajaryan]

Not sure about the impact, but I think the example of using "Attributes" to model different "schemas" for the logs is not very robust. I am ok removing it, but I would feel bad about using attributes to define "schema"

@bogdandrutu which example are you referring to? I am also confused by the reference to "schemas". What do you mean by this?

[tigrannajaryan]

@open-telemetry/specs-logs-approvers please review.

[bogdandrutu]

@tigrannajaryan was referring to the issue.. as I said I think this is fine in general, but we should carefully think before making the standard of encoding different types of events/entries as logs and identify using attributes

[tigrannajaryan]

@tigrannajaryan was referring to the issue.. as I said I think this is fine in general, but we should carefully think before making the standard of encoding different types of events/entries as logs and identify using attributes

Got it. I have been thinking about this for a while now and it seems to fit nicely in how we understand the attributes are used how presence of attributes can indicate a "type" of the recorded information. For example let's say I want to record information about events happening in the browser. Instead of using the Name field I could for example have a semantic convention for an attribute named browser.event_type or browser.dom.event_type the presence of which indicates that it is a browser event and the value is a string that tells what exactly the event is.

Or for example Otel Collector may decide to emit events about its state, for example otel.collector.state_change with a value of "started" can indicate that the Collector is started and in that same log record also record a bunch other attributes that describe the Collector.

Essentially every domain (such as browser) needs to come up with a reasonable semantic convention for the event they want to describe.

[himanshpal]

The log name is really helpful since its always going to be low cardinality field & having it improves the search by a large factor compared to doing LIKE on body field for systems which store logging data in columnar format (parquet) and query it via athena/presto.

Removing this field moves the responsibility back to lib consumer to make sure all attributes for an event emitted minimum fields & standard across all lang sdk's.

[tigrannajaryan]

@himanshpal the problem with the existing Name field is that the community has not been able to come up with a clear definition of what it is supposed to reflect. The semantics are not clear and people have different opinions about what it is supposed to contain.

For your particular use case if you know what you want to record as the "name" you can do that as an attribute.

If in the future we manage to form a consensus around what the "name" means we do not preclude the possibility of adding the field back.

[jack-berg]

Removing this field moves the responsibility back to lib consumer to make sure all attributes minimum have something similar in all lang sdk's.

@himanshpal one of the problems with name is that it lacks an unambiguous mapping for all known log and event formats, as argued here. So while its nice to have a low cardinality identifier, it's not particularly useful or guaranteed to be low cardinality unless the mapping semantics are well established.

Instead, each log format can establish its own mapping conventions. Folks doing analysis / search can use any type / classifiers available for format of logs they're analyzing.

** Edit - clearly I didn't see Tigran's reply before making this one! My response is very redundant.