-
Notifications
You must be signed in to change notification settings - Fork 24.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove dynamic templates from otel-plugin that set index:false
#113409
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These 2 are duplicates from [email protected]
- they were already there before, so I also left them in [email protected]
. Do we actually need these 2 here for OTel?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
After looking into this, I'd say it's safe to remove all 3.
histogram_metrics
: That is covered by ourhistogram
template, which is the same plus it addsignore_malformed: true
. Withoutignore_malformed: true
, I doubt we'd want to re-use this.histogram_metrics
comes from the old core templates.summary_counter
: This is covered bycounter_long
andcounter_double
, the difference is that this one setstype: aggregate_metric_double
instead 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_long
andgauge_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?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sgtm
- 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
x-pack/plugin/otel-data/src/yamlRestTest/resources/rest-api-spec/test/20_metrics_tests.yml
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 <[email protected]>
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we take the opportunity to make this one's name consistent with the others?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I was thinking summary
too.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
type: double | ||
time_series_metric: gauge | ||
ignore_malformed: true | ||
- summary_metrics: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 <[email protected]> * Remove unused dynamic templates * Update [email protected] --------- Co-authored-by: Felix Barnsteiner <[email protected]> Co-authored-by: Elastic Machine <[email protected]>
…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 [email protected] --------- Co-authored-by: Felix Barnsteiner <[email protected]> Co-authored-by: Elastic Machine <[email protected]>
…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
[email protected]
does not pull inmetrics@mappings
anymore. That is because multiple dynamic templates setindex:false
causing document rejection when those dynamic template match e.g. for an otel attribute.[email protected]
(from core) and moved them to[email protected]
. 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.