Another crucial ingredient for a successful reactive system operation is to have an understanding of how events flow across the services, how requests stack-up, and how long this takes. As stated in Chapter 8, Scaling Up with Cloud Streams, communication between services is an essential part of a distributed system operation and some problems can not be resolved without the full picture of the data flow. However, taking all the complexity of communications in a distributed system into account, such capturing is a very complicated task. Fortunately, Spring Cloud provides an excellent module called spring-cloud-sleuth. Spring Cloud Sleuth is a project well-integrated with Spring Boot 2.x infrastructure, enabling distributed tracing with just a few bits of auto-configuration.
Even though most modern tracing tools such as Zipkin or Brave do not fully support new Spring reactive web services, Spring Cloud Sleuth naturally fills that gap.
First of all, there is an identical replacement of WebMVC filters for WebFlux called org.springframework.cloud.sleuth.instrument.web.TraceWebFilter. That filter guarantees that all incoming HTTP requests are carefully analyzed and any tracing headers that are found are reported to Zipkin. In turn, with the support of org.springframework.cloud.sleuth.instrument.web.client.TracingHttpClientInstrumentation, all outgoing requests are adjusted with additional tracing headers as well. To track outgoing requests, we have to register WebClient as a context bean instead of creating it each time; otherwise, the proper instrumentation does not happen.
We also have to clarify how all the tracing spans are stored and passed in the reactive programming paradigm. As we might learn from the previous chapters, reactive programming does not guarantee that all of the transformations are executed on the same thread. This means that metadata transferring through ThreadLocal, the primary tracing pattern for WebMVC, does not work here in the same way as in the imperative programming paradigm. However, thanks to the composition of the reactor's Context mechanism (described in Chapter 4, Project Reactor - the Foundation for Reactive Apps), Reactor's global Hooks, and org.springframework.cloud.sleuth.instrument.web.client.TraceExchangeFilterFunction, it became possible to transfer additional contextual metadata through the reactive flow without ThreadLocal.
Finally, Spring Cloud Sleuth provides a few ways to report collected tracing information to the Zipkin server. The most common method of delivery is through HTTP. Unfortunately, at the moment this method is implemented in a blocking manner. Nevertheless, the default zipkin2.reporter.AsyncReporter sends spans (pieces of tracing information) to the Zipkin server on a separate Thread. So despite the blocking nature, such a technique might be pretty efficient even in a reactive application since callers on the reactive side are protected from blocking request latency or potential exceptions.
Along with the traditional data delivery protocol over HTTP, there is a message queue-based option. Spring Cloud Sleuth provides excellent support for Apache Kafka and RabbitMQ. Even though the client for Apache Kafka supports asynchronous, non-blocking message passing, the underlying mechanism still uses the same AsyncReporter that downgrades non-blocking communication to a blocking one.
Spring Cloud Sleuth brings distributed tracing support for Reactive Spring WebFlux and Spring Cloud Streams. Moreover, to start using this great tool in the project, all that is needed is to require the following dependencies in the project (Gradle config):
compile('org.springframework.cloud:spring-cloud-starter-sleuth') compile('org.springframework.cloud:spring-cloud-starter-zipkin')
Furthermore, relying on project dependencies and available environment, Spring Boot Autoconfiguration prepares all beans needed for distributed tracing at runtime.