← Back to blog
// blog · post

Why OTLP changes the observability stack

5 min read · opentelemetry · otlp · observability

OpenTelemetry has been quietly reshaping observability for years, and OTLP, the wire format OTel uses to ship telemetry, is the part that actually changes how engineering teams build their pipelines. Pick any meaningful telemetry decision in the next two years and OTLP will be in it.

The shape of the problem

Most production telemetry stacks accumulated by accretion. Application code emits via a vendor SDK; metrics go to one backend; traces to another; logs to a third. Each new tool added an agent or a sidecar. Instrumentation surface area grew faster than the value it returned, and switching costs locked teams into vendors they had outgrown.

OpenTelemetry's bet is simpler: instrument once, export anywhere. OTLP is how that bet pays off in practice.

What OTLP actually is

OTLP is a Protocol Buffers schema and transport, gRPC or HTTP/protobuf, with JSON encoding as a fallback, for shipping the three pillars of telemetry: traces, metrics, and logs. It defines:

  • A resource model, process, host, service.name, k8s pod, etc.
  • A signal model, span, metric, logRecord, each with attributes typed against the OpenTelemetry semantic conventions.
  • An export envelope, batched, optionally gzipped, with backpressure semantics.

The protocol is the same whether you're shipping from a Go service, a Rust SDK, a JS frontend, or a sidecar collector. There is no separate "trace OTLP" or "metric OTLP", there is one format that carries all three.

What changes for an engineering team

Three things shift, and each is load-bearing:

One agent in the path. The OpenTelemetry Collector terminates OTLP from your apps and re-exports to whatever backends you currently use, Tempo, Loki, Mimir, Jaeger, Datadog, Honeycomb, an S3 bucket. Adding a new backend doesn't require redeploying every service. It's a collector config change.

Vendor-neutral instrumentation. Your app code emits OTLP. If you migrate from one APM to another, the SDKs don't change. Migration becomes a routing problem rather than a re-instrumentation project, which is to say, a problem you can solve in days instead of quarters.

Logs are first-class. Logs were the late arrival in OTel. With OTLP you correlate a span with its log records by trace_id/span_id natively, instead of bolting it on via parser config in your log aggregator.

Where the win compounds

The Collector is where OTLP earns its keep. A typical pipeline looks like:

app  →  OTLP/gRPC  →  collector  →  [tail-sample, redact, enrich, batch]
                                  →  exporters → traces backend
                                                metrics backend
                                                logs backend

A few practical patterns this enables:

  • Tail sampling without app changes. Drop 90% of healthy traces at the collector, keep 100% of errored ones, do it without touching service code.
  • PII redaction at egress. Strip headers, mask fields on the way out. The app instruments richly; the collector enforces policy.
  • Cost control. High-cardinality metrics filtered or aggregated before they reach a paid backend.

Caveats worth pricing in

OTLP is not a panacea.

  • SDK maturity varies. Go, Java, Python, JS are solid. Some others lag on auto-instrumentation coverage.
  • Cardinality is still your problem. OTLP doesn't change the math of "every label is a series." Plan accordingly.
  • The collector is now critical infra. It needs the same care as any data plane component, monitoring, capacity planning, deploy hygiene.

How to start

If you're greenfield: start with OTLP. Use the SDK for your language, deploy a single collector, point exporters at whatever you already have.

If you're not: pick one signal, usually traces, and run OTel alongside your existing instrumentation. Move services over as they ship. The compounding value shows up around the third or fourth migrated service, when the collector becomes the thing you reach for first whenever the question is "where do I send this telemetry."

The long-term shape of an observability stack is converging on one wire format and one collector tier. Investing in OTLP now is investing in the place the industry is going regardless.

If you're rethinking your telemetry stack, we'd like to hear about it.