Zipkin

Zipkin's fundamental data unit is the span, which represents a single, timed operation within a service (e.g., an HTTP call or database query). Spans contain:

• Name: The operation name.
• Timestamp & Duration: Precise timing data.
• Tags: Key-value pairs for contextual metadata (e.g., http.method=GET).
• Annotations: Timestamped event logs within a span's lifetime. Spans are linked via parent-child relationships using Trace ID and Span ID to reconstruct the complete request path.

To correlate work across services, Zipkin propagates trace context using standardized headers. It primarily supports:

• B3 Propagation: The original header format (X-B3-TraceId, X-B3-SpanId, X-B3-ParentSpanId).
• W3C Trace Context: The modern W3C standard for interoperability with other systems like OpenTelemetry. This propagation is handled by instrumentation libraries or a propagator, ensuring the Trace ID is carried through HTTP, gRPC, and messaging systems to maintain a continuous trace.

Zipkin is designed as a collection of loosely coupled components:

• Instrumented Application: Services generate trace data (spans).
• Reporters/Exporters: Send spans from the application to a Zipkin collector (often via HTTP or Kafka).
• Collector: Validates, indexes, and persists spans to storage.
• Storage Backend: Supports pluggable options including Elasticsearch, Cassandra, and MySQL.
• Query Service & API: Retrieves traces and dependencies from storage.
• Web UI: Provides a graphical interface for finding and visualizing traces as flame graphs.

By analyzing trace data, Zipkin can automatically generate service dependency graphs. This visualization maps:

• Nodes: Represent each service in the architecture.
• Edges: Show the direction and volume of calls between services. This feature is critical for understanding systemic topology, identifying unexpected dependencies, and visualizing the impact of a service failure. The graph is derived from span kind attributes (e.g., Client, Server).

Zipkin offers broad support for different frameworks and languages through community-maintained libraries. Instrumentation can be achieved via:

• Manual Instrumentation: Using the Zipkin client library API directly.
• Framework Instrumentation: Pre-built tracing for Spring (Sleuth), JAX-RS, gRPC, etc.
• OpenTelemetry Integration: Spans generated by OpenTelemetry (OTel) SDKs can be exported to Zipkin using the OpenTelemetry Protocol (OTLP) or Zipkin-formatted exporters, making it a viable backend for OTel-based observability pipelines.

To manage data volume and storage costs in high-throughput systems, Zipkin supports trace sampling. This is typically configured at the instrumentation level.

• Head-based Sampling: A decision is made at the start of a trace (e.g., sample 10% of requests).
• Delegated Sampling: Can be integrated with external sampling proxies. While Zipkin itself does not perform tail sampling (decision after trace completion), this can be implemented upstream using a component like the OpenTelemetry Collector before data is sent to Zipkin storage.

The span and the trace are the two fundamental data models in distributed tracing that Zipkin collects and visualizes.

• Span: Represents a single, named, timed operation within a service (e.g., a database query, an HTTP handler). A span contains:
  • Span ID: A unique identifier for this operation.
  • Parent ID: A reference to the span that caused this work (creating a hierarchy).
  • Timestamps: Start and duration.
  • Tags/Annotations: Key-value metadata (e.g., http.method=GET).
• Trace: A directed acyclic graph (DAG) of spans that represents the end-to-end journey of a request. All spans in a trace share a single, globally unique Trace ID. Zipkin's UI reconstructs these hierarchies to show the flame graph visualization of a request's path.

Context propagation is the critical mechanism that enables distributed tracing by passing trace identifiers (Trace ID, Span ID) across service boundaries. Without it, spans cannot be linked into a coherent trace.

• Propagators: Code components that inject context into outbound requests (e.g., HTTP headers) and extract it from inbound requests.
• Formats: Zipkin originally popularized the B3 Propagation format, which uses headers like X-B3-TraceId. The W3C Trace Context standard is now widely adopted for interoperability.
• Process: When Service A calls Service B, Service A's tracing SDK injects the current trace and span IDs into the HTTP headers. Service B's SDK extracts them, creating a new child span linked to the parent. This propagation is what allows Zipkin to track requests across network hops, queues, and asynchronous processes.

Application Performance Monitoring (APM) is the overarching practice of monitoring software performance and availability. Distributed tracing, as implemented by Zipkin, is a core pillar of a modern APM strategy.

• APM Pillars: Typically includes Distributed Tracing, Metrics (time-series data), and Logs (event records).
• Zipkin's Role: Zipkin is a specialized tracing backend. Commercial and open-source APM Suites (e.g., Datadog APM, New Relic, Grafana Tempo) often bundle tracing with metrics, logging, and alerting into a unified platform.
• Use Case: While Zipkin excels at deep-dive latency analysis for microservices, a full APM solution provides a broader view, correlating traces with system metrics (CPU, error rates) and business KPIs.

A Service Dependency Graph (or Service Graph) is a topological map automatically generated from trace data by systems like Zipkin. It visualizes the runtime dependencies between services in a microservice architecture.

• Generation: Zipkin analyzes trace data to infer which services call which other services and the volume/latency of those calls.
• Purpose: Provides an immediate, visual understanding of system architecture and critical data flows. It is essential for:
  • Impact Analysis: Understanding which services will be affected by an outage.
  • Architecture Drift: Identifying unintended or new dependencies.
  • Bottleneck Identification: Spotting services with high fan-out or latency. This graph moves observability from analyzing single requests (traces) to understanding the holistic system behavior.