If You Don't Own the Control Plane, You're Not Vendor-Neutral

Every observability platform sales deck says the same thing now: "We're vendor-neutral — we support OpenTelemetry." And it's not a lie, exactly. OpenTelemetry really did make telemetry data portable. But portability of data is not portability of operations — and the gap between the two is where your exit strategy lives or dies.

This post is an honest look at that gap. No product pitch at the end — just the architecture question I'd want my team to answer before signing anything.

First, Be Fair to the Vendors — Their Leverage Is Rational

Here's the uncomfortable truth that usually gets skipped in "open vs. proprietary" debates: if you're an SRE or observability team, using the vendor's distribution is often the right call.

When you run Splunk's distribution, Elastic's EDOT, or Datadog's collector, you get a binary the vendor has tested end-to-end, security-patched on a schedule, and — most importantly — fully supported. File a ticket, and the vendor owns the whole pipeline, receiver to exporter.

Run a custom build or upstream contrib instead, and watch what happens to your support tier: best effort. The vendor will shrug at components they don't ship. Your team now owns every breaking change, every contrib processor interaction, every upgrade.

That support asymmetry is not villainy — it's a rational business model. But recognize what it is: leverage. The vendor's leverage is support; the question this post is really about is what leverage the customer has in return.

The Leverage You Actually Have

If the vendor's leverage is the supported distribution, the customer's counter-leverage is to separate the management layer from the data plane:

• Use the vendor distribution if it serves you — you paid for support, take it.
• But manage that distribution through a control plane you own, one that can deploy YAML, swap binaries, and upgrade collectors fleet-wide — over open OpAMP, against any collector build, from any vendor or none.

That combination — vendor binary, neutral brain — means the distribution is a replaceable component, not an identity. The day the vendor's pricing, roadmap, or acquisition changes, you swap binaries instead of running a multi-quarter migration program. The control plane is the exit door, and it works before you need it, not after.

What "Vendor-Neutral" Actually Looks Like — An Honest Scorecard

Let's walk through the setups architects actually propose, and grade them on operational neutrality — meaning: how much pain is migration, really, at 3 a.m., under deadline?

Setup 1 — Vendor agents + open-source gateway

The classic: vendor A's distribution on all your hosts, open-source gateway collectors in front with every exporter you might need. Genuinely good setup. Telemetry porting is a gateway config change.

Now migrate from vendor A to vendor B. The gateways flip easily. But your agents are still vendor A's distribution, managed by vendor A's control plane — and vendor B won't fully support a binary they don't ship. Even if the YAML reconfigures cleanly, there's a structural problem: an OpAMP agent typically maintains one live OpAMP connection. Your hosts are enrolled with vendor A. Re-enrolling them with vendor B means uninstall, reinstall, re-enroll — and that's assuming vendor B's fleet management speaks plain OpAMP and has no proprietary enrollment requirements of its own. That's not a config change; that's a fleet re-platforming. And we've only discussed collectors — your instrumentation agents are a second, bigger program.

Setup 2 — "We'll just use Ansible"

Not tied to any vendor — problem solved, right? Operationally, you've traded vendor lock-in for configuration sprawl.

Think through day two. Separate YAML for DB servers, app servers, syslog hosts, EC2, Azure VMs, polling APIs. Add one processor, one redaction rule, one new log source — and you're forking YAMLs again. Now you need GitOps discipline, precedence rules, override semantics, drift detection, and an audit trail proving each collector runs the YAML it should. In an enterprise, "which YAML has this config?" is a question nobody can answer from memory.

And there's an organizational tax: Ansible usually lives with the infrastructure/SRE team. So the observability engineer — the person who knows the YAML — files tickets, waits for rollout windows, and validates secondhand for every change. Migration from vendor A to B under Ansible means re-authoring playbooks and runbooks under deadline, running parallel pipelines while you burn double ingestion cost, and hoping nothing drifts in between.

Should a backend change hurt this much? If migration were easy, professional-services catalogs would stop listing "onboarding assistance and migration cadence" as a revenue line. They haven't.

Setup 3 — Upstream collector or your own distribution

The purest strategy: no vendor distribution at all. Full control, no lock-in. Also the heaviest operational load — you're now the distribution vendor. Tracking releases, breaking changes, security fixes, YAML drift, agent sprawl. And if you look at the OpAMP ecosystem honestly: the protocol is maturing, but the open-source reference implementations still leave orchestration, insights, and upgrade workflows as your problem.

This is precisely where a neutral control plane matters most — because the teams running custom builds are usually the ones building in-house observability stacks on top, including their own AI agents. And those agents are only as good as the pipeline feeding them: which collectors are emitting log storms, which patterns repeat, which collector silently stopped exporting, which one is dropping data? If your telemetry pipeline has a discrepancy, your AI agent is confidently wrong. A centralized control plane stops being a convenience here — it's infrastructure for everything downstream.

The Coralogix Example, Told Accurately

Take a real pattern. You're on Splunk's distribution of the OpenTelemetry Collector — a solid logging platform — and you're evaluating a move to Coralogix.

Your sales and solutions contacts will correctly say: "We're vendor-neutral, we accept OTLP." True. Generic OTLP will deliver data.

But Coralogix's own exporter documentation tells you to set application_name and subsystem_name, and their platform docs state those two metadata fields are required to organize your data — the metadata that powers their data tiers, TCO policies, and application-level features. Send via generic OTLP without that enrichment and your data lands in the platform without the structure its features assume. So you deploy the Coralogix exporter — which Splunk's distribution doesn't ship, because vendor distributions don't ship their rivals' exporters. That's how "we support OTLP" and "your migration is a multi-week collector redeployment" are both true at once.

Nobody lied to you. There was just a soft lock-in designed into the gap between the protocol and the platform — and no easy exit door on the far side.

The Part Nobody Has Fully Priced In Yet: AI Agents

One more force is coming, and it makes the control plane question more urgent, not less.

In an AI-agent-driven observability operation, your agents will need to inspect collector health, diagnose pipeline issues, and propose config changes. Now answer this as an architect: would you give an AI agent direct access to your VMs and clusters to troubleshoot collectors?

Your security team will flag that 100% of the time — and they'll be right. But flip it: what if there's an interface in between? Token-scoped RBAC over telemetry-pipeline operations only, proposed changes gated behind human approval, every action immutable and audited, running on-premises rather than as someone's SaaS.

That's a control plane. Not a nice-to-have — the security boundary your future AI operations run against. The teams that have one will let their agents operate with confidence; the teams that don't will either block AI ops entirely or route around security, which is worse.

The Question to Take Back to Your Architecture Review

You don't have to buy anything — ours or anyone's. But if your strategy document says "vendor-neutral," ask one question:

If the answer involves Ansible playbooks, parallel-run timelines, and professional services, you have portable data and an anchored operation. The data plane was never the lock-in risk. The control plane is — and it's the one layer of the stack you're allowed to own outright.

Own it on purpose.