What it does
Zipkin is an open-source distributed tracing system with a collector, storage integrations, and a browser UI for searching trace data. Engineers can look up a trace by ID or search by service, operation, tags, and duration, then inspect timing summaries and a dependency diagram. Applications must be instrumented to send spans; Zipkin does not create trace data on its own. It can run locally for evaluation or use persistent backends such as Cassandra and Elasticsearch for retained data.
Follow a request across services
Zipkin is useful after applications are already emitting spans. You can jump to a trace from an ID in a log, or search by service, operation, tags, or duration. The UI summarizes time spent in services, highlights failed operations, and draws a dependency diagram from traced requests. That makes Zipkin a diagnosis surface for request paths and latency, rather than an uptime checker or a tool that instruments an application automatically.
Start small, then choose storage
The official quickstart supports running a self-contained Java server or the published Docker image; the current repository documents Java 17 or later for the server. A local trial can use in-memory storage, which is convenient for a test but is explicitly not persistent or suited to realistic workloads. For retained traces, the project documents Cassandra and Elasticsearch storage components. A slim distribution is available when a smaller server is useful, but it omits messaging transports such as Kafka and RabbitMQ.
Before planning dashboards, confirm that each service has a compatible tracer or instrumentation library configured to report to Zipkin. The project provides collection and lookup, while instrumentation and the durability of the selected storage backend remain deployment responsibilities. No instance was installed or instrumented for this listing; these steps describe the documented workflow.
Strengths
- Searches traces by ID or by service, operation, tags, and duration, and summarizes service timing and failures.
- Shows a dependency diagram that can expose request paths and error-prone service relationships.
- Supports a lightweight local start as well as persistent Cassandra or Elasticsearch storage integrations.
Watch out for
- Applications need compatible instrumentation to emit spans; Zipkin does not generate traces by itself.
- In-memory storage is for testing rather than persistent or realistic workloads, so a durable backend adds deployment work.
- The slim server build does not include messaging transports such as Kafka or RabbitMQ.
Best for
- Developers investigating latency or errors across instrumented services using trace IDs and service-level search.
- Teams that want a self-hosted tracing UI and can operate the chosen storage backend.
Sources
- OpenZipkin · A distributed tracing system (Oct 26, 2026)
- Quickstart · OpenZipkin (Oct 26, 2026)
- GitHub - openzipkin/zipkin: Zipkin is a distributed tracing system (Oct 26, 2026)