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
+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
@@ -15,8 +15,6 @@ products:
15
15
16
16
On host or virtual machine environments, deploy local, per-host OpenTelemetry Collector instances at these [edge](index.md#understanding-edge-deployment) host or VMs where your applications are running.
17
17
18
-
19
-
20
18
Collectors deployed on these edge environments have two main purposes:
21
19
22
20
1. The collection of local logs and infrastructure metrics. Refer to [this sample config file](https://github.com/elastic/elastic-agent/blob/main/internal/pkg/otel/samples/linux/managed_otlp/platformlogs_hostmetrics.yml) for recommended Collector receiver configurations for hostmetrics and logs.
@@ -34,7 +32,7 @@ The following sections outline the recommended architectures for different Elast
34
32
35
33
{{serverless-full}} provides a [Managed OTLP Endpoint](/reference/motlp.md) for ingestion of OpenTelemetry data.
Users can send data direct from the Collectors or SDKs deployed on the edge environment through OTLP without any additional requirements for managing an ingestion layer.
40
38
@@ -46,13 +44,15 @@ stack: preview 9.2
46
44
47
45
{{ech}} provides a [Managed OTLP Endpoint](/reference/motlp.md) for ingestion of OpenTelemetry data. Users can send data direct from the Collectors or SDKs deployed on the edge environment through OTLP without any additional requirements for managing an ingestion layer.
48
46
47
+
48
+
49
49
### Self-managed
50
50
51
51
In a self-managed Elastic deployment, we recommend running an EDOT Collector in gateway mode as a unified ingestion layer for OTLP telemetry from OpenTelemetry collectors or SDKs running at the edge. This gateway can receive all signals (logs, metrics and traces), apply processing as needed, and cover the same use cases that previously required components like APM Server or Logstash.
52
52
53
53
Depending on your scalability and durability needs, this can be a single collector that scales horizontally, or a chain of collectors where each tier handles a specific concern. For high availability and stronger durability guarantees, you can insert Kafka between tiers so that ingestion is buffered and resilient to downstream outages.
Compared to [Elastic's classic ingestion paths](docs-content://solutions/observability/apm/use-opentelemetry-with-apm.md) for OTel data, with the EDOT Collector in gateway mode there is no need for {{product.apm-server}} anymore.
Copy file name to clipboardExpand all lines: docs/reference/architecture/k8s.md
+14-9Lines changed: 14 additions & 9 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -11,13 +11,13 @@ products:
11
11
- id: edot-collector
12
12
---
13
13
14
-
# Kubernetes Environments
14
+
# Kubernetes environments
15
15
16
-
The recommended OTel architecture for Kubernetes clusters includes a set of OpenTelemetry collectors in different forms. The following diagram shows the different forms:
16
+
## Types of Collectors
17
17
18
-
18
+
The recommended OTel architecture for Kubernetes clusters includes a set of OpenTelemetry collectors in different forms.
19
19
20
-
## DaemonSet collectors
20
+
###DaemonSet collectors
21
21
22
22
The Collector as a DaemonSet resource kind, deploys an instance on each Kubernetes node as an [edge collector](index.md#understanding-edge-deployment) (close to your data sources) to collect node-local logs and host metrics.
23
23
@@ -27,13 +27,13 @@ That Collector enriches the application telemetry with resource information such
27
27
28
28
All data is then sent through OTLP to the gateway Collector running in the cluster.
29
29
30
-
## Cluster collector
30
+
###Cluster collector
31
31
32
32
The Cluster collector is a Deployment resource kind that collects Kubernetes cluster-level metrics and sends them to the gateway Collector using OTLP.
33
33
34
34
This instance of the collector helps with collecting cluster level metrics which otherwise would be duplicated by the DaemonSet instances.
35
35
36
-
## Gateway collector (on edge)
36
+
###Gateway collector (on edge)
37
37
38
38
The gateway Collector deployed in the Kubernetes cluster centralizes OTel data from the DaemonSet and Cluster collectors. This gateway collector runs as part of your edge environment, not as part of the Elastic backend. It can be any OpenTelemetry Collector distribution as long as it forwards data using OTLP to the appropriate backend endpoint:
39
39
@@ -45,14 +45,14 @@ The gateway Collector deployed in the Kubernetes cluster centralizes OTel data f
45
45
The following sections outline the recommended architectures for different Elastic deployment scenarios.
46
46
47
47
::::{note}
48
-
Elastic Observability 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 sections for the different Elastic deployment options.
48
+
{{product.observability}} 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 sections for the different Elastic deployment options.
49
49
::::
50
50
51
51
### {{serverless-full}}
52
52
53
53
{{serverless-full}} provides a [Managed OTLP Endpoint](/reference/motlp.md) for ingestion of OpenTelemetry data.
For a Kubernetes setup, the gateway Collector in your cluster sends OTLP data directly to the Managed OTLP Endpoint. There is no need for an EDOT gateway collector on the backend side. You can optionally deploy an EDOT Collector in gateway mode as part of your edge environment if you need additional processing before data reaches the Managed OTLP Endpoint.
58
58
@@ -66,11 +66,16 @@ stack: preview 9.2
66
66
67
67
For a Kubernetes setup, the gateway Collector in your cluster sends OTLP data directly to the Managed OTLP Endpoint. There is no need for an EDOT gateway collector on the backend side.
68
68
69
+
70
+
69
71
### Self-managed
72
+
```{applies_to}
73
+
product: ga 2.3.0
74
+
```
70
75
71
76
With a self-managed deployment, you need an EDOT Collector running in gateway mode as part of your {{product.observability}} backend (not in the Kubernetes cluster). This backend gateway collector receives OTLP data from the Kubernetes gateway collector and ingests it into {{es}}.
0 commit comments