OpenTelemetry

• Vendor-neutral, CNCF standard for instrumenting, collecting, and exporting telemetry data ( OpenTelemetry Docs)
• Covers all three observability pillars: logs, metrics, and traces
• Does not store or visualize data — it is purely an instrumentation and transport layer
• Emerged from the merger of OpenCensus and OpenTracing (2019)

• APIs — language-agnostic interfaces for emitting telemetry
• SDKs — language-specific implementations of the API
• Instrumentation libraries — auto-instrumentation for popular frameworks
• OTel Collector — standalone pipeline service for receiving, processing, exporting
• OTLP — standardized wire protocol (gRPC port 4317, HTTP port 4318)

• Before OTel: each vendor (Datadog, Jaeger, Zipkin, AWS X-Ray) had its own agent and SDK
  • Switching backends required re-instrumenting all application code
• With OTel: instrument once → point Collector at any backend
  • Swap Tempo for Jaeger, add Datadog alongside — zero app code changes

• Traces — end-to-end request journeys (see Spans and Traces)
• Metrics — numeric measurements over time (counters, gauges, histograms)
• Logs — structured/unstructured event records (OTel log support is newer, still maturing)
• Profiles — continuous profiling (in development as of 2025)

• OTel SDK and Instrumentation
  • Language SDKs, auto-instrumentation, manual instrumentation, OTLP wire format
• OTel Collector
  • Standalone pipeline: agent vs gateway deployment, K8s DaemonSet, OTel Operator, processors

A useful mental model is:

OpenTelemetry is the plumbing, not the observability platform.

It standardizes how telemetry is produced and transported, but something else must store, query, and visualize that data.

Imagine a request hitting your application:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

User Request
     │
     ▼
 Application
     │
     ├─ Trace data
     ├─ Metrics
     └─ Logs
     │
     ▼
 OpenTelemetry SDK
     │
     ▼
 OpenTelemetry Collector
     │
     ▼
 Backend(s)
     ├─ Tempo / Jaeger (traces)
     ├─ Prometheus / Mimir (metrics)
     ├─ Loki / Elasticsearch (logs)
     └─ Datadog / New Relic / Honeycomb

OTel sits in the middle:

1

Application  →  OTel  →  Observability Backend

Before OTel, every observability vendor had its own SDK:

1
2
3
4
5

Application
 ├─ Datadog SDK
 ├─ New Relic SDK
 ├─ AWS X-Ray SDK
 └─ Zipkin SDK

If you switched vendors:

1

Datadog → New Relic

you often had to:

• uninstall one agent
• rewrite instrumentation
• change trace propagation formats
• update dashboards and exporters

OTel changed this to:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

Application
     │
 OTel SDK
     │
 Collector
     │
 ├─ Datadog
 ├─ Tempo
 ├─ Jaeger
 └─ New Relic

The application only knows OTel.