Elastic Agent as an OpenTelemetry Collector

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

This transition is incremental: in 9.3, 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.

×

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 — they do not 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. Upgrading to 9.3 changes the internal runtime of Elastic Agent to use Beat receivers by default, but inputs and outputs remain consistent for integration data.

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:
  debug/default:
    verbosity: detailed

service:
  pipelines:
    metrics/httpcheck-6d24bb0d-5349-4714-a7ea-2088abcb928b:
      receivers: [httpcheck/httpcheck-6d24bb0d-5349-4714-a7ea-2088abcb928b]
      exporters: [debug/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.

It depends on which receiver collected the data.

Data collected by a Beat receiver is written by the Elasticsearch exporter. As with traditional Elastic Agent and Beats, this data is processed by ingest pipelines, schematized, and stored in the appropriate data stream.

Data collected by an OTel-native receiver follows OpenTelemetry semantic conventions. When this data arrives at the Elastic cluster, it bypasses ingest pipelines and is stored directly in an OTel-specific data stream.

Yes. To configure Beat receivers in a standalone EDOT Collector, provide a standard OTel Collector configuration and configure Beat receivers manually as filebeatreceiver or metricbeatreceiver. For example:

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
		

The main difference is management support. Hybrid Elastic Agent can be managed by Fleet. The EDOT Collector does not support Fleet enrollment or central management. Some features, such as Elastic Defend, are only available under Fleet management and cannot be used with the EDOT Collector alone. Refer to the collector type comparison table for a full breakdown.

Standalone Elastic Agent use cases can now be addressed using the EDOT Collector. A practical advantage of the standalone Elastic Agent today is that it can be upgraded to Fleet-managed in the field without having to reinstall it.

The automatic asset installation from OTel content packages currently works only for data ingested by an EDOT Collector or a hybrid Elastic Agent. Data ingested with a third-party OpenTelemetry Collector does not trigger automatic asset installation.

No, the Elastic system support matrix does not change. Where Elastic does not provide Elastic Agent support for a specific operating system, you can deploy a third-party OpenTelemetry Collector supported by that vendor and send data to Elastic. For example, Red Hat provides an OTel Collector for OpenShift that can be configured to send data to Elastic. The same configuration can also be used with the EDOT Collector on operating systems that Elastic supports.