Nima Rezainia

Elastic Agent now runs as an OpenTelemetry Collector: Less memory overhead, zero config changes

Elastic Agent 9.3 sends logs, metrics and traces through one OTel Collector pipeline, running Beats integrations alongside native OTel sources in a single Fleet-managed agent.

Elastic Agent 9.3 uses less memory and accepts data from any OpenTelemetry-compatible (OTel-compatible) source out of the box. Under the hood, the old Beats subprocess architecture has been replaced by a single OTel-native pipeline for logs, metrics, and traces, built on the Elastic Distribution of OpenTelemetry (EDOT) Collector. Your existing integrations, dashboards, Fleet policies, alerting rules, and ingest pipelines all work without changes.

What changed in Elastic Agent 9.3: A native OTel Collector under the hood

Previously, Elastic Agent acted as a supervisor process, spinning up Beats-based subprocesses, such as Filebeat or Metricbeat. From 9.3 onward, that architecture has been replaced. Elastic Agent itself is now built on the EDOT Collector, turning it into a first-class OTel Collector under the hood while preserving its original functionality.

Key benefits of this architectural shift include:

  • Reduced footprint: Fewer subprocesses mean significantly less memory overhead and a simpler deployment model. In future releases, this footprint will be even further reduced.
  • Unified telemetry pipeline: Logs and metrics flow through a single, standards-based OTel pipeline, as do traces.
  • Ecosystem interoperability: Elastic Agent can now receive data from any OTel-compatible source out of the box. It can also be configured to emit to OTel-compatible destinations.
  • Aligned with the OTel ecosystem: As the OTel ecosystem matures with new receivers, processors, and exporters, Elastic Agent deployments gain access to those capabilities automatically.

When you deploy or update Elastic Agent from version 9.3 onward, you're deploying an OpenTelemetry Collector. EDOT is the technology foundation; Elastic Agent is the product.

How existing Beats configurations run inside the OTel Collector pipeline

Elastic has introduced Beats Receivers, which are Beat inputs and processors that execute natively inside the new OTel Collector pipeline. For your teams and customers, this means:

  • Existing elastic-agent.yml configurations require no modification.
  • Fleet-managed agents automatically translate policy configurations into OTel format internally.
  • All integrations, dashboards, ingest pipelines, and alerting rules continue to function exactly as before.
  • Data written via Beats Receivers lands in the same data streams as always.

Upgrading to 9.3 is transparent because it uses the same inputs and produces the same outputs.

Running Beats and OTel Collector pipelines in one Elastic Agent

The new Elastic Agent is a collector capable of simultaneously running traditional Beats-based collections alongside native OTel pipelines, all in a single deployment. One agent policy can collect Elastic Common Schema–schematized (ECS-schematized) data via Beats Receivers and ingest native OpenTelemetry Protocol (OTLP) data from OTel-instrumented applications and infrastructure. This same agent policy can apply OTel processing stages across all telemetry before export.

OTel integrations from Elastic's catalog can be added to any agent policy. When native OTel data is ingested, Elastic automatically installs the relevant dashboards and alerts, in addition to necessary content packs, without any manual setup.

What's the relationship between Elastic Agent and EDOT?

You may be familiar with EDOT, the Elastic Distribution of OpenTelemetry Collector, as a stand-alone product. With this architectural change, EDOT is the technology foundation that now powers Elastic Agent, not a separate product that users need to track or deploy independently.

Going forward, Elastic Agent is the supported, Fleet-manageable, fully featured product. A stand-alone deployment remains available for specific niche scenarios (environments where the full version of Elastic Agent cannot be installed), but it isn't the recommended path for the vast majority of users.

Elastic Agent deployment options: Fleet-managed vs. stand-alone

Fleet-managed Elastic AgentStand-alone Elastic Agent
Fleet lifecycle managementYesCan enroll into Fleet in-field without reinstallation
Beats ReceiversYesYes
Elastic DefendYesNo
Cloud SecurityYesNo
Profiler supportYesNo
OTel-native pipelineYesYes
Best forMost deploymentsEnvironments where full Elastic Agent cannot be installed or management is handled by other tools

Do I need to change anything when upgrading to Elastic Agent 9.3?

For users running Elastic Agent today, upgrading to 9.3 requires no changes to configurations or integrations, and no changes to workflows. For customers evaluating OTel adoption, Elastic Agent now provides a fully supported, production-ready OTel Collector with Fleet management and rich integrations, along with Elastic's full support matrix, and none of this requires a separate OTel deployment.

With Elastic Agent 9.3, Elastic's data collection is fully OpenTelemetry-native. Elastic Agent is now an OpenTelemetry Collector. Everything you have today still works, and you also get all the capabilities of OTel.

Share this article