Understanding Distributed Tracing

In this chapter, we will learn how to use distributed tracing to better understand how our microservices cooperate, for example, in fulfilling a request sent to the external API. Being able to utilize distributed tracing is essential for being able to manage a system landscape of cooperating microservices. As already described in Chapter 8, Introduction to Spring Cloud, Micrometer Tracing will be used to collect trace information, and Zipkin will be used for the storage and visualization of said trace information.

In this chapter, we will learn about the following topics:

• Introducing distributed tracing with Micrometer Tracing and Zipkin.
• How to add distributed tracing to the source code.
• How to programmatically add information to the traces.
• How to perform distributed tracing, visualizing both successful and unsuccessful API requests. We will see how both synchronous and asynchronous processing can be visualized.
...

Technical requirements

For instructions on how to install the tools used in this book and how to access the source code for this book, see:

• Chapter 21, Installation Instructions for macOS
• Chapter 22, Installation Instructions for Microsoft Windows with WSL 2 and Ubuntu

The code examples in this chapter all come from the source code in $BOOK_HOME/Chapter14.

If you want to view the changes applied to the source code in this chapter, that is, see what it took to add distributed tracing using Micrometer Tracing and Zipkin, you can compare it with the source code for Chapter 13, Improving Resilience Using Resilience4j. You can use your favorite diff tool and compare the two folders, $BOOK_HOME/Chapter13 and $BOOK_HOME/Chapter14.

Introducing distributed tracing with Micrometer Tracing and Zipkin

To recapitulate Chapter 8, Introduction to Spring Cloud, in reference to the Using Micrometer Tracing and Zipkin for distributed tracing section, the tracing information from a complete workflow is called a trace or a trace tree, and sub-parts of the tree, for example, the basic units of work, are called spans. Spans can consist of sub-spans forming the trace tree. Metadata can be added to a trace and its spans as key-value pairs called tags. The Zipkin UI can visualize a trace tree and its spans as follows:

Figure 14.1: Example of a trace with its spans

Micrometer Tracing is used to collect trace information, propagate trace contexts (for example, trace and span IDs) in calls to other microservices and export the trace information into trace analysis tools like Zipkin. The handling of the trace information is done under the hood, by a tracer. Micrometer supports auto-configuration of tracers based on...

Adding distributed tracing to the source code

In this section, we will learn how to update the source code to enable distributed tracing. This can be done with the following steps:

1. Add dependencies to the build files to bring in Micrometer Tracing with a tracer implementation and a reporter.
2. Add a Zipkin server to the Docker Compose files.
3. Configure the microservices to send trace information to Zipkin.
4. Add workarounds for the lacking support of reactive clients.
5. Add code for creating custom spans and custom tags in existing spans.

We will go through each of the steps in turn.

Adding dependencies to build files

To be able to utilize Micrometer Tracing and the ability to export trace information to Zipkin, we need to add a dependency to the selected tracer and reporter to the Gradle project build files, build.gradle.

This is accomplished by adding the following two lines:

implementation 'io.micrometer:micrometer-tracing...

Trying out distributed tracing

With the necessary changes to the source code in place, we can try out distributed tracing. We will do this by performing the following steps:

1. Build, start, and verify the system landscape.
2. Send a successful API request and see what trace information we can find in Zipkin related to this API request.
3. Send an unsuccessful API request and see what error information we can find.
4. Send a successful API request that triggers asynchronous processing and see how its trace information is represented.

We will discuss these steps in detail in the upcoming sections.

Starting up the system landscape

Let’s start up the system landscape. Build the Docker images with the following commands:

cd $BOOK_HOME/Chapter14
./gradlew build && docker-compose build

Start the system landscape in Docker and run the usual tests with the following command:

./test-em-all.bash start

Before we can call the...

Summary

In this chapter, we learned how to use distributed tracing to understand how our microservices cooperate. We learned how to use Micrometer Tracing to collect trace information, and Zipkin to store and visualize the trace information.

We saw how adding Micrometer Tracing to microservices is affected by adding a couple of dependencies to the build files and setting up a few configuration parameters. Reactive microservices are currently not fully supported, but we learned how to work around the most important issues. If required, we can use the Observation API to create custom spans or add tags to all spans created by a microservice. We also saw how the Zipkin UI makes it very easy to identify which part of a complex workflow caused either an unexpectedly long response time or an error. Both synchronous and asynchronous workflows can be visualized with the Zipkin UI.

In the next chapter, we will learn about container orchestrators, specifically Kubernetes. We will learn...

Questions

1. What is the purpose of the management.tracing.sampling.probability configuration parameter?
2. How can you identify the longest-running request after executing the test-em-all.bash test script?
3. How can we find requests that have been interrupted by a timeout introduced in Chapter 13, Improving Resilience Using Resilience4j?
4. What does the trace look like for an API request when the circuit breaker introduced in Chapter 13, Improving Resilience Using Resilience4j, is open?
5. How can we locate APIs that failed on the caller not being authorized to perform the request?
6. How can we programmatically add trace information?