Observability is not OpenTelemetry

OpenTelemetry is everywhere right now. Every observability blog post, every CNCF talk, every vendor pitch mentions it. And it's genuinely good , a vendor-neutral standard for traces, metrics, and logs is long overdue.

But there's a pattern I keep seeing: teams instrument their services with OTel, ship data to a backend, and then call themselves observable. They're not. They've instrumented. Those are not the same thing.

Most teams shipping OTel today are collecting telemetry. That's not the same as being observable.

Here's a failure mode worth naming: a service emits traces, metrics, and logs. Everything lands in the backend. The team closes the instrumentation ticket. Then an incident hits, latency spike in checkout, root cause somewhere across three services — and nobody can answer "which request crossed which service at what time." The data exists. The correlation doesn't.

This talk is about that gap: the difference between having data and being able to answer questions you didn't know you'd need to ask.

OTel's scope is data collection and transport. It standardizes how you emit and ship signals. What it doesn't standardize: how you model your data for high-cardinality queries, how you correlate traces across asynchronous boundaries, or whether your backend can do fan-out exploration without a pre-built dashboard. Those gaps are where incidents actually live.

I'll walk through three patterns that look like observability but aren't,  trace coverage without baggage propagation, metrics without exemplars, log volume without structured context and show what each gap looks like in production, and draw the line between where OTel ends and backend/query design begins.

OTel is a telemetry standard. Observability is a system property. Shipping OTel doesn't make your system observable.

Trace coverage without baggage propagation means you have spans but no correlation across async boundaries.

Metrics without exemplars mean you can see latency is high but can't tie it to a specific trace or deployment.

Log volume without structured context means events exist but user_id and request_id aren't consistent fields you can query.

A five-question diagnostic to tell whether your system can answer questions you didn't know you'd need to ask before the next incident forces the answer.