You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
[exporter/elasticsearch] Add _metric_names_hash to avoid metric rejections (#37511)
If metrics that have the same timestamp and dimensions aren't grouped
into the same document, ES will consider them to be a duplicate. This
adds a hash of the metric names that will be mapped as a dimension in
Elasticsearch. The tradeoff is that if the composition of the metrics
grouping changes over time, a new time series will be created. That has
an impact on the rate aggregation for counters.
ES mapping changes: elastic/elasticsearch#120952
---------
Co-authored-by: Carson Ip <[email protected]>
Copy file name to clipboardExpand all lines: exporter/elasticsearchexporter/README.md
+37-16Lines changed: 37 additions & 16 deletions
Original file line number
Diff line number
Diff line change
@@ -457,23 +457,44 @@ processors:
457
457
458
458
### version_conflict_engine_exception
459
459
460
-
Symptom: elasticsearchexporter logs an error "failed to index document" with `error.type` "version_conflict_engine_exception" and `error.reason` containing "version conflict, document already exists".
461
-
462
-
This happens when the target data stream is a TSDB metrics data stream (e.g. using OTel mapping mode sending to a 8.16+ Elasticsearch). See the following scenarios.
460
+
Symptom: `elasticsearchexporter`logs an error "failed to index document" with `error.type` "version_conflict_engine_exception" and `error.reason` containing "version conflict, document already exists".
461
+
462
+
This happens when the target data stream is a TSDB metrics data stream (e.g. using OTel mapping mode sending to a 8.16+ Elasticsearch).
463
+
464
+
Elasticsearch [Time Series Data Streams](https://www.elastic.co/guide/en/elasticsearch/reference/current/tsds.html) requires that there must only be one document per timestamp with the same dimensions.
465
+
The purpose is to avoid duplicate data when re-trying a batch of metrics that were previously sent but failed to be indexed.
466
+
The dimensions are mostly made up of resource attributes, scope attributes, scope name, attributes, and the unit.
467
+
468
+
The exporter can only group metrics with the same dimensions into the same document if they arrive in the same batch.
469
+
To ensure metrics are not dropped even if they arrive in different batches in the exporter, the exporter adds a fingerprint of the metric names to the document in the `otel` mapping mode.
470
+
Note that you'll need to be on a minimum version of Elasticsearch in order for this to take effect 8.16.5, 8.17.3, 8.19.0, 9.0.0.
471
+
If you are on an earlier version, either update your Elasticsearch cluster or install this custom component template:
472
+
473
+
```shell
474
+
PUT _component_template/metrics-otel@custom
475
+
{
476
+
"template": {
477
+
"mappings": {
478
+
"properties": {
479
+
"_metric_names_hash": {
480
+
"type": "keyword",
481
+
"time_series_dimension": true
482
+
}
483
+
}
484
+
}
485
+
}
486
+
}
487
+
```
463
488
464
-
1. When sending different metrics with the same dimension (mostly made up of resource attributes, scope attributes, attributes),
465
-
`version_conflict_engine_exception`is returned by Elasticsearch when these metrics are not grouped into the same document.
466
-
It also means that they have to be in the same batch in the exporter, as metric grouping is done per-batch in elasticsearchexporter.
467
-
To work around the issue, use a [transform processor](https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/processor/transformprocessor/README.md) to ensure different metrics to never share the same set of dimensions. This is done at the expense of storage efficiency.
468
-
This workaround will no longer be necessary once the limitation is lifted in Elasticsearch (see [issue](https://github.com/elastic/elasticsearch/issues/99123)).
489
+
While in most situations, this error is just a sign that Elasticsearch's duplicate detection is working as intended, the data may be classified as a duplicate while it was not.
490
+
This implies data is lost.
469
491
470
-
```yaml
471
-
processors:
472
-
transform/unique_dimensions:
473
-
metric_statements:
474
-
- context: datapoint
475
-
statements:
476
-
- set(attributes["metric_name"], metric.name)
477
-
```
492
+
1. If the data is not sent in `otel` mapping mode to `metrics-*.otel-*` data streams, the metrics name fingerprint is not applied.
493
+
This can happen for OTel host and k8s metrics that the [`elasticinframetricsprocessor`](https://github.com/elastic/opentelemetry-collector-components/tree/main/processor/elasticinframetricsprocessor) has translated to the format the host and k8s dashboards in Kibana can consume.
494
+
If these metrics arrive in the `elasticsearchexporter` in different batches, they will not be grouped to the same document.
495
+
This can cause the `version_conflict_engine_exception` error.
496
+
Try to remove the `batchprocessor` from the pipeline (or set `send_batch_max_size: 0`) to ensure metrics are not split into different batches.
497
+
This gives the exporter the opportunity to group all related metrics into the same document.
478
498
479
499
2. Otherwise, check your metrics pipeline setup for misconfiguration that causes an actual violation of the [single writer principle](https://opentelemetry.io/docs/specs/otel/metrics/data-model/#single-writer).
500
+
This means that the same metric with the same dimensions is sent from multiple sources, which is not allowed in the OTel metrics data model.
0 commit comments