Zipkin is a distributed tracing system that helps gather timing data to troubleshoot latency issues in microservices. It works by having tracers in applications record timing metadata about operations into spans, which are sent to Zipkin via reporters. Spans contain things like trace IDs, span IDs, timestamps, and annotations. Related spans with the same trace ID form traces that show how requests flow through systems. Zipkin's components include collectors that store and index spans, storage like Cassandra or Elasticsearch, search APIs, and a web UI for viewing traces. It supports tracing HTTP, Thrift, and messaging protocols.

1. Zipkin
Distributed Tracking System

2. Content
● What is Zipkin?
● Zipkin Architecture
● Data Structure
● Components
● Tracing

3. What is Zipkin?
● Distributed Tracking System
● Is an implementation of Google’s Dapper paper from 2010
● It helps gather timing daha need to troubleshoot latency problems in microservices
● As an analogy, think of it as a performance profiler, like Firebug but tailored for a website backend
instead of a browser

4. Zipkin Architecture Overview
● Tracers live in your applications and record timing and metadata about operations
that took place.
● The trace data collected is called a Span.
● The component in an instrumented app that sends data to Zipkin is called a
Reporter.

5. Zipkin Architecture Diagram

6. Data Structure
● Trace Id : The overall 64 or 128-bit ID of the trace.
Every span in a trace shares this ID.
● Name : Action Name
● Id : The ID for a particular span. This may or may not
be the same as the trace id.
● ParentId: This is an optional ID that will only be present
on child spans. That is the span without a parent id is
considered the root of the trace.
● Timestamp: Microseconds (multiply 1000)
● Duration : Total span duration like as timestamp
● Annotations : An Annotation is used to record an
occurrence in time.

7. Data Structure (Continuous)
Annotation Types
● cs - Client Send. The client has made the request. This sets the beginning of the span.
● sr - Server Receive: The server has received the request and will start processing it. The difference
between this and cs will be combination of network latency and clock jitter.
● ss - Server Send: The server has completed processing and has sent the request back to the client.
The difference between this and sr will be the amount of time it took the server to process the
request.
● cr - Client Receive: The client has received the response from the server. This sets the end of the
span. The RPC is considered complete when this annotation is recorded
● ms - Message Send: The producer sends a message to a broker.
● mr - Message Receive: A consumer received a message from a broker

8. Data Structure (Continuous)
Binary Annotations
● Binary annotations do not have a time component.
● They are meant to provide extra information about the RPC.
Endpoint Annotations
● Contains a time component.
● Contains an endpoint address (IP, Port and Service Name)

9. Data Structure (Continuous)
Span
● A set of Annotations and Binary Annotations that correspond to a particular RPC.
Spans contain identifying information such as traceId, spandId, parentId, and RPC
name.
● Spans are usually small. For example, the serialized form is often measured in KiB
or less. (The unit symbol for the kibibyte is KiB 1 kibibyte is 1024 bytes)

10. Data Structure (Continuous)
Trace
● A set of spans that share a single root span.
● Traces are built by collecting all Spans that share a traceId.
● The spans are then arranged in a tree based on spanId and parentId thus providing
an overview of the path a request takes through the system.

11. Components
● Collector
● storage
● search
● web UI

12. Zipkin Collector
Once the trace data arrives at the Zipkin collector daemon, it is validated, stored, and
indexed for lookups by the Zipkin collector.

13. Storage
● Zipkin was initially built to store data on Cassandra
● Support Elastic Search
● Support MySql

14. Search
Once the data is stored and indexed, we need a way to extract it. The query daemon provides a simple
JSON API for finding and retrieving traces. The primary consumer of this API is the Web UI.

15. Web UI
We created a GUI that presents a nice interface for viewing traces. The web UI provides a method for
viewing traces based on service, time, and annotations. Note: there is no built-in authentication in the UI!

16. Tracing
● Http Tracing
● Thrift Tracing
● Message Tracing

17. Http Tracing
HTTP headers are used to pass along trace information.
The B3 portion of the header is so named for the original name of Zipkin: BigBrotherBird.
Ids are encoded as hex strings:
● X-B3-TraceId: 128 or 64 lower-hex encoded bits (required)
● X-B3-SpanId: 64 lower-hex encoded bits (required)
● X-B3-ParentSpanId: 64 lower-hex encoded bits (absent on root span)
● X-B3-Sampled: Boolean (either “1” or “0”, can be absent)
● X-B3-Flags: “1” means debug (can be absent)

18. Thrift Tracing
Finagle clients and servers negotate whether they can handle extra information in the header of the thrift
message when a connection is established. Once negotiated trace data is packed into the front of each
thrift message.

19. Message Tracing
● Message Tracing is different than RPC tracing because the producer and consumer don’t share
span IDs.
● In normal RPC tracing, client and server annotations go on the same span. This doesn’t work for
messaging because there may be multiple consumers for a given message. The trace context
propagated to the consumer is the parent
● Similar to one-way RPC tracing, messaging tracing doesn’t have a response path: only two
annotations are used “ms” and “mr”. Unlike one-way RPC tracing, it is fine to set Span.timestamp
and duration as the producer and each consumer use separate spans.