Uncovered: The Hard Truth About OpenTelemetry's Vendor Neutrality
We still hear, "OpenTelemetry (OTel) is vendor neutral so you can switch vendors any time you want to." This is akin to saying because the vCard format exists, it's easy to switch from iOS to Android. Yes, your core data will ultimately be portable, but you'll be missing a lot of other things.
This doesn't make vendor neutrality moot. Switching vendors isn't like waving a magic wand, but it is much easier thanks to OTel. We’ll cover some of the challenges and pitfalls, and offer best practices to make this process as pain-free as possible. We’ll discuss:
- OTel APIs/SDKs ease tool migration: helpful but not foolproof
- OTel Collector enables multi-tool simulcast, ideal for vendor "bake-offs"
- OpenTelemetry Protocol (OTLP): OTel’s standout feature
- What's transferrable between vendors vs what's not
Attendees will come away with an understanding of what OTel vendor neutrality means, so they can make informed decisions when considering switching to or adopting new tooling.
Tool choices can shift with reorganizations or mergers. The fact that OpenTelemetry (OTel) is vendor neutral is a superpower…but what exactly does that vendor neutrality actually mean?
OTel is designed such that even if you want to swap out OTel’s official SDK for your own, you still can, without breaking anything, as long as you implement the API. The OTel Collector is designed so that you can ingest telemetry data from multiple data sources and multiple formats, and export data using OTLP (OpenTelemetry Protocol) to any OTLP-compatible backend.
The ability to mix-and-match OTel-compatible tools, and to pick and choose pieces of OpenTelemetry to adopt, means that build-vs-buy is no longer a binary choice, but a spectrum of choice. End-users are empowered to leverage multiple tools simultaneously, if that best suits their needs. Vendors are empowered to provide ergonomic enhancements on top of open standards.
OpenTelemetry is vendor neutral on data ingest. This means that you can point your OTel Collector to two or more OTel-compatible backends. But once the data is ingested…
Not all backends may support all 3 “main” OpenTelemetry signals (traces, logs metrics). For example, Jaeger only ingests Traces. Prometheus only ingests metrics.
Tools may visualize OTel signals differently
Dashboards and dashboard query languages vary across tools. For example, some use PromQL, some use their own proprietary query language, and some use SQL.
Some tools optimize on structuring OTel data differently, which can affect pricing when switching to another tool. For example, some vendors encourage sampling. Some discourage sampling. Some encourage enhancing traces with attributes. Some may encourage adding span events to traces.
The power of choice means that users can assemble the solution that works for them in pursuit of Observability's true promise: the ability to ask useful questions, get meaningful answers, and enable practitioners to act effectively on what they’ve learned.
This talk will unpack OpenTelemetry’s vendor neutrality, and help decision makers and practitioners alike understand what’s truly vendor-neutral and what’s not, helping them select the right tools for their own purposes, and to help them avoid those nasty surprises that come in the form of giant bills, giant learning curves, and interminable migration timelines.
Josh is a seasoned software developer with over a decade of experience, specializing in a broad range of topics including operations, observability, agile methodologies, and accessibility. His passion for technology is matched by his enthusiasm for sharing knowledge through public speaking. Currently, Josh serves as a Developer Advocate for Altinity, where he creates educational content on ClickHouse and OpenTelemetry, and he is a contributor to the OpenTelemetry project.
LinkedIn