Zipkin distributed tracing system project

Zipkin distributed tracing system project

Zipkin is a distributed tracing system used for gathering all the services involved in managing a request to the twitter API.

There is web user interface where we can exactly find out the request processing information on timely basis. You can click on each of those to get the detailed information of that particular request.

This can be used for tracing the HTTP, Thrift, Memcache, SQL and Redis requests. This zipkin will help twitter in fixing removing memcache requests, rewriting slow MySQL SELECTs, and fixing incorrect service timeouts. Finding and correcting these types of performance bottlenecks helps make twitter faster.

Zipkin distributed tracing system project

Zipkin is the Twitter open-source implementation of Dapper which, on the other hand, is the distributed tracing system of Google. The usual Zipkin deployment looks similar to the image below. Cassandra is the recommended database. Zipkin on Scribe on Thrift or “Zipkin/Scribe/Thrift” is the protocol used between the Zipkin collector and the applications. The Zipkin project recommends the setup of a full Scribe environment for scalability.

You can execute multiple instances of the Zipkin collector and configure your server-local Scribe receiver for load- balancing by routing Zipkin messages to the cluster. You can direct your application straight to the Zipkin collector when testing on low workload environment because it also supports Scribe protocol. Each request initiated by the user is treated as a trace by Zipkin.

Every trace has a number of spans and every span is linked or connected to an RPC call. You can have a number of annotations in every span and there are four annotations that a span should have to be able to build a complete view of an RPC call, which is in chronological order.

The four annotations are cs, sr, ss, and cr where “cs” stands for “client send”, “sr” for “server receive”, “ss” for “server send”, and “cr” for “client receive”.