In this article, learn how to implement Jaeger \u2014 which is based on OpenTracing with a Spring Boot application \u2014 and how to visualize the traces using Jaeger UI.<\/b>
\nJoin the DZone community and get the full member experience. In this article, we will explore how to implement distributed tracing using Jaeger and how to visualize the traces using Jaeger UI. Jaeger is an open-source distributed tracing mechanism that helps to trace requests in distributed systems. It is based on OpenTracing specification and is a part of the Cloud Native Computing Foundation (CNCF). I have explained some key concepts of tracing in my previous article \u201c Distributed Tracing With Spring Cloud Sleuth.\u201d With this, let\u2019s look at some code. Let\u2019s create an application from https:\/\/start.spring.io with only a single dependency of \u201cSpring Web.\u201d Once you generate and download the code, we will add the following Jaeger dependency to the pom file which will help to generate and propagate the traces between the services. With this, let’s add a controller with some paths. Here, we have two endpoints: \/path1 and \/path2. The idea here is to use two instances of the same application such that \/path1 calls \/path2 of another service at a fixed port 8090. For the spans to get connected to the same trace ID, we need to create a RestTemplate bean to allow Jaeger to include an interceptor. This then helps to add traces to the outgoing request which will help to trace the entire request. With this done, let\u2019s start a Jaeger server locally using Docker. For this, I have created a Docker Compose file with the port mappings. We can communicate with Jaeger using either via UDP or TCP. After starting the Docker image using docker-compose up, we can access the UI using the URL http:\/\/localhost:16686\/. Now, let’s add some properties to allow the application to send the traces to the Jaeger server. We will communicate via TCP, so make sure that we send the traces to the other TCP port, i.e 14268 Let\u2019s start \u201cServer 1\u201d with the below command. Then on a different terminal, run a new instance of the same application as \u201cService 2\u201d as follows Once the application starts, call \u201cService 1\u201d at \/path1 as follows Let\u2019s look at the logs of \u201cService 1.\u201d The tracing is of the format [Root Span ID, Current Span ID, Parent Span ID]. In this case, since \u201cService 1\u201d is the originating service, the parent span ID ed70bbaa2bd5b42f is also the root span ID. Now, let\u2019s look at the logs of \u201cService 2.\u201d Here we see that the middle value is the current span ID and the parent span ID (ie. the third value c7c94163fc95fc1e) is the span ID of \u201cService 1\u201d. Now, if you open the UI you will see the following: When we dig deeper, we see more details on each of the spans. Here, the root span id ed70bbaa2bd5b42f spans across the entire request. The other two span IDs refer to individual services. Today we explored how we can integrate Jaeger, which is based on OpenTracing with a Spring Boot application. You can always read more in-depth about the specification of OpenTracing here. Also, the library documentation for using Spring Cloud Jaeger is here. I have uploaded the code on GitHub. You can read about distributed tracing using Zipkin my previous article here. I keep exploring and learning new things. If you want to know the latest trends and improve your software development skills, then follow me on Twitter. Enjoy!! Published at DZone with permission of Amrut Prabhu. See the original article here. Opinions expressed by DZone contributors are their own.<\/p>\n