Remove dynamic templates from otel-plugin that set index:false#113409
Conversation
| - histogram_metrics: | ||
| mapping: | ||
| type: histogram | ||
| - summary_metrics: | ||
| mapping: | ||
| type: aggregate_metric_double | ||
| metrics: sum, value_count | ||
| default_metric: value_count |
There was a problem hiding this comment.
These 2 are duplicates from metrics@mappings.json - they were already there before, so I also left them in metrics@mappings.json. Do we actually need these 2 here for OTel?
There was a problem hiding this comment.
In https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/exporter/elasticsearchexporter/model.go, I could not find usage of the following dynamic templates. Thus, I think they can be removed.
- summary_gauge
- summary_counter
- histogram_metrics
There was a problem hiding this comment.
Will they be useful in any scenarios? If there is a chance that we need it, might be useful to keep these if a future version of es exporter need to work with 8.16 ES. Just asking if see how likely we need them.
There was a problem hiding this comment.
After looking into this, I'd say it's safe to remove all 3.
histogram_metrics: That is covered by ourhistogramtemplate, which is the same plus it addsignore_malformed: true. Withoutignore_malformed: true, I doubt we'd want to re-use this.histogram_metricscomes from the old core templates.summary_counter: This is covered bycounter_longandcounter_double, the difference is that this one setstype: aggregate_metric_doubleinstead of double and long. By looking at docs for counters in OTel I doubt we'd want to useaggregate_metric_double- that does not match the OTel counters.summary_gauge: same as above, and this is covered bygauge_longandgauge_double.
So with that, I don't think we'd want to use those dynamic templates for OTel later. -> I'd be for just removing.
Any thoughts? Maybe something I'm overlooking?
| - histogram_metrics: | ||
| mapping: | ||
| type: histogram | ||
| - summary_metrics: | ||
| mapping: | ||
| type: aggregate_metric_double | ||
| metrics: sum, value_count | ||
| default_metric: value_count |
There was a problem hiding this comment.
In https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/exporter/elasticsearchexporter/model.go, I could not find usage of the following dynamic templates. Thus, I think they can be removed.
- summary_gauge
- summary_counter
- histogram_metrics
carsonip
left a comment
There was a problem hiding this comment.
I assume we want to auto backport this to 8.16 as well?
Yeah. I guess this should target the current |
…ec/test/20_metrics_tests.yml Co-authored-by: Felix Barnsteiner <felixbarny@users.noreply.github.com>
|
I think you'll also need to add the Also, based on the checks, this needs these labels as well: |
|
Pinging @elastic/es-data-management (Team:Data Management) |
| type: double | ||
| time_series_metric: gauge | ||
| ignore_malformed: true | ||
| - summary_metrics: |
There was a problem hiding this comment.
Should we take the opportunity to make this one's name consistent with the others?
There was a problem hiding this comment.
Makes sense to me. We'd then just call it summary, right? This means that there will need to be changes in the ES exporter, though.
cc @carsonip
There was a problem hiding this comment.
I renamed it to summary. @carsonip I'll wait for you to acknowledge this before I push merge, just to make sure we don't miss the change in ES exporter.
There was a problem hiding this comment.
I'm wondering if rolling out that change is easier by temporarily adding both summary and summary_metrics in this PR, then making the change in the ES exporter, then removing the summary_metrics dynamic template in another ES PR.
That way, there's never a situation where ES exporter@main is incompatible with ES@main, without having to coordinate to merge the ES and ES exporter PRs at the same time (which is somewhat unpredictable for the ES exporter).
There was a problem hiding this comment.
ack. Will rename it to summary.
I'm wondering if rolling out that change is easier by temporarily adding both summary and summary_metrics in this PR, then making the change in the ES exporter, then removing the summary_metrics dynamic template in another ES PR.
I'm not too concerned. e2e poc pins ES version and es exporter version anyway. The mains don't have to be compatible at every point of time.
There was a problem hiding this comment.
| type: double | ||
| time_series_metric: gauge | ||
| ignore_malformed: true | ||
| - summary_metrics: |
There was a problem hiding this comment.
Makes sense to me. We'd then just call it summary, right? This means that there will need to be changes in the ES exporter, though.
cc @carsonip
|
@elasticmachine update branch |
💚 Backport successful
|
…stic#113409) * Remove dynamic templates from otel-plugin that set `index:false` * Update x-pack/plugin/otel-data/src/yamlRestTest/resources/rest-api-spec/test/20_metrics_tests.yml Co-authored-by: Felix Barnsteiner <felixbarny@users.noreply.github.com> * Remove unused dynamic templates * Update metrics-otel@mappings.yaml --------- Co-authored-by: Felix Barnsteiner <felixbarny@users.noreply.github.com> Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
…3409) (#113578) * Remove dynamic templates from otel-plugin that set `index:false` * Update x-pack/plugin/otel-data/src/yamlRestTest/resources/rest-api-spec/test/20_metrics_tests.yml * Remove unused dynamic templates * Update metrics-otel@mappings.yaml --------- Co-authored-by: Felix Barnsteiner <felixbarny@users.noreply.github.com> Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
…mary_metrics to summary (#35424) **Description:** <Describe what has changed.> <!--Ex. Fixing a bug - Describe the bug and how this fixes the issue. Ex. Adding a feature - Explain what this achieves.--> Renaming OTel mode dynamic template summary_metrics to summary to align with Elasticsearch otel-data change elastic/elasticsearch#113409 **Link to tracking Issue:** <Issue number if applicable> **Testing:** <Describe what testing was performed and which tests were added.> **Documentation:** <Describe the documentation added.> No changelog as this should not concern end users. This is a coordinated change between in-development Elasticsearch otel-data plugin and in-development elasticsearchexporter OTel mapping mode.
|
We forgot to increment the template version. This can lead to the dynamic templates not being available on existing deployments. |
Opened #113858 |
…mary_metrics to summary (open-telemetry#35424) **Description:** <Describe what has changed.> <!--Ex. Fixing a bug - Describe the bug and how this fixes the issue. Ex. Adding a feature - Explain what this achieves.--> Renaming OTel mode dynamic template summary_metrics to summary to align with Elasticsearch otel-data change elastic/elasticsearch#113409 **Link to tracking Issue:** <Issue number if applicable> **Testing:** <Describe what testing was performed and which tests were added.> **Documentation:** <Describe the documentation added.> No changelog as this should not concern end users. This is a coordinated change between in-development Elasticsearch otel-data plugin and in-development elasticsearchexporter OTel mapping mode.
Fixes #112945
Changes
metrics-otel@template.yamldoes not pull inmetrics@mappingsanymore. That is because multiple dynamic templates setindex:falsecausing document rejection when those dynamic template match e.g. for an otel attribute.metrics@mappings.json(from core) and moved them tometrics-otel@template.yaml. All these were introduced in x-pack/plugin/otel: introduce x-pack-otel plugin #111091, so I'd expect them to only used within the OTel project at this point. Here the assumption is that we'd only use these dynamic templates in otel mapping mode - since it's not in core anymore, e.g. in ecs mode they are not available. If we'd need those in non otel mapping mode later, we can still think about how to share it, but for now, I think best is to remove.