CollectorCtrlEvery Vendor Supports OTLP. None Ship Each Other's Exporters.
What's really running in your agent and gateway tiers, and what it would take to switch backends next year.
Somewhere in almost every OpenTelemetry rollout there's a slide that says: “We've standardized on OpenTelemetry. We're vendor-neutral.”
It's easy to see why. OTLP is open, every big backend accepts it, and even your vendor's own collector ships an OTLP exporter. So where's the lock-in?
In our last post we argued that owning the control plane is what makes neutrality real. This time we want to test that slide against how teams actually run telemetry today, using nothing but the vendors' own documentation.
To keep it simple, we'll stick to four vendors most of you run or evaluate: Datadog, Dynatrace, Elastic and Grafana Labs. All four were named Leaders in the July 2026 Gartner® Magic Quadrant™ for Observability Platforms. And we'll stay strictly on the data plane: agents, collectors and instrumentation. Dashboards, alerts and keeping your data consistent deserve their own post (that one's about semantic registries).
Everyone runs the same shape
Pick any of these vendors and their docs land you in roughly the same place: a light agent on every host or node, and a central gateway tier that batches, samples and forwards to the backend.
The shape isn't the problem. The real question is which binary is sitting in those two boxes, because that decides how hard it is to leave.
Three kinds of data plane
In practice, the agent and gateway tiers run one of three things:
The same upstream collector, rebuilt by a vendor with a hand-picked component list, a support contract, and defaults tuned for their backend.
Most large estates run all three at once: vendor agents on older VMs, a vendor distribution on newer Kubernetes clusters, and a platform team quietly running contrib somewhere. Option B is the one that gets mistaken for neutrality, so let's open the box.
What's actually in the box
Here's every vendor distribution's exporter list, mapped against the places you might want to send data. We've added upstream contrib at the bottom for comparison. Click any cell to see what it means and the evidence behind it.
| You run ↓ / You want to send to → | Datadogdatadog | Elasticelasticsearch | Grafana stackprometheus · loki | Splunksplunk_hec | Dynatrace / any OTLPotlp · otlphttp |
|---|---|---|---|---|---|
| DDOT CollectorDatadog | |||||
| Dynatrace OTel CollectorDynatrace | |||||
| EDOT CollectorElastic | |||||
| AlloyGrafana Labs | |||||
| otelcol-contribUpstream, for reference |
There's no elasticsearch exporter in DDOT Collector. To get Datadog's collector talking to Elastic, you have three options:
“this build process must be repeated each time you update the Agent version”Datadog docs ↗
Three things jump out:
None of this is bad behaviour. A vendor supports what it tests, and that's fair. But it means “our collector supports OTLP” is a statement about one exporter, not about portability.
“Fine, we'll just use OTLP.” Not so fast.
OTLP gets the data there. It doesn't guarantee the data lands the same way. A few examples straight from the docs:
Each one is a small fix on its own: a processor here, a batch-size change there. Across a fleet of thousands of collectors, though, “small” adds up to a project.
So, how neutral are you really?
This is the question leadership actually cares about: if we had to move backends next year, is it a config change or a re-platforming? Find your setup below and click it to see what moving would involve.
- 1Swap the exporter and credentials at the gateway tier.
- 2Handle the new backend's quirks in processors (temporality, limits, attribute names).
- 3Roll out to gateways only. Agents keep sending OTLP and never notice.
Nobody gets five dots. Even the most open setup still has to deal with the new backend's quirks.
Switch to the Instrumentationtab and the picture gets worse. Collectors are the visible half. Instrumentation is where migrations really slow down, because it touches every application team. Changing a collector is a platform team's job. Changing a tracer means a redeploy for every service you own.
The pattern is the same at both layers: the API may be open, but the default path isn't.
“But we have a telemetry pipeline”
Plenty of organizations add a pipeline layer between agents and backends, using products like Cribl, Edge Delta and others, specifically to reduce lock-in risk. It's a reasonable move, so let's be fair about both sides.
- +A routing point you control. Dual-writing to old and new backends during a migration gets much easier.
- +One place for filtering, reduction and enrichment.
- +Real value if the same streams also feed your SIEM, archive or data lake.
- −Another licence, often priced on volume. Telemetry volume only goes one way.
- −Another tier to run: HA, upgrades, capacity, its own config language and skills.
- −Egress on raw data if the reduction happens in someone else's cloud.
- −It doesn't touch the edge. Vendor agents and SDKs are still on your hosts and in your apps.
The egress point is easy to miss, so here it is visually. Toggle between the two and watch what leaves your network:
(you pay egress on this)
You ship the raw volume out first, then throw 60% of it away. You paid egress on the part you discarded.
Illustrative numbers; real reduction ratios vary a lot. Many pipeline products, Cribl for example, also offer customer-managed (hybrid) workers that run inside your network.
And the licence question deserves an honest spreadsheet. A pipeline licence is an ongoing premium to insure against a migration you might do once every few years. Over three to five years, how does that premium compare to the one-time professional-services bill for the migration itself? We can't answer that for you. Prices vary too much to quote fairly. But it's worth asking before the pipeline becomes the neutrality story.
A pipeline can be the right call. It just isn't neutrality on its own. It's another dependency, chosen on purpose.
Before you put “vendor-neutral” on the slide
We don't think vendor neutrality is a myth. But right now, for most teams, it's closer to a hope than a fact. OTLP is the foundation. It isn't the house.
Next time a vendor tells you they're “fully OpenTelemetry-native”, these are worth asking. Tick the ones you can already answer with confidence:
We'd genuinely like to hear the answer, from vendors and from teams who've been through a migration.
Sources & evidence (20 links)
Missed part 1? If You Don't Own the Control Plane, You're Not Vendor-Neutral →
Gartner and Magic Quadrant are registered trademarks of Gartner, Inc. and/or its affiliates. Component lists reflect each vendor's public documentation as of October 2026.