11 Distributed tracing with Spring Cloud Sleuth and Zipkin

The microservices architecture is a powerful design paradigm for breaking down complex monolithic software systems into smaller, more manageable pieces. These manageable pieces can be built and deployed independently of each other; however, this flexibility comes at a price: complexity. Because microservices are distributed by nature, trying to debug where a problem is occurring can be maddening. The distributed nature of the services means that we have to trace one or more transactions across multiple services, physical machines, and different data stores, and try to piece together what exactly is going on.

This chapter lays out several techniques and technologies for making distributed debugging possible. In this chapter, we look at the following:   

11.1  Spring Cloud Sleuth and the correlation ID

11.1.1      Adding Spring Cloud sleuth to licensing and organization

11.1.2     Anatomy of a Spring Cloud Sleuth trace

11.2  Log aggregation and Spring Cloud Sleuth

11.2.1    A Spring Cloud Sleuth/ELK stack implementation in action

11.2.2       Configure logback in our services.

11.2.3     Define and run ELK stack applications in Docker

11.2.4     Configuring Kibana

11.2.5    Searching for Spring Cloud Sleuth Trace IDs in Kibana

11.2.6   Adding the correlation ID to the HTTP response with Spring Cloud Gateway

11.3  Distributed tracing with Open Zipkin

11.3.1     Setting up the Spring Cloud Sleuth and Zipkin dependencies

11.3.2    Configuring the services to point to Zipkin

11.3.3     Configuring a Zipkin Server

11.3.4   Setting tracing levels

11.3.5    Using Zipkin to trace transactions

11.3.6    Visualizing a more complex transaction

11.3.7    Capturing messaging traces

11.3.8    Adding custom spans

11.4  Summary