Part 8 – Distributed Tracing with Sleuth & Zipkin in Microservices

What have we learned so far,

PART 1 – MICROSERVICES INTRODUCTION – In this tutorial, we discussed what microservices architecture is and how its different from monolithic architecture.

 PART 2 – SCENARIO TO DEVELOP – In this tutorial, we discussed the scenario to develop.

PART 3 – FEIGN CLIENT – In this tutorial, we discussed how feign client simplifies the rest client consumption.

PART 4 – RIBBON CLIENT – In this tutorial, we discussed how ribbon client handles the client side load balancing.

PART 5 – EUREKA NAMING SERVER – In this tutorial, we discussed how Eureka Naming Server is used to dynamically register the services at one place.

PART 6 – ZUUL GATEWAY – In this tutorial, we discussed how Zuul gateway acts as a single entry point to our application.

PART 7 – DISTRIBUTED TRACING WITH SPRING CLOUD SLEUTH – In this tutorial, we discussed how Spring sleuth used to generate logs with trace and span ids.

What is Zipkin?

How to log the distributed logs at one place in microservices?

Zipkin is a distributed tracing system. It helps gather timing data needed to troubleshoot latency problems in microservice architectures. It manages both the collection and lookup of this data. Zipkin’s design is based on the Google Dapper paper.

Applications are instrumented to report timing data to Zipkin. The Zipkin UI also 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 percentage of the total trace time each span takes which allows you to identify the problem application.

Till now we have configured sleuth which was giving the trace id to find out the logs from different applications. But the problem with sleuth is its distributed and it becomes very difficult to check all log files one by one to check the logs. Zipkin will solve this problem by giving the central access to all the distributed logs. Lets see how we can implement it.

1. Download the zipkin server from Java section :
https://zipkin.io/pages/quickstart.html

2. After downloading the jar file fire below command to start the zipkin server
java -jar zipkin.jar
This will start the zipkin server on http://localhost:9411
Please follow below url to setup the zipkin server.
Setup Zipkin Server

3. Add below entry in pom file for account-service &customer-service projects

<dependency>
 <groupId>org.springframework.cloud</groupId>
 <artifactId>spring-cloud-starter-zipkin</artifactId>
</dependency>

4. Add below entry in application.properties file for account-service & customer-service projects

spring.zipkin.base-url=http://localhost:9411/
spring.sleuth.sampler.probability=1

5. Zipkin server internally uses jms to recieve the logs from all the running applications. Please follow Setting up RabbitMQ url to install and start the RabbitMQ server.

6. Now hit the below URL :
http://localhost:8100/accounts/1

7. Open zipkin with http://localhost:9411.
Now it will show the accounts request and its internal rest calls and their logs on same console.
Select the service for which we want to get more information and it will show all the internal rest calls with response time.

Lets see how Zipkin maintains the distributed logs. Every service sends the log with traceId to the RabbitMQ(JMS) server. Zipkin keeps observing thee logs and shows them on dashboard,