Skip to content

Observability with OpenTelemetry

OpenTelemetry (OTel) is a vendor-neutral, open-source observability framework that standardises how telemetry data is collected, processed, and exported from applications and infrastructure.

Three pillars of observability

Pillar Purpose
Metrics Numeric measurements of system health and performance over time (e.g. request rate, error rate, latency)
Logs Structured or unstructured records of discrete events, status changes, and errors
Traces End-to-end tracking of a single request as it flows through distributed services

Key components

  • SDK — Language-specific libraries (Go, Java, Python, Node.js, etc.) for instrumenting application code
  • API — Interfaces for generating telemetry; applications code against the API, not the SDK
  • Collector — A standalone agent/proxy that receives telemetry from SDKs, processes it (filtering, batching, enriching), and exports it to backends
  • Exporters — Plugins that send data to observability backends such as Prometheus, Jaeger, Grafana Tempo, or commercial platforms

OpenTelemetry Collector pipeline

Application SDK → Receiver → Processor → Exporter → Backend
  • Receiver — Accepts telemetry in OTLP or legacy formats (Jaeger, Zipkin, Prometheus)
  • Processor — Transforms data: batch, filter, add/remove attributes, tail-sampling
  • Exporter — Sends data to the target backend

Auto-instrumentation vs manual instrumentation

Approach Description
Auto-instrumentation Zero-code agent injected at runtime; instruments frameworks automatically (HTTP, DB, messaging)
Manual instrumentation Developer adds spans, attributes, and events explicitly for business-logic visibility

Both can be used together: auto-instrumentation covers infrastructure-level signals, manual instrumentation adds application-specific context.