Zipkin distributed tracing system

Zipkin is a distributed tracing system. It helps gather /manage timing data needed to troubleshoot latency problems in microservice architectures. Twitter developed the technology using a Google paper that described Google’s internally-built distributed app debugger, Dapper.

Applications are instrumented to report timing data to Zipkin. The Zipkin UI presents a Dependency diagram showing how many traced requests went through each application. If you are troubleshooting latency problems or errors, you can filter or sort all traces based on the application, length of trace, annotation, or timestamp. Once you select a trace, you can see the % of the total trace time each span takes.

Whenever a request comes in, Zipkin application, traces it as it goes through the system. Each request gets a unique identifier, which is passed along with the request to each microservice. For Zipkin to work, each microservice is instrumented with Zipkin library that the service then uses identify the request’s entry and exit ports. Libraries are available for C#, Java, JavaScript, Python, Go, Scala and Ruby.

Request data is transmitted back to a Zipkin server, which is captured by Node.js and stored in Cassandra. It is left to the user to establish the communication protocol between the emitter and the collector; for his class, Gehard uses RabbitMQ. Scribe, HTTP, and Kafka are also recommended as transport mechanisms.

Zipkin comes with a Web interface that shows the amount of traffic each microservice instance is getting. The log data can be filtered by application, length of trace, annotation, or timestamp.

Below is Intro video :

Quick start :

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.