OpenTelemetry
Also known as: OTel, OTLP, OpenTracing, OpenCensus, distributed tracing, OTel Collector
OpenTelemetry (OTel) is an open-source project that standardizes how applications emit observability data -- traces (following a request through services), metrics (counters and measurements), and logs.
Instead of being locked into Datadog or Dynatrace's proprietary agents, you instrument code once with OTel and route data to any backend.
OpenTelemetry, explained at three levels
At home
When you have a complex app that uses many services, tracking what happens during a user request is hard. OpenTelemetry adds instrumentation to your code that records what each service did, how long it took, and any errors -- then sends that data to your monitoring tool of choice.
At work
OpenTelemetry solves vendor lock-in for observability. Instead of installing Datadog's proprietary agent, teams instrument code with OTel and can send the same data to Datadog, Grafana, Prometheus, or any compatible backend -- switching vendors doesn't require re-instrumenting the application.
At home
OpenTelemetry has three pillars: Traces (a distributed trace follows a request through microservices; each service adds a 'span' with its timing and attributes), Metrics (counters, gauges, histograms emitted on a configured schedule), and Logs (structured log records with trace context attached for correlation). The OTel Collector is a standalone agent that receives, processes, and exports telemetry data.
At work
OTel SDKs exist for every major language (Java, Python, JavaScript, Go, .NET, Ruby). Auto-instrumentation (Java agent, Python sitecustomize) adds spans to common frameworks (HTTP clients, databases, queues) without code changes. Manual instrumentation allows adding business-specific spans and attributes. The OTel Collector runs as a sidecar or daemon, batching and routing telemetry to backends, and applying processing rules (attribute filtering, sampling).
At home
OTel's data model for traces uses Span (unit of work with start/end time, attributes, events, and status), SpanContext (trace ID + span ID propagated between services), and Baggage (key-value data propagated through the trace for context). W3C TraceContext is the standard header format for propagating trace context across HTTP calls. Sampling strategies (head-based, tail-based) control what fraction of traces are collected.
At work
Tail-based sampling in the OTel Collector or backends (Grafana Tempo, Jaeger) makes sampling decisions after seeing the full trace -- retaining 100% of error traces and sampled interesting traces while dropping routine successful ones. The OTel Protocol (OTLP) uses gRPC or HTTP/protobuf as the universal transport to backends. Semantic conventions standardize attribute names (http.method, db.system, messaging.destination) for consistent querying across services and vendors.
Real-world examples
At home
Jerome added OTel auto-instrumentation to his Python Flask app. Now every HTTP request generates a trace showing Flask processing time, the database query time, and external API call time -- all visible in Grafana Tempo without any manual code changes.
At work
Nadia's platform team adopted OTel across all microservices. They collect traces to Grafana Tempo, metrics to Prometheus, and logs to Loki -- all via the OTel Collector. When they decided to add Datadog for AI-powered anomaly detection, they added a Datadog exporter to the Collector config -- no application code changes.
Common confusions
- OpenTelemetry replaces Datadog or Prometheus — OpenTelemetry is an instrumentation and collection framework, not a backend. You still need a backend to store, query, and visualize data (Datadog, Grafana, Prometheus, Jaeger, Tempo). OTel standardizes how data is collected and formatted, not where it's stored.
- OpenTelemetry is only for microservices — OTel works for monoliths, serverless functions, batch jobs, and microservices. Any application can benefit from standardized observability instrumentation, regardless of architecture.
For analysts
OpenTelemetry traces expose the full journey of a business transaction across systems -- a purchase that touches the web frontend, payment service, inventory system, and notification service can be traced end-to-end. BAs can use this to identify where business process bottlenecks occur technically.
History & origin
OpenTelemetry was formed in 2019 by merging two competing projects: OpenCensus (Google) and OpenTracing (CNCF). The merger was driven by the realization that fragmented instrumentation standards were causing pain for both developers and vendors. OTel graduated from CNCF sandbox to incubating status rapidly, becoming the second-most-active CNCF project (after Kubernetes). It achieved stable specification for traces in 2021, metrics in 2022, and logs in 2023.