[exporter/elasticsearch] deprecate/remove dedot config #33772
Comments
|
Pinging code owners:
See Adding Labels via Comments if you do not have permissions to add labels yourself. |
**Description:** Deprecate `exporter/elasticsearch`'s "dedot" configuration. In a future release we will remove this configuration, and always dedot ECS mode, never for raw/none modes. **Link to tracking Issue:** #33772 **Testing:** N/A **Documentation:** Updated the README.
|
This issue has been inactive for 60 days. It will be closed in 60 days if there is no activity. To ping code owners by adding a component label, see Adding Labels via Comments, or if you are unsure of which component this issue relates to, please ping Pinging code owners:
See Adding Labels via Comments if you do not have permissions to add labels yourself. |
|
This is still relevant. The code has been deprecated but not removed - we're waiting for the 6 month grace period per https://github.com/open-telemetry/opentelemetry-collector/blob/main/CONTRIBUTING.md |
Component(s)
exporter/elasticsearch
Describe the issue you're reporting
The
dedotconfig 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
dedotlogic is making the exporter's encoding logic needlessly complicated. I propose we:dedotconfigThe text was updated successfully, but these errors were encountered: