OpenTracing

Definition

OpenTracing is a vendor-neutral specification for instrumenting applications with distributed tracing, defining a common API that libraries and services use to generate trace spans without binding to a specific tracing backend. It let developers add tracing calls to their code once and send the resulting data to any compliant tracer, avoiding lock-in to a single vendor's client library. The project became a CNCF incubation project before being merged into OpenTelemetry, which now serves as its successor.

Overview

Distributed systems split a single user request across many services, and understanding why a request was slow or where it failed requires following that request's path end to end. OpenTracing addressed this by defining a language-agnostic API for creating spans, the basic unit of work in a trace, and propagating trace context between services. Rather than shipping a tracer itself, OpenTracing specified the interface: how to start a span, attach tags and logs to it, and pass a trace identifier across process boundaries, leaving the actual collection and storage to a pluggable backend. Mechanically, an application instrumented with OpenTracing creates a span at the start of an operation, records metadata such as HTTP status codes or database query text as tags, and closes the span when the operation finishes. When a service calls another service, it injects the trace context into the outgoing request headers; the receiving service extracts that context and creates child spans that nest under the parent, forming a tree that a tracing backend can reconstruct into a full request timeline. Because the API was standardized, libraries for popular frameworks could instrument themselves once and remain compatible with any OpenTracing-compliant backend such as Jaeger or Zipkin. OpenTracing sat alongside OpenCensus, a competing Google-originated project that combined tracing with metrics collection in a single SDK. The existence of two overlapping standards created confusion for teams choosing an instrumentation strategy, since libraries had to choose which API to support or implement both. This fragmentation was a direct motivation for merging the two projects into OpenTelemetry, which absorbed OpenTracing's tracing model and OpenCensus's metrics model into one unified specification and SDK. In practice, teams used OpenTracing-compatible client libraries inside microservices to emit spans that were exported to a tracing backend like Jaeger, Zipkin, or a commercial APM product, then visualized as waterfall diagrams showing latency contributed by each downstream call. This was especially valuable for diagnosing tail latency and pinpointing which service in a call chain was responsible for a slow or failed request, something aggregate metrics alone cannot reveal. OpenTracing is now a legacy specification: the project is in maintenance mode and new instrumentation should target OpenTelemetry instead, which provides a superset of its API along with metrics and logging support. Existing OpenTracing instrumentation continues to work through compatibility shims, but it does not receive new features, and organizations still running it are effectively on a deprecated standard. Teams evaluating tracing today should adopt OpenTelemetry directly rather than building new dependencies on OpenTracing.

Specification

• Vendor-neutral API for creating and propagating distributed trace spans
• Language-agnostic specification implemented by libraries in many ecosystems
• Decouples application instrumentation from the choice of tracing backend
• Supports span tags and structured logs for attaching contextual metadata
• Propagates trace context across process and network boundaries via headers
• Compatible with backends such as Jaeger and Zipkin through defined exporters
• Was a CNCF incubation project prior to merging into OpenTelemetry
• Now maintained only for backward compatibility, not active development

Use Cases

Alternatives

Frequently Asked Questions

Related in DevOps