Zipkin distributed tracing system project

Asked By 20 points N/A Posted on -
qa-featured

What is zipkin software provided by Twitter ? What for this tool is used ? Where exactly this tool is going to be deployed online or a mobile based tool ?

SHARE
Answered By 0 points N/A #140464

Zipkin distributed tracing system project

qa-featured

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.

Answered By 563960 points N/A #140465

Zipkin distributed tracing system project

qa-featured

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”.

Login/Register to Answer

Related Questions