Member-only story
Spring Boot Microservices — Implementing Distributed Tracing
In this article, we will learn an important patten in Microservices Architecture — Distributed Tracing. We will create a sample implementation based on Spring Boot, Spring Cloud Sleuth and Zipkin. This is the fourth part of our series — Spring Boot Microservices — Learning through examples.
What is Distributed Tracing?
Logging is an important aspect of software development. It not only helps in troubleshooting the issues but also help us in understanding the behavior of our softwares. With multiple microservices, logging becomes a multifold challenge.
Consider the example we discussed in our previous exercise — Developing Service Discovery. In this exercise, Our Shopping Cart Service needs to call Product Catalog Service to get the product details. The request is distributed across multiple services (2 in our case). If each of the services has multiple instances running, request will follow a path determined at run time.
The picture below shows just the 9 user requests getting distributed across 6 instances and it has already started looking complex. Imagine a situation when millions of transactions are getting processed with multiple participating services.
If we try to trouble shoot an issue in this environment, our monolith style logging will be as useful as nothing. The Session, Thread, or the Http Request references do not help much when the request is getting processed across multiple services. We will be lost, digging the logs.
We must have a unique request/transaction reference which should be passed across all the calls, to all the dependent microservices, in the call chain. This unique reference is usually referred as Correlation-id or Trace Id.
The Trace Id is created when the request hits the very first service in the chain. For subsequent calls, already existing Trace Id is passed…
