Elastic vs. OTel Collector

Five years ago this comparison was two camps. Elastic had Beats, then Elastic Agent and Fleet, with a schema (ECS) and a management console built for one destination. The OpenTelemetry Collector was the neutral alternative. You picked a side.

That framing is out of date, and being precise about why is most of the decision. Elastic contributed ECS into the OpenTelemetry semantic conventions, ships its own distribution of the OpenTelemetry Collector and SDKs (EDOT), and accepts OTLP natively as an ingest path. Elastic Observability the backend is happy either way. The choice that remains — and it is a real one — is about the collection layer: Elastic Agent managed by Fleet, or the OpenTelemetry Collector managed by a control plane. They differ in what they are good at, and the difference is structural, not a feature race.

If your question is “how do I move off Elastic Agent onto collectors”, that is a migration and it is covered step by step in migrating Elastic Agent to OpenTelemetry. This post is the comparison you read before deciding whether to.

What each is actually optimised for

Elastic Agent + Fleet is optimised for getting a known source into Elastic with the right shape, fast. Its integrations are the asset: pick “nginx” or “Windows Event Log” or “AWS CloudTrail” in Kibana, and you get the collector config, the ECS field mapping, the ingest pipeline, the dashboards and often the alert rules — as one installable unit, managed centrally by Fleet, versioned as a package. That is a genuinely mature catalogue and nothing in the OpenTelemetry world matches its breadth of finished integrations.

The OpenTelemetry Collector is optimised for owning the processing layer and not being tied to a destination. Receivers exist for most of the same sources, but you assemble the pipeline: what to parse, what to mask, what to sample, where to send. The value is that the assembly is yours, portable, and can fan out to several backends. The cost is that the assembly is also yours to do.

That is the whole comparison in two sentences. Everything below is consequence.

Where they genuinely differ

• Schema. Elastic Agent emits ECS, which Kibana understands completely. The Collector emits OpenTelemetry semantic conventions — which ECS is now converging into, but the two are not identical today, and a Kibana dashboard built on ECS fields may need mapping when fed OTel-shaped data. This gap is closing; it is not closed.
• Management. Fleet manages Elastic Agents — enrolment, policy, upgrades — from Kibana, and only Elastic Agents. The Collector speaks OpAMP, which is a protocol rather than a product: the management server is something you run or buy. Fleet is finished and single-purpose; OpAMP is open-ended and needs a control plane above it — OpAMP explained.
• Processing before egress. Elastic’s model does most transformation in ingest pipelines on the Elastic side, after the data arrives. The Collector does it in the agent or a gateway, before egress. For cost that is the difference between paying to ingest then discarding, and discarding then paying to ingest — observability cost starts at the edge. For compliance it is the difference between masking on the host and masking in the cluster.
• Multiple backends. Elastic Agent sends to Elastic. It can be coaxed elsewhere via Logstash, but the design assumption is one destination. The Collector fans out by design — one strategy, multiple backends. If Elastic is your only backend this does not matter; if it is one of three, it is the deciding factor.
• Lock-in. An estate instrumented with Elastic APM agents and collected by Elastic Agent is a fine estate — until the renewal. The OTel path keeps instrumentation and collection as open standards, with Elastic as a replaceable consumer. Elastic’s own EDOT work is an acknowledgement that customers now require this.

What EDOT changes

The Elastic Distribution of OpenTelemetry is Elastic’s curated build of the Collector plus SDKs, tuned and supported for sending to Elastic. It is a real product, not marketing, and it changes the picture in one specific way: you can adopt the OpenTelemetry model — Collector, OTLP, semantic conventions — while keeping Elastic as backend and keeping a vendor on the hook for support.

What it does not change: EDOT’s Collector is still a Collector. It needs the same fleet discipline — config as policy, drift detection, health-gated rollouts — as any other, and Fleet does not manage it. If you pick EDOT you have chosen the OTel side of this comparison with an Elastic-flavoured binary, and the operating model that comes with it.

When to choose which

If you…	Lean toward
Run Elastic as your only backend and value finished integrations over flexibility	Elastic Agent + Fleet
Ship mostly well-known sources (Windows, nginx, cloud audit logs) and want dashboards on day one	Elastic Agent + Fleet
Run two or more backends, or expect to	OpenTelemetry Collector
Need masking and volume reduction before data leaves the host	OpenTelemetry Collector
Have application teams already on OTel SDKs	OpenTelemetry Collector (or EDOT)
Want the OTel model with a support contract and Elastic as the destination	EDOT Collector
Have a mixed estate — Elastic Agents on some hosts, Collectors on others	Both, managed from one place

That last row is the common real-world answer, and it is only tolerable if one control plane sees both — otherwise it is two consoles, two drift surfaces and two answers to “what is running on that host”.

The honest summary

Elastic Agent is the better product: more integrations, more finished content, one console. The OpenTelemetry Collector is the better layer: portable, processing before egress, backend-neutral, and the thing every vendor — Elastic included — now ships a distribution of. Choose the product if Elastic is the whole picture. Choose the layer if it is part of one. And do not let the choice be made by default by whichever agent happened to be installed first.