Updated: 2026-07-12

For years, observability in distributed systems meant three separate tools: Prometheus for metrics, Jaeger/Zipkin for traces, Elasticsearch/Loki for logs. Each with its own agent, protocol, and format. OpenTelemetry[1] (OTel) is the CNCF[2] project unifying the three signals under a single standard: it graduated in May 2026, the foundation’s highest maturity level, and it is already 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, or 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: it 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.

OpenTelemetry architecture diagram with SDK, Collector, and observability backendsOpenTelemetry architecture diagram with SDK, Collector, and observability backends

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 auto can’t infer: its own span, such as process_payment.

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.

Cross-correlation diagram: from metric to log to trace with shared namespace and service labelsCross-correlation diagram: from metric to log to trace with shared namespace and service labels

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.

This article is also available in Spanish: OpenTelemetry: la unificación de logs, métricas y trazas.

Sources

  1. OpenTelemetry
  2. CNCF
  3. OpenTelemetry — Signal stability status by language
  4. OpenTelemetry Collector achieves Tracing stability milestone (official blog, 2021)
  5. First stable release of the OTel Go metrics SDK (official blog, 2023)
  6. CNCF: announcement of OpenTelemetry’s graduation (May 2026)