OpenTelemetry: Tips to navigate the sea of observability options
Learn how OpenTelemetry SDKs, OTLP, and the Collector create a vendor-neutral observability pipeline—and where that flexibility adds complexity.
Daniela Miao 
Observability can quickly become a rabbit hole. At Momento, we wanted an efficient, durable system for monitoring customer traffic without closing off our options. That led us to OpenTelemetry (OTel), which defines vendor-neutral observability standards for tracing, metrics, and logging.
This post walks through Momento’s OpenTelemetry journey and the tradeoffs to consider when deciding whether it fits your stack.
My experience with OpenTelemetry started with OpenTracing in 2017. I was working at Lightstep with CEO Ben Sigelman, who co-created OpenTracing to provide an open-source, unifying tracing standard. OpenTracing later merged with Google’s OpenCensus to form OpenTelemetry. It’s rewarding to see how much the community has grown over the last five years and how many companies and individuals now contribute to the project.
How the OpenTelemetry pipeline fits together
The OpenTelemetry ecosystem can be overwhelming when you just want to start coding. Its components are designed for flexibility, so you can use the entire pipeline or only the parts you need.
OpenTelemetry SDKs instrument applications
OpenTelemetry SDKs are the libraries developers use to instrument an application with metrics, traces, and logs. The OpenTelemetry specification defines the standardized API for that instrumentation. Each supported language, including Java, Python, and Go, implements the specification in its own SDK.
Because OpenTelemetry is an open-source, community-driven project, SDK stability varies across language frameworks. You can contribute to an SDK if you need a particular capability, and the OpenTelemetry status page tracks each SDK’s current stability.
OTLP carries the telemetry
After you instrument an application with an OTel SDK, the application emits observability data in a standard wire format called the OpenTelemetry Protocol (OTLP). OTLP defines details such as encoding, transport, and delivery. It uses a Protocol Buffers schema (protobuf) and supports both gRPC and HTTP/1.1 transports, including JSON over HTTP.
The Collector processes and exports data
The OpenTelemetry Collector is an optional intermediate agent that can receive, process, and export telemetry data. In the diagram, applications send data over OTLP to the Collector. The Collector batches or rate-limits that data before exporting it to observability vendors. This layer can help, but it also adds infrastructure and complexity to your stack.
Is OpenTelemetry right for your stack?
The classic answer: it depends.
OpenTelemetry’s biggest advantage is its flexibility and vendor neutrality. As the community has expanded, many observability vendors have announced native OTel support, including Splunk, Datadog, Dynatrace, and Lightstep. Adopting OpenTelemetry gives you the option to change vendors. New players continue to arrive with different features and prices, so keeping that option open can help you remain nimble.
If you’re committed to an existing observability vendor, however, OpenTelemetry may add little value. In that case, you can stay with the vendor-specific library and use the vendor’s official observability pipeline.
At Momento, we adopted OpenTelemetry to keep our options open. We wanted to move quickly without locking ourselves into a particular vendor, and OpenTelemetry made that choice a two-way door. Once we set up the SDKs and Collector, we could evaluate multiple vendors concurrently by broadcasting OTel data to all of them. Our developers can use several observability systems at the same time and compare their user experiences side by side. This allowed us to choose a vendor that best suits our current budget and needs while retaining the option to switch as those needs evolve.
That flexibility comes with costs. The OpenTelemetry ecosystem is still young and constantly evolving. We have encountered breaking changes when upgrading the SDK and Collector, so you should factor that dynamic into your decision.
Observability is a first-class citizen at Momento because it helps us maintain a high bar for availability and performance. Building on OpenTelemetry’s flexibility, we provide customers with extensive visibility to help them meet their own observability goals. Before adopting OpenTelemetry, check with the OpenTelemetry community on its current plans.
