OpenTelemetry: Unifying Logs, Metrics, and Traces
Actualizado: 2026-05-03
For years, observability in distributed systems meant three separate tools: Prometheus for metrics, Jaeger/Zipkin for traces, Elasticsearch/Loki for logs. Each with its agent, protocol, format. OpenTelemetry[1] (OTel) is the CNCF[2] project unifying the three signals under a single standard, and it has reached enough maturity to be the default choice for new projects.
Key takeaways
- Before OTel, instrumenting an application required three libraries, three formats, and three configuration models; changing backends meant re-instrumenting.
- OTel proposes one instrumentation library, one transport protocol (OTLP), and interchangeable backends.
- Traces are GA since 2021; metrics are GA since 2023; logs are in beta but already worth using for new projects.
- The OpenTelemetry Collector is the most underrated component: it enables backend changes without touching application code.
- The practical recommendation is auto-instrumentation for basic coverage plus manual instrumentation for critical business spans.
The problem it solves
Before OTel, instrumenting an application required:
- Metrics: Prometheus client library, export at
/metrics. - Traces: Jaeger/Zipkin library, configure sampler.
- Logs: structured-format library, ship to stdout or backend.
Three libraries, three formats, three configuration models. If you changed backends, you re-instrumented. If you wanted trace-log correlation, you implemented it manually.
OTel proposes: one instrumentation library, one transport protocol (OTLP), and interchangeable backends.
The state of the three signals
Each signal has different maturity:
- Traces: GA since 2021. Stable and production-ready in every major language. Integration with Jaeger, Tempo, Datadog, New Relic, Grafana Cloud — trivial.
- Metrics: GA since 2023. Stable but with backend ecosystem still transitioning. Prometheus isn’t OTel-native but has an OTLP receiver adapter.
- Logs: in beta. Standard defined, implementations maturing. For new projects already worth it; for migrating existing pipelines, waiting 6-12 months can pay off.
Typical architecture
A typical OTel deployment has three layers:
- SDK instrumenting the application (auto or manual, depending on language).
- OpenTelemetry Collector as local or regional proxy — receives, processes (sampling, filtering, enrichment), and exports.
- Backends receiving the data: Prometheus, Grafana, Jaeger, etc.
The Collector is the most underrated component. It lets you change backends without touching application code, add metadata, apply dynamic sampling, and aggregate metrics before sending — all in declarative YAML.
Auto-instrumentation vs. manual
Two paths, each with its profile:
- Auto-instrumentation: agents that inject instrumentation without touching code. For Java (with Javaagent), Python, .NET, and Node.js, it works notably well: you get HTTP, DB, and gRPC traces out-of-the-box.
- Manual: explicit
tracer.start_span(...)calls in code. More work, but captures business semantics that auto can’t infer — “process_payment” as its own span.
Practical recommendation: auto for basic coverage + manual for critical business spans.
Integrations with existing stack
OTel doesn’t force you to abandon what already works. Three common integrations:
- Prometheus exporter: the Collector can expose metrics in Prometheus format, so Grafana keeps working unchanged.
- Jaeger backend: OTLP → native Jaeger. No historical data migration, just redirect new flows.
- Promtail/Fluent Bit: you can complement OTel logs with existing pipelines without conflict.
See the complete Grafana stack in Loki, Tempo, and Mimir for open observability — OTel as unified SDK and Grafana as visualisation layer form a natural combination. For the network context where signals originate, see Cilium and Hubble and Pixie for K8s.
When to adopt
Recommendation by team type:
- Greenfield: adopt OTel from day one. Cost is identical to any other library and avoids future migrations.
- Mature stack with Prometheus + Jaeger working: migrate gradually. Instrument new services with OTel, let them send to your existing backend via exporters. Medium-term, unify.
- No formal observability yet: start with OTel traces + Grafana Tempo. Add metrics and logs as they stabilise.
Conclusion
OpenTelemetry is no longer the future of observability — it’s the present. For new projects, it’s the default choice. For teams with established infrastructure, gradual migration is feasible without disruption. What remains is deciding when to start, not whether.
