<Tech>Brunch


SpringBoot Web Services Integration with Spring Cloud Slueth and Zipkin

In Microservices ecosystem, we have distributed application and microservices. How each distributed microservice is performing, what is the latency measurment of each component, and stuffs like this can be easily monitored using Distributed Tracing.

We have implemented a simple SpringBoot web service where we have integrated Spring Cloud Sleuth and Zipkin for the purpose of Distributed Tracing. Though we have only one web service for the demo, but the process of integration for the rest of the other microservices stays the same. If we have implemented for one microservice, the process for implementation is the same for the rest, and when all the microservices have implemented this, we get a seamless distributed tracing at one place.

What is Spring Cloud Sleuth?
Spring Cloud Sleuth implements a distributed tracing solution for Spring Cloud, borrowing heavily from Dapper, Zipkin and HTrace. In simple terms, Sleuth is a tool from Spring cloud family which is used to generate the trace id, span id and add these information to the service calls in the headers and MDC, so that these can be used with tools like Zipkin and ELK etc. to store, index and process log files.

What is Zipkin?
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.

Ok, so we have a Student Microservice, which returns information related to students. The microservice is a SpringBoot application.

Steps to implement Distributed Tracing:

  • First download the zipkin jar, and start the server. Zipkin is not part of Spring Umbrella, and hence we can’t find it in Spring Initializer tool. Download the latest jar from Zipkin’s official site. Find the latest jar here.
    Alternatively:
    1
    2
    curl -sSL https://zipkin.io/quickstart.sh | bash -s
    java -jar zipkin.jar

Once we have the jar, we will start the zipkin server:

1
java -jar zipkin.jar

Zipkin will run on the default port:9041

  • Add Spring Cloud Sleuth and Zipkin Client dependency in the microservice’s pom. This step needs to be performed for all the microservices that we have. Here we have just one, so we are going to add the required dependencies in our microservice. These dependencies can be found in Spring Initializer tool.
    1
    2
    3
    4
    5
    6
    7
    8
    9
    <dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-zipkin</artifactId>
    </dependency>

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

Now, lets add some code changes. In application.properties of microservice, add an entry so that our microservice is aware where the zipkin server is:

1
2
3
4
server.port = 7788
spring.zipkin.base-url=http://localhost:9411/
spring.sleuth.sampler.probability = 1
spring.application.name = student-ws

Now we need to create a sampler Bean in our microservice, so that sleuth creates span and traces, which will be used by Zipkin:

1
2
3
4
@Bean
public AlwaysSampler alwaysSampler() {
return new AlwaysSampler();
}

  • Now, with all these changes of adding dependencies in our microservice is done, its time to start our microservice. A unique traced id is generated from Sleuth at the beginning of the request and that is passed as part of request to other services. With every service call, there will be a unique span id generated and communicated to Zipkin.