Distributed Tracing

What Is Distributed Tracing?

Distributed TracingDistributed tracing, or distributed request tracing, is a process that allows developers to profile, monitor, debug and better understand microservice applications. It’s especially useful in identifying root problems and pinpointing poor performance and failure locations in distributed systems.

Distributed tracing lets you track activities resulting from requests to an application, so you can trace request paths, find latency in those pathways, and identify components creating issues or bottlenecks. It’s becoming an increasingly key component for debugging and understanding application dependencies in microservices architectures.

Why Do You Need It?

Moving from a monolithic to microservice architecture changes the ways your team can identify and troubleshoot issues. It’s neither realistic nor scalable to troubleshoot an issue by isolating and reproducing it, as you would have in a monolithic structure. Microservice architectures span across services, so you need observability that also lets you see across your services.

Consistent observability of your data becomes more critical as you increase the number or complexity of your services, and pinpointing those performance issues becomes more of a challenge as requests pass through more services. With distributed tracing, you can view requests moving through services with a more holistic view, enabling you to reduce MTTD and oftentimes improve MTTR.

In addition, implementing tracing libraries across services in different frameworks or written in different languages is costly in terms of time and resources. Distributed tracing allows teams to track data as it moves through services, then assemble the data to show an application’s runtime behaviors.

Service Mesh and Distributed Tracing

Service mesh provides a simpler ways for teams to use distributed tracing when running Kubernetes and Istio.

As explained by Neeraj Poddar, when running tracing with Istio, “Istio injects a sidecar proxy (Envoy) in the pod which your application container is running. This sidecar proxy transparently intercepts all network traffic going in and out of your application. Because of this interception, the sidecar proxy is in a unique position to automatically trace all network requests (HTTP/1.1, HTTP/2.0 & gRPC).”

At Aspen Mesh, we recommend Jaeger to help you get the most out of tracing, metrics, and your service mesh. Several advantages of using Jaeger for tracing as part of your service mesh include:

Want To Get Started?

Try it out yourself in a few minutes with our Visualizing and Tracing Traffic Scenario – or get started using it in your application by signing up for the free Aspen Mesh 30-day trial.

For more specific info about a couple topics related to distributed tracing, learn more about tracing requests to AWS services when using Istio, or read about tracing gRPC applications with Istio.