Skip to content

[exporter/elasticsearch] deprecate/remove dedot config #33772

Open
@axw

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

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions