Kubernetes environments

Serverless Observability Stack

In Kubernetes environments, deploy OpenTelemetry Collectors as edge collectors within your cluster where your applications are running. The recommended architecture includes different types of collectors deployed as various Kubernetes resource types (DaemonSets, Deployments) to handle specific collection needs.

Collectors deployed in these edge environments have several main purposes:

1. The collection of node-level logs and infrastructure metrics through DaemonSet collectors running on each node.
2. The collection of cluster-level metrics through a dedicated Cluster collector.
3. Enriching application telemetry from OTel SDKs with corresponding host and Kubernetes resource attributes.
4. Centralizing data through a gateway collector before sending to the Elastic backend.

The recommended OTel architecture for Kubernetes clusters includes a set of OpenTelemetry collectors in different forms.

The Collector as a DaemonSet resource kind, deploys an instance on each Kubernetes node as an edge collector (close to your data sources) to collect node-local logs and host metrics.

The DaemonSet collectors also can funnel and enrich telemetry from applications instrumented with OTel SDKs and running on corresponding nodes.

That Collector enriches the application telemetry with resource information such as host and Kubernetes metadata.

All data is then sent through OTLP to the gateway Collector running in the cluster.

The Cluster collector is a Deployment resource kind that collects Kubernetes cluster-level metrics and sends them to the gateway Collector using OTLP.

This instance of the collector helps with collecting cluster level metrics which otherwise would be duplicated by the DaemonSet instances.

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:

• For Elastic Cloud Serverless and Elastic Cloud Hosted: Sends OTLP data to the Managed OTLP Endpoint.
• For self-managed, ECE, and ECK: Sends OTLP data to an EDOT Collector running in gateway mode on the backend side (refer to backend architecture).

The following sections outline the recommended architectures for different Elastic deployment scenarios.

Elastic Cloud Serverless provides a Managed OTLP Endpoint 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.

Stack Preview 9.2.0 ECH

Elastic Cloud Hosted provides a Managed OTLP Endpoint 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.

With a self-managed deployment, you need an EDOT Collector running in gateway mode as part of your Elastic Observability backend (not in the Kubernetes cluster). This backend gateway collector receives OTLP data from the Kubernetes gateway collector and ingests it into Elasticsearch.

The backend gateway Collector processes APM data and logs to improve latency on solution UIs before ingesting into Elasticsearch.

The Kubernetes cluster components (DaemonSet collectors, Cluster collectors, gateway collector, and OTel SDKs) can all use fully vendor-agnostic or upstream OpenTelemetry components. Only the backend gateway Collector needs to be either an EDOT Collector or a custom, EDOT-like Collector containing the required components and preprocessing pipelines.