Zipkin
By OpenZipkin
Zipkin is an open-source distributed tracing system, originally developed at Twitter, that helps engineers collect and visualize timing data across microservice calls to identify latency problems and understand request flow through a…
Definition
Zipkin is an open-source distributed tracing system, originally developed at Twitter, that helps engineers collect and visualize timing data across microservice calls to identify latency problems and understand request flow through a distributed system. It provides instrumentation libraries, a collector, storage options, and a web UI for searching and viewing individual traces across a service architecture, and it helped popularize span-based tracing concepts now standardized in OpenTelemetry.
Overview
As services split into many independently deployed components, a single user-facing request can traverse numerous internal calls, and pinpointing which one is slow or failing becomes difficult without a shared record connecting them. Zipkin was built at Twitter, inspired by Google's internal Dapper paper, to solve exactly this: it defines a way to tag each unit of work in a request with a shared trace ID and per-call span IDs, then collects and reassembles those spans into a single visualized timeline of the request's full path. Mechanically, applications are instrumented with Zipkin-compatible libraries that generate spans — a piece of the trace representing one operation, such as an RPC call or database query — carrying timing data, the trace ID, and a parent span ID showing the call hierarchy. These spans are reported, often asynchronously, to a Zipkin collector, which validates and stores them in a backend such as Cassandra, Elasticsearch, or MySQL. Zipkin's web UI and API then query that storage by trace ID or by searchable attributes like service name, tag, or duration, rendering a waterfall diagram showing how long each span took and how they nested, which makes it straightforward to spot which downstream call added the most latency to a slow request. Zipkin was one of the earliest widely adopted open-source tracing systems and helped establish patterns that later influenced the OpenTracing and OpenTelemetry standards, which aim to make instrumentation portable across different tracing backends. It differs from Grafana Tempo mainly in its indexing approach: Zipkin builds a searchable index over span tags in its storage backend, enabling attribute-based search directly, whereas Tempo intentionally omits that index to reduce storage cost, relying more on external correlation. It sits alongside Jaeger, a similarly indexed, CNCF-hosted tracing system with broader current momentum in many cloud-native environments. In practice, teams instrument services with a Zipkin-compatible client, or increasingly with OpenTelemetry SDKs configured to export in Zipkin's format, run a Zipkin server to collect and store spans, and use its UI to investigate specific slow or failed requests reported by users or alerts. It remains common in codebases and organizations that adopted it early, particularly those with Twitter or Java/Spring ecosystem roots, where Spring Cloud Sleuth historically integrated directly with Zipkin. The main limitation is that Zipkin's storage and query model does not scale as cost-effectively as newer approaches like Tempo's object-storage design once trace volume gets very large, and its ecosystem momentum has been partly overtaken by Jaeger and OpenTelemetry-native tooling. Teams starting fresh today often evaluate Jaeger or an OpenTelemetry-compatible backend first, while organizations with existing Zipkin instrumentation frequently keep it running rather than migrate, since OpenTelemetry can still export to Zipkin's format if needed.
Key Features
- Provides a full open-source distributed tracing pipeline end to end
- Uses trace IDs and span IDs to reconstruct request call hierarchies
- Supports multiple storage backends including Cassandra and Elasticsearch
- Offers a web UI with waterfall diagrams for individual traces
- Enables attribute-based trace search via an indexed storage layer
- Integrates with OpenTelemetry as a supported export format
- Has broad language support through community instrumentation libraries
- Influenced later standards like OpenTracing and OpenTelemetry