What Is Zipkin Tracing?

What Is Zipkin Tracing?

Zipkin is an open-source distributed tracing system that helps developers monitor how requests travel across microservices and identify performance bottlenecks. It collects timing information from different services, allowing engineers to understand how long individual operations take and where delays occur.

In a distributed application, a single request may pass through several services before completing. Each service performs a specific operation, and a delay in one component can affect the entire request.

Zipkin connects these operations using traces and spans. A trace represents the complete journey of a request, while spans represent individual operations performed during that journey.

By collecting and visualizing this information, Zipkin helps engineers identify slow services, investigate failed requests, and understand dependencies between application components.

Zipkin originated at Twitter and was inspired by Google's Dapper distributed tracing system. It is now maintained as an open-source project under OpenZipkin.

In simple terms: Zipkin is a distributed tracing tool that tracks requests across multiple services, helping developers understand application performance and identify where delays or failures occur.

Why Is Zipkin Tracing Important?

Modern applications frequently use microservices, containers, and cloud infrastructure. A single user request may involve several independent services, databases, and external APIs.

While this architecture improves scalability and flexibility, it also makes troubleshooting more complicated. Traditional monitoring may reveal that an application is slow without identifying which downstream operation caused the delay.

Zipkin addresses this problem by recording how requests move across services and measuring the time spent on individual operations.

For example, an e-commerce application takes four seconds to complete a checkout request. The request passes through authentication, inventory, payment, and order services. Zipkin reveals that the payment service accounts for three seconds of the total execution time.

This helps engineers focus their investigation on the affected service instead of examining every application component.

Zipkin is particularly useful for understanding request latency, analyzing service dependencies, and identifying failures in distributed systems.

How Does Zipkin Tracing Work?

Zipkin works by collecting trace information from instrumented applications and connecting related operations into a complete request timeline.

Applications use tracing libraries or compatible instrumentation to generate spans and report them to Zipkin.

The process generally involves four stages.

1. Instrumenting Applications

The first step is enabling tracing instrumentation within application services.

Instrumentation records operations such as incoming HTTP requests, outgoing API calls, and database interactions.

Each recorded operation becomes a span containing information such as its name, timing, and associated metadata.

For example, when an order service calls a payment API, tracing instrumentation records the payment request as a span.

2. Propagating Trace Context

When a request travels between services, tracing identifiers must be passed along so the resulting operations can be connected.

Zipkin commonly uses B3 propagation, which transfers tracing information through HTTP headers or other supported communication mechanisms.

The trace ID remains consistent across operations belonging to the same distributed request, while span identifiers establish individual operation relationships.

3. Collecting and Storing Traces

Instrumented applications report completed spans to Zipkin, generally through asynchronous communication.

The Zipkin collector receives the spans, validates them, and stores the information in a configured storage backend.

This approach separates trace reporting from normal application request processing.

4. Visualizing Request Execution

Once trace data is stored, engineers can search for traces through the Zipkin web interface.

Zipkin displays individual operations and their timing, allowing developers to understand how a request was processed.

For example, a trace might show that an API gateway takes 20 milliseconds, an authentication service takes 80 milliseconds, and a database query takes 900 milliseconds.

Engineers can use this information to identify the operation contributing most to request latency.

Understanding Zipkin Architecture

Zipkin uses several components to collect, store, search, and visualize distributed tracing information.

Its architecture is designed to separate trace collection from trace analysis, allowing applications to report telemetry without requiring synchronous communication with the tracing interface.

The four core server-side components are collection, storage, search, and the web interface.

Zipkin supports different storage configurations, including in-memory storage for development and persistent backends such as Elasticsearch, Cassandra, and MySQL.

For example, an application running across several Kubernetes services can send tracing data to a Zipkin collector. Engineers can then search the stored traces to investigate slow API requests.

This architecture allows Zipkin to support distributed tracing across applications running on different infrastructure environments.

Understanding Traces and Spans in Zipkin

Traces and spans are the fundamental elements of Zipkin tracing.

A trace represents the complete execution path of a request across one or more services. Each trace has a unique trace ID that connects its related operations.

A span represents an individual operation within the trace. Spans contain information such as operation names, timestamps, duration, tags, and relationships with other spans.

For example, consider the following request:

API Gateway → Authentication Service → Order Service → Payment Service

Zipkin can represent the operations as separate spans connected through a shared trace ID.

Example: The payment service takes significantly longer than the other operations, making it a useful starting point for investigating the transaction.

Individual span durations may overlap, so adding them together does not necessarily equal the total request duration.

Zipkin uses parent-child relationships to reconstruct the execution structure, helping engineers understand how operations depend on one another.

What Is B3 Propagation in Zipkin?

B3 is a trace context propagation format commonly associated with Zipkin. It defines how tracing identifiers and sampling information travel between services.

When a service receives a request containing B3 headers, compatible tracing instrumentation can extract the context and associate its operations with the existing trace.

B3 supports both multiple-header and single-header formats.

Common B3 headers include:

For example, when a checkout service calls a payment service, B3 headers allow compatible instrumentation to preserve the trace relationship between both operations.

B3 supports 64-bit and 128-bit trace IDs, while span IDs are 64-bit identifiers.

Although Zipkin commonly uses B3, other propagation formats, including W3C Trace Context, can be used in compatible instrumentation environments.

What Is Trace Sampling in Zipkin?

Trace sampling controls how much tracing information is collected from an application.

In high-traffic environments, collecting every span from every request can generate large amounts of telemetry data and increase storage requirements.

Sampling reduces this volume by selecting which traces should be recorded.

For example, an application processes 100,000 requests per minute. A 10% probabilistic sampling configuration would collect approximately 10,000 traces per minute, assuming sampling decisions are applied consistently.

Zipkin's tracing ecosystem supports sampling decisions that can be propagated between services using formats such as B3.

However, sampling introduces trade-offs. Reducing trace collection can lower resource consumption, but rare errors or infrequent performance problems may not appear in the collected data.

For this reason, sampling policies should consider application traffic, troubleshooting requirements, and telemetry storage capacity.

How Zipkin Helps Troubleshoot Microservices

Zipkin provides visibility into request execution across distributed applications, making it useful for investigating service latency and failures.

Identifying Slow Services

Zipkin records operation timing across instrumented services, allowing engineers to identify where requests spend their time.

For example, a customer-facing API takes two seconds to respond. Zipkin reveals that a downstream inventory service accounts for most of the request duration.

Engineers can investigate that dependency instead of reviewing every component.

Investigating Failed Requests

Zipkin allows developers to examine trace data associated with failed operations. Depending on the instrumentation, spans may contain error-related tags and other diagnostic information.

For example, a payment request fails because a downstream API returns an error. Zipkin helps identify which service interaction failed and where it occurred in the request path.

Understanding Service Dependencies

Zipkin provides dependency visualizations that show relationships between services based on collected tracing data.

These relationships help engineers understand how services communicate and which components may be affected by failures.

For example, a service dependency graph reveals that checkout, billing, and subscription services all communicate with the same authentication service.

This information can help teams understand the potential impact of authentication-related failures.

Zipkin vs. Jaeger

Zipkin and Jaeger are open-source distributed tracing systems designed to help engineers understand request behavior across microservices.

Both collect tracing information, reconstruct distributed requests, and provide interfaces for investigating application latency and errors.

However, they differ in their architecture, implementations, and ecosystem integrations.

Zipkin is often considered for applications that already use B3 propagation or existing Zipkin instrumentation.

Jaeger is another option for organizations adopting OpenTelemetry-based tracing infrastructure.

Both can help engineers investigate request latency and understand distributed service behavior.

Zipkin vs. OpenTelemetry

Zipkin and OpenTelemetry are related technologies, but they serve different purposes.

Zipkin is a distributed tracing system that collects, stores, and visualizes trace data.

OpenTelemetry is an observability framework that provides standardized APIs, SDKs, instrumentation, and collection tools for traces, metrics, and logs.

OpenTelemetry can receive Zipkin-formatted tracing data through a compatible Collector receiver and forward it to another observability backend.

Its Collector architecture supports receivers, processors, and exporters for processing telemetry across different systems.

An important distinction: OpenTelemetry's Zipkin exporter specification is deprecated as of October 2026, with removal from the specification planned for December 2026. Existing implementations may remain supported under their respective stability guarantees, but new integrations should generally favor OTLP where possible.

How to Get Started With Zipkin Tracing

Getting started with Zipkin involves deploying the tracing backend, instrumenting application services, and verifying that traces are collected correctly.

The simplest way to explore Zipkin is through its official Docker image.

1. Run Zipkin

Zipkin provides a Docker image that can be started locally:

docker run -d -p 9411:9411 openzipkin/zipkin

After starting the container, open:

http://localhost:9411

This provides access to the Zipkin web interface.

2. Instrument Your Application

Configure your application using an appropriate tracing library or OpenTelemetry instrumentation.

The instrumentation should generate spans for important operations, including HTTP requests and downstream service calls.

3. Configure Trace Export

Configure the application or OpenTelemetry Collector to send trace data to Zipkin through a supported endpoint or protocol.

For existing Zipkin-compatible instrumentation, the Zipkin v2 API commonly receives spans at /api/v2/spans.

4. Analyze Collected Traces

Once the application begins generating traces, use the Zipkin interface to search by service name, operation, duration, or trace ID.

For example, generate several API requests and examine the resulting traces to understand how long each service takes to process them.

This provides an initial view of request execution and service dependencies.

Limitations of Zipkin Tracing

Zipkin provides useful distributed tracing capabilities, but it has some limitations.

First, Zipkin primarily focuses on traces. It does not provide the same native breadth of infrastructure monitoring, log management, and application metrics available in full-stack observability platforms.

Second, tracing visibility depends on instrumentation coverage. If an application service does not generate spans or propagate trace context correctly, the resulting trace may be incomplete.

Sampling can also affect troubleshooting. When only a portion of requests is recorded, rare failures or short-lived performance problems may be missed.

Additionally, organizations operating Zipkin themselves must manage its infrastructure, storage, retention, and availability requirements.

Zipkin can be effective for understanding distributed request execution, but teams often combine tracing with logs, metrics, and infrastructure monitoring to investigate production issues more completely.

How Middleware Helps With Distributed Tracing

Middleware is an OpenTelemetry-native observability platform that helps engineering teams monitor application performance through distributed tracing, logs, metrics, and infrastructure telemetry.

While Zipkin primarily focuses on distributed tracing, Middleware provides a broader observability environment where engineers can investigate service performance and correlate related telemetry.

Trace Requests Across Microservices

With Middleware Application Performance Monitoring, engineers can trace requests across instrumented application services and identify slow operations.

Middleware uses OpenTelemetry instrumentation to collect tracing information, helping teams maintain visibility across distributed applications.

For example, when a checkout request experiences increased latency, engineers can examine its trace to determine whether the delay originates in the checkout service, payment API, or database.

For teams with existing Zipkin instrumentation, an OpenTelemetry Collector configured with a Zipkin receiver can provide a path for converting and forwarding trace data to an OTLP-compatible backend such as Middleware. This requires appropriate Collector configuration rather than implying native, automatic ingestion of every Zipkin deployment.

Investigate Traces With Multiple Views

Middleware's Trace Explorer provides Waterfall, Flame Graph, Spans, and Map views for examining distributed requests.

The Waterfall view shows operation timing and execution relationships, while other views help engineers understand service dependencies and inspect individual span details.

Developers can also filter traces and investigate associated errors, events, and span attributes.

Correlate Traces With Logs and Metrics

Middleware connects distributed traces with logs and application metrics, helping engineers investigate problems across multiple telemetry sources.

For example, a distributed trace identifies a slow database operation. Engineers can examine related logs and performance metrics to determine whether the delay is associated with an application error, query behavior, or infrastructure conditions.

This provides additional context that cannot always be obtained from tracing data alone.

Middleware also supports OpenTelemetry-based instrumentation, allowing organizations to maintain portable telemetry collection as their observability requirements change.

Best Practices for Zipkin Tracing

Maintain consistent instrumentation: Instrument important application services and downstream dependencies to ensure requests can be traced across service boundaries.

Preserve trace context: Configure compatible propagation formats, such as B3 or W3C Trace Context, to prevent disconnected traces.

Apply appropriate sampling: Balance trace collection requirements with application traffic and storage capacity.

Monitor critical transactions: Prioritize tracing for important application workflows, including authentication, payments, and order processing.

Combine tracing with other telemetry: Use logs, metrics, and infrastructure monitoring alongside traces to investigate performance problems more effectively.

Review trace data regularly: Examine latency patterns, error-related spans, and service dependencies to identify recurring performance issues.

Conclusion

Zipkin is an open-source distributed tracing system that helps developers understand how requests move across microservices and distributed applications. By collecting spans and connecting them into traces, it provides visibility into request execution, latency, and service dependencies.

As applications become more distributed, tracing becomes increasingly important for identifying performance bottlenecks and investigating failures.

Zipkin provides a foundation for distributed tracing, while OpenTelemetry enables standardized instrumentation and telemetry collection across environments.

For organizations that need broader visibility, platforms such as Middleware combine distributed tracing with logs, metrics, and infrastructure monitoring, helping engineering teams investigate application issues with more complete operational context.