Description
Component(s)
exporter/elasticsearch
Describe the issue you're reporting
The dedot
config was introduced in the initial implementation of the Elasticsearch exporter for expanding dotted attributes into JSON object hierarchies, merging objects as needed. e.g. "service.name": "svc"
and "service.version": "1.0.0"
would be combined into {"service": {"name": "svc", "version": "1.0.0"}}
.
Somewhere along the line the exporter grew multiple encodings ("modes"): "none", "raw", and "ecs". Raw and None are almost the same, with some minor differences to how record-level attributes are encoded: at the top level vs. embedded under "Attributes."
ECS (Elastic Common Schema) mode came along more recently, with the intention being to encode Elasticsearch documents so they are compatible with existing Kibana UIs, dashboards, Ingest pipelines, etc. that expect ECS. Ingest pipelines in particular expect the documents to be "dedotted", so I think makes sense to always dedot in this mode, and remove the configuration.
Conversely, there's no real need to dedot in the exporter when using "none" or "raw" encodings. Dotted fields are understood by Elasticsearch, and the main reason for dedotting is to simplify Ingest pipelines. If you even need Ingest pipelines (why? use OTel Collector processors!) then you can instead use the dot_expander Ingest processor, or configure your Ingest processors to expect dotted field names.
All that to say: the dedot
logic is making the exporter's encoding logic needlessly complicated. I propose we:
- deprecate and then remove the
dedot
config - always dedot in ECS mode
- never dedot in raw/none modes