Skip to content

Discuss ECS' field reuse concept for OTel semantic attributes #339

@AlexanderWert

Description

@AlexanderWert

In ECS there is the concept of field reuse that does not exist in OTel semantic conventions / semantic attributes (yet).
Field reuse in ECS means that an entire namespace of fields (i.e. attributes) can be reused under another namespace without the need to explicitly define all the fields in the second namespace.

Example from ECS

A clear example from ECS is the Geo namespace which defines attributes for describing a Geo location of an event / entity / etc.

Let's assume you want to collect the Geo location of the client and server (e.g. derived from the corresponding public IP address in a log file).

ECS defines that the entire geo.* namespace can be reused (i.e. nested) under the client.geo.* or server.geo.* namespaces. With that, there's no need to duplicate the definition of those nested fields explicitly.

To achieve the same with OTel semconv today, we would need to explicitly define all permutations between client/server and all the geo.* fields. This becomes especially broad the more a namespace can be reused in other namespaces.

Example from existing OTel semconv attributes

The following is only a very small example, but illustrates the idea behind reuse.
In OTel, we have today the following attributes regarding client/server.socket.* (that are symmetric):

  • client.socket.domain
  • client.socket.address
  • client.socket.port
  • server.socket.domain
  • server.socket.address
  • server.socket.port

Instead of defining all the permutations explicitly, we could have defined the socket attributes only once:

  • socket.domain
  • socket.address
  • socket.port

And then defining that namespace as being reusable in client.* and server.*.
I appreciate this particular case might be not the best example, but it shows the conceptual idea.

Intent

I think this concept is especially useful once we add more ECS fields (especially fields like Geo, security-related fields, etc.) and explicitly differentiate between attribute definitions in a registry and attribute usages in semantic conventions. Thus, semantic conventions could explicitly overwrite / precise attribute descriptions in a concrete context.

I'd like to use this issue to discuss the idea of adding a similar concept to OTel once we established the attributes registry as the place for defining attributes. This would allow us to be more efficient and compact in defining attributes that can occur in multiple places / contexts.

Metadata

Metadata

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions