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/architecture/hosts_vms.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -27,7 +27,7 @@ These collectors have two main purposes:
27
27
See the recommended architectures per Elastic deployment scenarios:
28
28
29
29
:::{note}
30
-
Elastic's Observability solution is technically compatible with edge setups that are fully based on upstream OTel components as long as the ingestion path follows the recommendations outlined in the following sections.
30
+
Elastic's Observability solution is technically compatible with edge setups that are fully based on contrib OTel components as long as the ingestion path follows the recommendations outlined in the following sections.
Copy file name to clipboardExpand all lines: docs/reference/architecture/k8s.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -42,7 +42,7 @@ For self-managed and {{ech}} deployment models the Gateway Collector does some a
42
42
See the recommended architectures per Elastic deployment scenarios:
43
43
44
44
::::{note}
45
-
Elastic's Observability solution is technically compatible with setups that are fully based on upstream OTel components, as long as the ingestion path follows the recommendations outlined in following sub-sections for the different Elastic deployment options.
45
+
Elastic's Observability solution is technically compatible with setups that are fully based on contrib OTel components, as long as the ingestion path follows the recommendations outlined in following sub-sections for the different Elastic deployment options.
Copy file name to clipboardExpand all lines: docs/reference/compatibility/collectors.md
+2-2Lines changed: 2 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -61,11 +61,11 @@ For information on the compatibility of each Collector component, refer to the [
61
61
62
62
## Other Collector distributions
63
63
64
-
Non-EDOT distributions of the OTel Collector, such as custom Collector builds, upstream Collector distributions, and so on aren't officially supported through Elastic but are technically compatible ([Compatible]) if they contain the [required OTel Collector components](/reference/edot-collector/custom-collector.md) and are configured like the EDOT Collector.
64
+
Non-EDOT distributions of the OTel Collector, such as custom Collector builds, contrib Collector distributions, and so on aren't officially supported through Elastic but are technically compatible ([Compatible]) if they contain the [required OTel Collector components](/reference/edot-collector/custom-collector.md) and are configured like the EDOT Collector.
65
65
66
66
You can retrieve required components and configuration options from the [example configuration files](https://github.com/elastic/elastic-agent/tree/v<COLLECTOR_VERSION>/internal/pkg/otel/samples/linux) for the EDOT Collector.
67
67
68
-
For a comparison between EDOT and the upstream OTel, refer to [EDOT compared to upstream OTel](edot-vs-upstream.md).
68
+
For a comparison between EDOT and the contrib OTel Collector, refer to [EDOT compared to contrib Collector](edot-vs-upstream.md).
description: Differences between Elastic Distributions of OpenTelemetry (EDOT) and upstream OpenTelemetry.
2
+
navigation_title: EDOT compared to contrib Collector
3
+
description: Differences between Elastic Distributions of OpenTelemetry (EDOT) and contrib OpenTelemetry Collector.
4
4
applies_to:
5
5
stack:
6
6
serverless:
@@ -12,13 +12,13 @@ products:
12
12
- id: edot-sdk
13
13
---
14
14
15
-
# EDOT compared to upstream OpenTelemetry
15
+
# EDOT compared to contrib OpenTelemetry Collector
16
16
17
-
The [Elastic Distributions of OpenTelemetry (EDOT)](/reference/index.md) are based on the upstream OpenTelemetry project but include additional features and configurations that are specific to the Elastic ecosystem. Each EDOT component is carefully selected and tested to ensure it works seamlessly with Elastic Stack components.
17
+
The [Elastic Distributions of OpenTelemetry (EDOT)](/reference/index.md) are based on the contrib OpenTelemetry project but include additional features and configurations that are specific to the Elastic ecosystem. Each EDOT component is carefully selected and tested to ensure it works seamlessly with Elastic Stack components.
18
18
19
-
Here are some key differences and considerations when using EDOT compared to upstream OpenTelemetry:
19
+
Here are some key differences and considerations when using EDOT compared to contrib OpenTelemetry Collector:
| Support | Official Elastic support with SLAs. | Community support only. |
@@ -28,15 +28,15 @@ Here are some key differences and considerations when using EDOT compared to ups
28
28
| Central management | Central management of OTel SDKs and Collectors. | No central management. |
29
29
| Compatibility | Fully compatible with Elastic Stack components. | Compatible but may require additional configuration. |
30
30
| Self-managed/ECH | Required for full functionality. | Compatible but without guaranteed support. |
31
-
| Updates | Future updates aligned with Elastic Stack releases. | Updates depend on upstream OpenTelemetry release cycle. |
31
+
| Updates | Future updates aligned with Elastic Stack releases. | Updates depend on contrib OpenTelemetry release cycle. |
32
32
| EDOT-specific components | Includes custom components optimized for Elastic. | Uses standard OpenTelemetry components. |
33
33
34
-
EDOT offers a streamlined experience with less configuration burden compared to upstream OpenTelemetry. While you can use upstream components with Elastic, these components aren't covered under official Elastic support SLAs.
34
+
EDOT offers a streamlined experience with less configuration burden compared to contrib OpenTelemetry Collector. While you can use contrib components with Elastic, these components aren't covered under official Elastic support SLAs.
35
35
36
-
## EDOT Collector compared to upstream OTel Collector
36
+
## EDOT Collector compared to contrib OpenTelemetry Collector
37
37
38
-
The OpenTelemetry project does not provide a single, recommended distribution of the OpenTelemetry Collector for production use. Instead, it offers a variety of components that can be assembled into a custom Collector. Using the upstream Collector requires careful selection and configuration of components, which can be complex and time-consuming.
38
+
The OpenTelemetry project does not provide a single, recommended distribution of the OpenTelemetry Collector for production use. Instead, it offers a variety of components that can be assembled into a custom Collector. Using the contrib Collector requires careful selection and configuration of components, which can be complex and time-consuming.
39
39
40
-
EDOT Collector is a curated version of the OpenTelemetry Collector that includes specific components and configurations optimized for Elastic Observability. It is designed to work seamlessly with Elastic Stack components, such as Elasticsearch and Kibana, and provides additional features that are not available in the upstream OpenTelemetry Collector.
40
+
EDOT Collector is a curated version of the OpenTelemetry Collector that includes specific components and configurations optimized for Elastic Observability. It is designed to work seamlessly with Elastic Stack components, such as Elasticsearch and Kibana, and provides additional features that are not available in the contrib OpenTelemetry Collector.
41
41
42
42
For a complete list of components included in the EDOT Collector, refer to [EDOT Collector components](/reference/edot-collector/components.md).
Copy file name to clipboardExpand all lines: docs/reference/compatibility/limitations.md
+5-5Lines changed: 5 additions & 5 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -14,7 +14,7 @@ products:
14
14
15
15
# Limitations of Elastic Distributions of OpenTelemetry
16
16
17
-
The Elastic Distributions of OpenTelemetry (EDOT) come with a new way of ingesting data in OTel-native way and format. Elastic is continuously working on providing a great experience with OTel-native data within Elastic solutions, contributing popular Elastic features to the upstream OpenTelemetry projects and aligning concepts with OpenTelemetry.
17
+
The Elastic Distributions of OpenTelemetry (EDOT) come with a new way of ingesting data in OTel-native way and format. Elastic is continuously working on providing a great experience with OTel-native data within Elastic solutions, contributing popular Elastic features to the contrib OpenTelemetry projects and aligning concepts with OpenTelemetry.
18
18
19
19
While EDOT and OTel-native data collection already covers most of the core Observability use cases, the following limitations apply compared to data collection with classic Elastic data ingestion components.
20
20
@@ -27,7 +27,7 @@ EDOT already supports most core observability use cases, but in some scenarios,
27
27
***Existing integrations and dashboards:** Many prebuilt Elastic integrations and dashboards are designed for ECS-formatted data and may not work as expected with the OpenTelemetry semantic conventions without customization.
28
28
***Ingest pipelines for structuring logs:** {{es}} ingest pipelines cannot directly parse OTel-native data with dotted field names without preprocessing. See [Centralized parsing and processing of data](#centralized-parsing-and-processing-of-data) for workarounds.
29
29
***Tail-based sampling (TBS):**
30
-
If you need the full tail-based sampling capabilities of APM Server, use APM Server with an Elasticsearch output. EDOT does not provide managed TBS. You can run TBS in a self-managed EDOT Collector or any upstream OTel Collector and ingest the sampled traces into Elastic with some caveats - refer to [Tail-based sampling limitations](#tail-based-sampling-tbs) for more information.
30
+
If you need the full tail-based sampling capabilities of APM Server, use APM Server with an Elasticsearch output. EDOT does not provide managed TBS. You can run TBS in a self-managed EDOT Collector or any contrib OTel Collector and ingest the sampled traces into Elastic with some caveats - refer to [Tail-based sampling limitations](#tail-based-sampling-tbs) for more information.
31
31
32
32
Refer to [EDOT data streams compared to classic APM](../compatibility/data-streams.md) for an overview of how these ingestion paths differ.
33
33
@@ -43,11 +43,11 @@ Refer to [these examples](/reference/edot-collector/config/configure-logs-collec
43
43
44
44
## Infrastructure and host metrics
45
45
46
-
Due to limitations and gaps in data collection with the upstream OTel `hostmetrics`, there are corresponding limitations with the curated infrastructure and host metrics UIs in Elastic.
46
+
Due to limitations and gaps in data collection with the contrib OTel `hostmetrics`, there are corresponding limitations with the curated infrastructure and host metrics UIs in Elastic.
| Host network panels do not display data in some Elastic Observability UIs. | Due to an upstream limitation, `host.network.*` metrics are not available from OpenTelemetry. |
50
+
| Host network panels do not display data in some Elastic Observability UIs. | Due to an contrib limitation, `host.network.*` metrics are not available from OpenTelemetry. |
51
51
| Process state is unavailable in OpenTelemetry host metrics. | The `process.state` metric is not present and is assigned a dummy value of "Unknown" in the State column of the host processes table. |
52
52
| Host OS version and operating system may show as "N/A". | Although the {{es}} exporter processes resource attributes, it may not populate these values. |
53
53
| Normalized Load data is missing unless the CPU scraper is enabled. | The `system.load.cores` metric is required for the Normalized Load column in the Hosts table and the Normalized Load visualization in the host detailed view. |
@@ -86,7 +86,7 @@ Runtime metrics can be ingested and used to create custom dashboards. As a tempo
86
86
87
87
If you need the full tail-based sampling capabilities of APM Server, use APM Server with an Elasticsearch output. EDOT does not provide a managed TBS service.
88
88
89
-
You can run tail-based sampling in a self-managed EDOT Collector or any upstream OTel Collector and ingest the sampled traces into Elastic, with these caveats:
89
+
You can run tail-based sampling in a self-managed EDOT Collector or any contrib OTel Collector and ingest the sampled traces into Elastic, with these caveats:
90
90
91
91
***Metric accuracy:** Counts and rate metrics reflect sampled data, not total volumes. The Elastic APM backend cannot extrapolate totals because the `tailsamplingprocessor` does not send sampling probability metadata.
92
92
***Service map coverage:** Some edges between services may be missing.
Copy file name to clipboardExpand all lines: docs/reference/compatibility/nomenclature.md
+4-4Lines changed: 4 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -16,7 +16,7 @@ products:
16
16
17
17
OpenTelemetry (OTel) is a modular, extensible framework designed to integrate with a wide range of technologies. Its architecture enables interoperability across many components, extensions, and tools, giving users flexibility to shape their observability pipelines.
18
18
19
-
Elastic Distributions for OpenTelemetry (EDOT) are built from upstream OTel components and are technically compatible with a broad set of community components. Users can also send data to Elastic using other upstream OTel components or distributions like the contrib Collector and OTel SDKs, which are technically compatible with Elastic’s ingestion APIs.
19
+
Elastic Distributions for OpenTelemetry (EDOT) are built from contrib OTel components and are technically compatible with a broad set of community components. Users can also send data to Elastic using other contrib OTel components or distributions like the contrib Collector and OTel SDKs, which are technically compatible with Elastic’s ingestion APIs.
20
20
21
21
*Supported through Elastic* refers to components and configurations that Elastic has explicitly tested, validated, and committed to maintaining under our [Support Policies](https://www.elastic.co/support). This includes regular updates, issue triaging, and guidance from Elastic’s support and engineering teams. Components outside of this supported set may still work, but Elastic does not provide guaranteed support or troubleshooting assistance for them.
22
22
@@ -35,15 +35,15 @@ The EDOT Collector includes two types of components with different compatibility
35
35
36
36
### Core components
37
37
38
-
Core components are used by default in Elastic’s onboarding flows and are essential for common use cases. They are fully supported under your Service Level Agreement (SLA).
38
+
Core components are used by default in Elastic's onboarding flows and are essential for common use cases. They are fully supported under your Service Level Agreement (SLA).
39
39
40
40
### Extended components
41
41
42
-
Extended components are a curated set of optional components that enhance functionality and are technically compatible. These are not part of Elastic’s core product journeys and are not covered by SLAs. You’re free to use them, but Elastic provides limited support.
42
+
Extended components are a curated set of optional components that enhance functionality and are technically compatible. These are not part of Elastic's core product journeys and are not covered by SLAs. You're free to use them, but Elastic provides limited support.
43
43
44
44
### Breaking changes
45
45
46
-
Because the EDOT Collector is built on upstream OpenTelemetry, breaking upstream changes might impact both Extended and Core components. For example, breaking changes in semantic conventions or configuration options. Elastic highlights and manages these through docs and support channels.
46
+
Because the EDOT Collector is built on contrib OpenTelemetry, breaking contrib changes might impact both Extended and Core components. For example, breaking changes in semantic conventions or configuration options. Elastic highlights and manages these through docs and support channels.
47
47
48
48
:::{tip}
49
49
For the best support experience, rely on Core components and use Extended Components only when required.
The `bearertokenauth` extension is an upstream OpenTelemetry authentication method that supports static bearer tokens. This extension is useful for token-based authentication scenarios.
36
+
The `bearertokenauth` extension is an contrib OpenTelemetry authentication method that supports static bearer tokens. This extension is useful for token-based authentication scenarios.
Copy file name to clipboardExpand all lines: docs/reference/edot-collector/config/configure-metrics-collection.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -106,7 +106,7 @@ hostmetrics:
106
106
107
107
You must grant access to the `/proc` filesystem to the receiver by running the Collector with privileged access and mounting /proc and /sys appropriately. Refer to the hostmetrics container use [guide](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/receiver/hostmetricsreceiver#collecting-host-metrics-from-inside-a-container-linux-only) (Linux only).
108
108
109
-
Turning on the process scraper might significantly increase the volume of scraped metrics, potentially impacting performance. Refer to the upstream issue [#39423](https://github.com/open-telemetry/opentelemetry-collector-contrib/issues/39423) for discussion.
109
+
Turning on the process scraper might significantly increase the volume of scraped metrics, potentially impacting performance. Refer to the contrib issue [#39423](https://github.com/open-telemetry/opentelemetry-collector-contrib/issues/39423) for discussion.
110
110
111
111
To ensure compatibility with {{kib}}'s Infrastructure dashboards, include the [elasticinframetrics processor](https://github.com/elastic/opentelemetry-collector-components/tree/main/processor/elasticinframetricsprocessor) in your pipeline:
Use the previous example configurations as a reference when configuring your upstream Collector or customizing your EDOT Collector configuration.
35
+
Use the previous example configurations as a reference when configuring your contrib Collector or customizing your EDOT Collector configuration.
36
36
37
37
The following sections describe the default pipelines by use cases.
38
38
@@ -51,7 +51,7 @@ The goal of EDOT is to preserve OTel data formats and semantics as much as possi
51
51
52
52
#### Logs collection pipeline
53
53
54
-
For logs collection, the default configuration uses the [`filelog`] receiver to read log entries from files. In addition, the [`resourcedetection`] processor enriches the log entries with metadata about the corresponding host and operating system.
54
+
For logs collection, the default configuration uses the [`filelog`] receiver to read log entries from files. In addition, the [`resourcedetection`] processor enriches the log entries with metadata about the corresponding host and operating system.
55
55
56
56
:::{note}
57
57
The `from_context: client_metadata` option in the `resource` processor only applies to transport-level metadata. It cannot extract custom application attributes.
0 commit comments