Map all OTel attributes

[noamalffasy]

As of now, only some of the attributes are mapped.

Some attributes (like process.command_args, process.owner, network.*) don't have any mapping and are automatically stored under labels.

Are there any plans to map them all? Or are there only specific ones that are supposed to be mapped?

[axw]

Yes. We intend to change how we store OTel data, and in the future attributes should be stored as-is. e.g. process.owner would be stored as process.owner, and would not be rewritten as labels.process_owner.

[josh-williams]

@axw Is there any update on this? I'm trying to set up all Elastic collection via OTel/APM server for an application I'm working on, and I can't really do that if I can't use most Semantic Convention attributes, so I might have to switch to another collection method if this isn't coming soon.

[axw]

@josh-williams for ingesting OTel data without loss of fidelity, we're now more focused on contributions to OpenTelemetry Collector, and the elasticsearch exporter. We may still make this change to APM Server, but it's not likely to come as soon as originally anticipated.

Just last week, support for indexing OTLP logs into Elasticsearch in a new "OTel-native" document structure was merged: open-telemetry/opentelemetry-collector-contrib#33290. Attribute names are used as-is, embedded within a namespace such as resource.attributes or scope.attributes.

Support for indexing metrics with this document structure is WIP (open-telemetry/opentelemetry-collector-contrib#34248), traces should be a fast follow, and then profiles.

[smith]

@AlexanderWert should we consider adding attributes mapping in APM server to help with UI migrations? For instance, we could probably put telemetry.sdk.* fields in data based on existing agent.name, etc. See elastic/kibana#195857

We have a lot of avenues to produce more data that's more closely aligned to semconv, like getting more people using EDOT, so I guess it's a matter of prioritization.