The practical argument for OpenTelemetry is not that it produces better telemetry than a vendor agent. It is that the instrumentation lives in your code under a neutral standard, so changing observability vendors becomes a configuration change rather than a re-instrumentation project. Anyone who has migrated between monitoring vendors understands why that matters.
Getting there is straightforward if you do it in the right order and avoid one expensive mistake.
What changed in 2026
- Automatic instrumentation coverage broadened. Language agents and libraries covered more frameworks out of the box, reducing how much manual work adoption requires.
- Semantic conventions stabilized further. Standard attribute names across HTTP, databases, messaging, and generative AI meant dashboards ported between backends more cleanly.
- Collector deployment became the default recommendation. Exporting directly from applications gave way to routing through a collector for sampling, redaction, and vendor flexibility.
- Cost incidents made cardinality a first-class concern. Enough teams generated surprise bills from unbounded attribute values that guidance shifted toward explicit cardinality review.
The order that works
| Step |
Effort |
Value |
| 1. Enable automatic instrumentation |
Low |
Immediate trace coverage of HTTP and database calls |
| 2. Deploy a collector |
Low |
Central control over sampling, redaction, and routing |
| 3. Propagate context across services |
Low |
Traces span service boundaries instead of fragmenting |
| 4. Add correlation identifiers to logs |
Low |
Logs join to traces |
| 5. Add manual spans at real gaps |
Medium |
Detail where automatic coverage is thin |
| 6. Tune sampling |
Medium |
Cost control without losing the interesting traces |
| 7. Custom metrics |
Medium |
Business-level signals |
Automatic instrumentation first, always. It delivers most of the value for a fraction of the effort, and it shows you where the gaps actually are — which is a much better guide to where manual spans belong than guessing beforehand.
Context propagation deserves attention because it is where multi-service tracing succeeds or fails. If service A does not pass trace context to service B, you get two disconnected traces instead of one, and the whole point evaporates. Automatic instrumentation usually handles this for standard HTTP clients; custom transports and message queues frequently need explicit work.
The cardinality trap
Cardinality is the number of distinct combinations of attribute values. On traces it is mostly harmless — each span is stored individually. On metrics it is multiplicative, because each unique combination creates a separate time series.
Adding a user identifier as a metric attribute creates one time series per user. Adding a request identifier creates one per request. Bills from this are not slightly higher; they are orders of magnitude higher, and the failure is silent until the invoice arrives.
The rule is simple: metric attributes must be bounded and low-cardinality — status code, region, service name, endpoint pattern rather than the actual URL with identifiers in it. High-cardinality detail belongs on spans and log events, where the storage model handles it.
Tail sampling in the collector is the other cost lever worth setting up. Rather than sampling randomly at the source, tail sampling decides after seeing the complete trace — so you can keep all errors and slow requests while sampling the fast successful majority heavily. That preserves exactly the traces you would want during an incident, and it interacts well with the structured events described in structured logging guide.
Common mistakes
- High-cardinality metric attributes. The most expensive mistake in the whole ecosystem.
- Exporting directly from applications. Works, and leaves you with no central place to sample or redact.
- Skipping context propagation. Produces fragmented traces that answer nothing.
- Hand-instrumenting before enabling automatic coverage. Duplicated effort and inconsistent attribute naming.
- Head sampling only. Random sampling at source discards errors at the same rate as successes.
FAQ
Does OpenTelemetry replace my monitoring vendor?
No. It is the instrumentation and transport layer. You still send the data to a backend, and the point is that you can change which one.
What is the performance overhead?
Typically small — a few percent for automatic instrumentation in most languages. Verify under load rather than assuming, particularly in very high-throughput services.
Should I use it for logs too?
Log support has matured and works well when you want a single pipeline. Many teams keep existing log shipping and use OpenTelemetry for traces and metrics initially.
Can I run it alongside an existing vendor agent?
Usually, though duplicate instrumentation causes confusing double-counted spans. Plan a migration rather than a permanent overlap.
Where to go next
For the log side, read structured logging guide. For tracing across a federated API, GraphQL federation, and for AI-specific tracing, AI agent observability.