Elastic Agent as an OpenTelemetry Collector

Starting with version 9.2, Elastic Agent runs the Elastic Distribution of OpenTelemetry (EDOT) Collector. Rather than managing separate Beats sub-processes, the agent collects data through an embedded OpenTelemetry (OTel) Collector process, leveraging the extensibility and interoperability of the OTel ecosystem. This architecture brings OTel capabilities while maintaining compatibility with existing Beats-based workflows and integrations.

This transition is incremental: in 9.2, agent self-monitoring uses the OTel runtime by default, while data collection inputs will be migrated to run as OTel receivers over subsequent releases. Existing integrations and agent configurations continue to work without disruption.

Previously Elastic Agent acted as a supervisor that launched and managed individual Beats processes to collect telemetry (Filebeat, Metricbeat, and others), each running as a separate sub-process.

With the new Elastic Agent OTel Collector architecture:

• Elastic Agent embeds the EDOT Collector as its runtime, eliminating the overhead associated with managing separate sub-processes.
• Instead of running as individual Beats processes, Beat inputs can run inside the EDOT Collector as Beat receivers.
• Elastic Agent leverages OTel receivers and pipelines to ingest, process, and export telemetry data in a unified, standard manner within a single OTel Collector process, reducing the agent's footprint.
• OTel-native receivers and pipelines run in the same Collector alongside Beat receivers.
• Backward compatibility is preserved: existing Beats-based integrations continue to work through Beat receivers without configuration changes or changes to the collected data.

×

A Beat receiver is a Beat input and its associated processors, wrapped to run as an OTel receiver inside the EDOT Collector. Beat receivers produce the exact same data, formatted according to the Elastic Common Schema (ECS), as current Beat inputs. Beat receivers don't output data in the OTLP schema.

When Beat receivers are enabled, Elastic Agent automatically translates the relevant parts of its standalone or Fleet-generated elastic-agent.yml file into an OTel Collector configuration.

The data path works as follows:

1. A Beat input (like filestream) collects data.
2. Beat-specific processors transform the data.
3. The data passes through OTel processing.
4. An exporter (Elasticsearch, Logstash, or Kafka) writes the data to the output destination.
5. As with Beats and Elastic Agent configurations for Beat inputs, data can be processed by ingest pipelines before being stored in Elasticsearch.

×

The introduction of Beat receivers does not require configuration changes. Inputs and outputs remain consistent for integration data. The migration to Beat receivers is rolling out incrementally across Elastic Agent versions:

• Agent self-monitoring data (metrics and logs) uses Beat receivers by default with the Elasticsearch output.
• Some metrics inputs use Beat receivers by default with the Elasticsearch output. For a list of the migrated inputs, refer to the Elastic Agent 9.3.0 release notes.
• All metrics inputs use Beat receivers by default, with support for the Elasticsearch, Logstash, and Kafka outputs.

Fleet-managed agents: The same Beats-based integration packages continue to work. These packages configure the relevant Beat receivers automatically. Assets such as dashboards, alerts, and ingest pipelines remain unchanged.

Standalone agents: Existing standalone configurations are accepted as before. Elastic Agent generates the OTel Collector configuration internally.

This example shows a Filebeat input configuration and its respective generated OTel configuration:

×

The term hybrid agent refers to an Elastic Agent that collects data using two methods at the same time:

• Beats-based data collection: The agent uses Beat inputs or Beat receivers to collect ECS-formatted data.
• OTel-native data collection: The agent uses standard OTel Collector receivers to ingest telemetry data using OTLP, with the data following semantic conventions.

Both methods run inside the same OTel Collector process. This is what makes the agent "hybrid": it combines traditional Beats-based data collection and OTel-native data collection within a single agent instance, rather than requiring separate tools for each. This reduces memory consumption compared to running separate Beat sub-processes alongside a standalone OTel Collector.

In practice, a single elastic-agent.yml can contain both an inputs and outputs section for Beats-based data collection and receivers, exporters, and service.pipelines sections for OTel-based data collection.

This example shows a hybrid agent configuration that collects system auth logs through a Beat input and monitors an HTTP endpoint through an OTel receiver.

inputs:
  - id: filestream-system-66cab0a6-6fa3-46b1-9af1-2ea171fbd885
    type: filestream
    data_stream:
      namespace: default
    streams:
      - id: filestream-system.auth-66cab0a6-6fa3-46b1-9af1-2ea171fbd885
        data_stream:
          dataset: system.auth
        paths:
          - /var/log/auth*.log

outputs:
  default:
    type: elasticsearch
    hosts: [127.0.0.1:9200]
    api_key: "your-api-key"

receivers:
  httpcheck/httpcheck-6d24bb0d-5349-4714-a7ea-2088abcb928b:
    collection_interval: 30s
    targets:
      - method: "GET"
        endpoints:
            - https://example.com

exporters:
  elasticsearch/default:
    endpoints: [127.0.0.1:9200]
    api_key: "your-api-key"

service:
  pipelines:
    metrics/httpcheck-6d24bb0d-5349-4714-a7ea-2088abcb928b:
      receivers: [httpcheck/httpcheck-6d24bb0d-5349-4714-a7ea-2088abcb928b]
      exporters: [elasticsearch/default]
		

The Integrations catalog offers packages that bundle application-specific configuration and assets. ECS-based integrations include an agent configuration and Elasticsearch and Kibana assets (dashboards, alerts, ingest pipelines). A similar approach exists for OTel-native data collection:

• OpenTelemetry input packages contain the configuration required for the OTel receiver and related pipeline components.
• Content packages contain the corresponding set of assets (dashboards, visualizations, and more) for the application whose data is ingested through the OTel receiver.

The same agent policy can include both ECS-based integrations and OpenTelemetry input packages. When you add an OpenTelemetry input package to your agent policy, it configures the OTel receiver section of the hybrid agent configuration. Once data is ingested into Elasticsearch, the relevant OTel assets are automatically installed when available.

For more details on OpenTelemetry input packages and their configuration, refer to Collect OpenTelemetry data with Elastic Agent integrations.

Depending on your environment, you can use Elastic Agent (as described on this page), the standalone EDOT Collector, or a third-party OpenTelemetry Collector to send OTel data to Elastic. The following table highlights the differences between these options in terms of management capabilities and feature support:

Collector	Fleet central monitoring	Fleet central management	Beat receivers	Logstash exporter	Elastic Defend	Cloud Security	Profiler
Hybrid agent (Fleet-managed)
Hybrid agent (standalone)	Planned
EDOT Collector	Planned	Planned
Upstream OTel Collector	Planned	Planned

Planned indicates that support is on the roadmap and not yet generally available.

receivers:
    filebeatreceiver:
        filebeat:
            inputs:
                - data_stream:
                    dataset: generic
                  id: filestream-receiver
                  index: logs-generic-default
                  paths:
                    - /var/log/*.log
                  type: filestream
    metricbeatreceiver:
        metricbeat:
            modules:
                - data_stream:
                    dataset: system.cpu
                  index: metrics-system.cpu-default
                  metricsets:
                    - cpu
                  module: system