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
Copy file name to clipboardExpand all lines: docs/reference/compatibility/data-streams.md
+65-18Lines changed: 65 additions & 18 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,6 +1,6 @@
1
1
---
2
2
navigation_title: Data streams comparison
3
-
description: Learn how EDOT optimizes telemetry storage and query performance in Elastic Observability compared to classic APM.
3
+
description: Learn how EDOT optimizes telemetry storage and query performance in Elastic Observability compared to classic APM and ECS-based integrations.
4
4
applies_to:
5
5
stack:
6
6
serverless:
@@ -12,9 +12,9 @@ products:
12
12
- id: edot-sdk
13
13
---
14
14
15
-
# OpenTelemetry data streams compared to classic APM
15
+
# OpenTelemetry data streams compared to classic APM and ECS-based integrations
16
16
17
-
The Elastic Distribution of OpenTelemetry (EDOT) stores telemetry data using a storage model optimized for OpenTelemetry signals. When `mapping::mode: otel` is enabled on the [Elasticsearch exporter](elastic-agent://reference/edot-collector/components/elasticsearchexporter.md) (which is the default setting), EDOT writes logs, traces, and metrics to specialized data streams aligned with OpenTelemetry semantics.
17
+
The {{edot}} (EDOT) stores telemetry data using a storage model optimized for OpenTelemetry signals. When `mapping_mode: otel` is enabled on the {{es}} exporter (which is the default setting), EDOT writes logs, traces, and metrics to specialized data streams aligned with OpenTelemetry specifications.
18
18
19
19
This architecture is designed for scalable observability workloads. It supports dynamic attributes, reduces mapping complexity, and avoids issues like mapping explosions or manual dimension setup.
20
20
@@ -35,7 +35,18 @@ Metric data is stored using Elasticsearch’s [TSDS](docs-content://manage-data/
35
35
* Fast aggregations
36
36
* Automatic detection of metric dimensions (no need to manually define `time_series_dimension` in field mappings)
37
37
38
-
## Query compatibility with classic APM data streams
38
+
39
+
## Comparison with classic APM data streams
40
+
41
+
This table highlights key differences between classic Elastic APM data streams and EDOT with `mapping_mode: otel`:
| Index mode | General-purpose data streams (logs, traces, metrics) <br><br> TSDS is not supported for classic APM. | LogsDB (logs/traces), TSDS (metrics) |
46
+
| Mapping style | Nested objects are mapped as structured fields. Some exceptions exist, such as `labels.*` and `numeric_labels.*`, where dots in field names are replaced with underscores. <br><br> ECS supports multiple field types (keyword, long, double, date, boolean, and so on) as defined in the schema. | Native OpenTelemetry fields with `passthrough`, preserving types and structure. |
47
+
| Attribute handling | Dynamic mapping. Custom attributes are stored under `labels.*` (strings) or `numeric_labels.*` (numbers); dots in field names are replaced with underscores. <br><br> See [Document examples - classic APM](#classic-apm)| Dynamic mapping with native types under `attributes.*`, preserving dots in field names. <br><br> See [Document examples - EDOT](#edot)|
48
+
49
+
### Query compatibility with classic APM data streams
39
50
40
51
EDOT is designed to make OpenTelemetry data queryable using many of the same field names as classic APM (ECS-based) data streams. This helps preserve compatibility with existing dashboards, saved searches, and queries.
41
52
@@ -44,7 +55,7 @@ Query compatibility is achieved through:
44
55
***`passthrough` fields:** Make nested OpenTelemetry fields available at the top level so they can be queried. For example, while the service name is stored at `resource.attributes.service.name`, you can query it as `service.name` (the same field name as the one used in the classic APM data stream).
45
56
***Field aliases:** Map fields with different names in ECS and OpenTelemetry semantic conventions to a common query name to make migration easier.
46
57
47
-
### Limitations
58
+
####Limitations
48
59
49
60
Query compatibility is not complete:
50
61
@@ -55,20 +66,10 @@ These differences may require updates to certain queries or visualizations.
55
66
56
67
Refer to [ECS & OpenTelemetry](ecs://reference/ecs-opentelemetry.md) for details on the available aliases and field mappings.
57
68
58
-
## Comparison with classic APM data streams
59
-
60
-
This table highlights key differences between classic Elastic APM data streams and EDOT with `mapping_mode: otel`:
| Index mode | General-purpose data streams (logs, traces, metrics) <br><br> TSDS is not supported for classic APM. | LogsDB (logs/traces), TSDS (metrics) |
65
-
| Mapping style | Nested objects are mapped as structured fields. Some exceptions exist, such as `labels.*` and `numeric_labels.*`, where dots in field names are replaced with underscores. <br><br> ECS supports multiple field types (keyword, long, double, date, boolean, etc.) as defined in the schema. | Native OpenTelemetry fields with `passthrough`, preserving types and structure. |
66
-
| Attribute handling | Dynamic mapping. Custom attributes are stored under `labels.*` (strings) or `numeric_labels.*` (numbers); dots in field names are replaced with underscores. <br><br> See [Document examples - classic APM](#classic-apm)| Dynamic mapping with native types under `attributes.*`, preserving dots in field names. <br><br> See [Document examples - EDOT](#edot)|
67
-
68
69
69
70
### Document examples
70
71
71
-
#### Classic APM:
72
+
#### Classic APM
72
73
73
74
```yaml
74
75
"@timestamp": "2025-08-14T05:29:43.922Z"
@@ -93,7 +94,7 @@ log:
93
94
level: INFO
94
95
```
95
96
96
-
#### EDOT:
97
+
#### EDOT
97
98
98
99
```yaml
99
100
"@timestamp": "2025-08-14T05:29:43.922Z"
@@ -114,4 +115,50 @@ attributes:
114
115
body:
115
116
text: "Order was successfully created"
116
117
severity_text: INFO
117
-
```
118
+
```
119
+
120
+
121
+
## Comparison with ECS-based integrations
122
+
123
+
While classic APM and EDOT represent two ingestion paths for application telemetry, Elastic’s integrations (for example Nginx, MySQL, Kubernetes) also produce ECS-based data streams for logs, metrics, and events. These use ECS mappings and integration-specific pipelines optimized for their domain.
124
+
125
+
| Stream type | Typical field layout | Custom attributes / dot notation |
| **Integration ECS-based** | Uses ECS mapping tailored by integration. Custom fields are added under ECS-structured objects or `.custom` objects. Dots in field names are often disallowed or normalized to underscores. | Example: `host.os.name`, `nginx.access.time` rewritten to `nginx_access_time` |
128
+
| **EDOT (OTel + passthrough)** | Stores OTel-native nested object structure (`resource.attributes.*`, `attributes.*`). Uses `passthrough` to expose fields at the top level for query compatibility. | Example: `attributes.cart.items: 42`, `resource.attributes.service.name: "checkout-service"` |
| **Index mode** | General-purpose data streams (logs, traces, metrics); TSDS not supported | ECS-style data streams (logs, metrics, events) using integrations | LogsDB for logs/traces, TSDS for metrics |
| **Compatibility limits** | N/A | Some integration fields may not align 1:1 with ECS or OTel. | Not all ECS/integration fields have aliases; label vs attribute layout differs. |
158
+
159
+
160
+
## See also
161
+
162
+
* [ECS and OpenTelemetry schema reference](ecs://reference/ecs-opentelemetry.md)
163
+
* [Logs data stream (LogsDB)](docs-content://manage-data/data-store/data-streams/logs-data-stream.md)
164
+
* [Time Series Data Stream (TSDS)](docs-content://manage-data/data-store/data-streams/time-series-data-stream-tsds.md)
0 commit comments