Zipkin Tracing API
Zipkin is an open-source distributed tracing system with a v2 JSON REST API for collecting spans and querying traces to investigate latency and error propagation across microservices.
Score Breakdown
⚙ Agent Friendliness
🔒 Security
No authentication whatsoever by default — Zipkin is designed as an internal tool behind a network boundary. Spans can contain sensitive data (HTTP headers, request bodies) with no access controls. TLS requires a proxy layer.
⚡ Reliability
Best When
Best when you need a lightweight, easily embeddable distributed tracing backend with a clean v2 JSON API that agents can both write spans to and query without complex setup.
Avoid When
Avoid when you need advanced trace analytics, long retention, or tight OpenTelemetry ecosystem integration — Jaeger or Grafana Tempo are better choices for those needs.
Use Cases
- • Query the Zipkin API by service name and time range to retrieve recent traces and automatically identify the slowest endpoints after a production change
- • Use the /api/v2/services and /api/v2/spans endpoints to maintain a real-time catalog of all instrumented services and their operation names for agent-driven service maps
- • Post spans directly to /api/v2/spans from an agent that wraps outbound API calls to add tracing to uninstrumented legacy services
- • Retrieve trace dependency graphs via /api/v2/dependencies to detect newly introduced or broken service-to-service relationships during continuous deployment
- • Search traces with error tags using the /api/v2/traces?annotationQuery=error endpoint to power automated alert triage that links alerts to root-cause trace data
Not For
- • Metrics collection and alerting — Zipkin stores only trace/span data with no metric aggregation, alerting rules, or time-series storage
- • Log aggregation or correlation — use a log backend (Loki, Elasticsearch) alongside Zipkin for full observability; Zipkin has no log storage
- • High-cardinality trace storage at scale without a proper backend — the default in-memory store is for development only and loses all data on restart
Interface
Authentication
Zipkin has no built-in authentication or authorization. All endpoints are open by default. Access control must be implemented via a reverse proxy. Do not expose Zipkin directly to the internet.
Pricing
Fully open source. Production deployments require a storage backend (MySQL, Cassandra, Elasticsearch) that incurs its own operational costs.
Agent Metadata
Known Gotchas
- ⚠ Timestamps in the Zipkin v2 API are in microseconds since epoch — submitting milliseconds or seconds will produce traces with wildly incorrect timestamps that appear far in the past or future
- ⚠ The default in-memory storage backend loses all trace data on restart — agents must not rely on previously queried trace IDs persisting across Zipkin restarts in dev environments
- ⚠ Span ingestion via POST /api/v2/spans is fire-and-forget with a 202 Accepted response — a 202 does not guarantee the span was stored; storage failures are silent from the client perspective
- ⚠ The /api/v2/traces search API has no cursor-based pagination — results are limited by the `limit` parameter (max 10 by default) and there is no way to fetch the next page beyond adjusting endTs
- ⚠ Service names and span names in Zipkin are case-sensitive and whitespace-sensitive — inconsistent instrumentation across services produces fragmented service maps that are difficult to query programmatically
Alternatives
Full Evaluation Report
Detailed scoring breakdown, competitive positioning, security analysis, and improvement recommendations for Zipkin Tracing API.
Scores are editorial opinions as of 2026-03-06.