Which Distributed Tracing Tool Wins? Comparing Zipkin, SkyWalking, Pinpoint

Background

Micro‑service architectures cause a single request to traverse many services across thousands of servers and multiple data centers. To locate and resolve failures quickly, engineers need full‑link monitoring that records the end‑to‑end call chain. Google’s Dapper paper introduced the core concepts of distributed tracing that most modern APM tools follow.

Goal Requirements

Low probe overhead – tracing must add minimal latency and consume little CPU/memory.

Non‑intrusive instrumentation – the tracing component should be transparent to the application and require no code changes.

Scalability – the system must support distributed deployment and handle large volumes of trace data.

Fast data analysis – metrics should be available in near real‑time for capacity planning and fault isolation.

Functional Modules

Instrumentation & Log Generation : client‑side, server‑side or bi‑directional agents record traceId, spanId, timestamps, protocol, IP/port, service name, latency, result and error information.

Log Collection & Storage : distributed collectors (often pub/sub) optionally buffer via MQ, aggregate logs and persist them for both real‑time and offline analysis.

Analysis & Statistics : reconstruct call stacks from Span IDs, compute TPS, latency, error rates and provide batch and streaming dashboards.

Visualization & Decision Support : UI call‑graph visualizations, performance heatmaps and alerting to aid troubleshooting.

Google Dapper Model

Span

A Span represents a single unit of work (e.g., an RPC or DB call) and is identified by a 64‑bit ID. Typical fields are TraceID, SpanID, ParentID, timestamps, annotations and optional tags.

type Span struct {
    TraceID    int64 // identifies the whole request
    Name       string
    ID         int64 // current span ID
    ParentID   int64 // parent span ID, null for root
    Annotation []Annotation
    Debug      bool
}

Trace

A Trace is a tree of Spans that together represent the complete execution path of a request, from client start to server response.

Annotation

Annotations record specific events within a Span. The four standard timestamps are:

cs – Client Start

sr – Server Receive

ss – Server Send

cr – Client Receive

type Annotation struct {
    Timestamp int64
    Value     string
    Host      Endpoint
    Duration  int32
}

Solution Comparison

The three open‑source APM solutions evaluated are Zipkin (Twitter), SkyWalking (Apache) and Pinpoint (Naver). All are inspired by Dapper but differ in architecture, performance and feature set.

Probe Performance

Performance tests used a Spring‑Boot application (Tomcat, Spring MVC, Redis, MySQL) with 500, 750 and 1000 concurrent users via JMeter. Sampling was 100 % for all three tools. Results:

SkyWalking introduced the smallest throughput impact.

Zipkin’s impact was moderate.

Pinpoint reduced throughput noticeably (e.g., from 1385 TPS to 774 TPS at 500 concurrency).

CPU and memory overhead for all three stayed within ~10 %.

Collector Scalability

Zipkin : multiple Zipkin‑Server instances consume logs via HTTP or asynchronous MQ; horizontal scaling is achieved by adding more server nodes.

SkyWalking : collector can run in single‑node or cluster mode; agents communicate with the collector over gRPC.

Pinpoint : collector supports both single‑node and clustered deployment; agents use Thrift for transport.

Data Analysis

SkyWalking and Pinpoint provide fine‑grained, code‑level visibility (including SQL statements and method‑level spans).

Zipkin’s analysis is coarser, typically limited to service‑to‑service calls.

Developer Transparency

Zipkin requires code changes or library integration (Brave API).

SkyWalking and Pinpoint use bytecode‑instrumentation agents, enabling zero‑code‑change deployment.

Topology Visualization

All three generate full‑call‑graph topologies.

Pinpoint’s UI shows detailed DB names; SkyWalking displays extensive middleware support; Zipkin’s topology is limited to service‑level links.

Pinpoint vs. Zipkin Detailed Comparison

Scope : Pinpoint offers a complete APM stack (probe, collector, storage, UI); Zipkin focuses on collector and storage.

Instrumentation : Pinpoint uses a Java Agent with bytecode injection; Zipkin’s Brave provides only an API.

Storage backend : Pinpoint uses HBase; Zipkin uses Cassandra.

Extensibility : Zipkin’s REST/JSON interface is easier for community contributions; Pinpoint’s Thrift‑based extensions are harder to develop due to limited documentation.

Community support : Zipkin benefits from a large, active community (Twitter); Pinpoint’s community is smaller (Naver), affecting plugin availability and long‑term maintenance.

Tracing vs. Monitoring

Monitoring captures system‑level metrics (CPU, memory, process stats) and application‑level metrics (QPS, latency, error counts). Tracing focuses on call‑chain data to analyze system behavior and pinpoint performance bottlenecks before they cause outages.

Conclusion

Choosing an APM solution depends on project priorities:

Pinpoint : best for rapid deployment with zero‑code‑change agents, fine‑grained method tracing and a rich UI, but has a steeper learning curve, smaller community and higher integration effort.

Zipkin : offers easier onboarding, broader language support and a large community, making integration simpler at the cost of coarser granularity.

SkyWalking : provides a balanced mix of performance, scalability and extensive middleware coverage, suitable for large‑scale Java ecosystems.