Introduction to distributed tracing

New Relic offers distributed tracing for monitoring and analyzing modern distributed systems. This document explains:

What is distributed tracing?

Modern applications and sites increasingly use many interconnected services. An application architecture that relies on many services or microservices is often referred to as a distributed system.

Distributed tracing is the process of tracking the activity resulting from a request to an application. With this feature, you can:

  • Trace the path of a request as it travels across a complex system
  • Discover the latency of the components along that path
  • Know which component in the path is creating a bottleneck

Distributed tracing from New Relic

Distributed tracing main UI page
rpm.newrelic.com/apm > (select an application) > Distributed tracing > Trace details: Once you select a trace, you can see its services and spans, including any anomalous spans. You can zoom in on a specific time range and examine a span's duration and other performance data. For more details about the UI, see the UI documentation.

Distributed tracing lets you see the path that a request takes as it travels through a distributed system. A distributed trace is composed of multiple spans, which represent time spent in services or resources of those services.

Distributed tracing features include:

Enable distributed tracing

The distributed tracing feature can use data from a variety of sources. To enable, see the documentation for a specific data source:

Relationship to cross application tracing

Our distributed tracing feature replaces the previous cross application tracing feature. Compared to cross application tracing, distributed tracing gives more detail about cross-service activity and provides more complete end-to-end visibility.

Support for W3C Trace Context

New Relic supports the W3C Trace Context standard for distributed tracing. This initiative addresses the problems with broken traces that occur when distributed tracing vendors identify transactions with their own proprietary HTTP header formats.

A diagram showing the failure of a proprietary header.
Traces can be broken by incompatible headers.

HTTP headers act like passports on an international trip: They identify your software traces and carry important information as they travel through various networks, processes, and security systems. If these headers don't follow a standard format, you can have some problems:

  • The headers themselves might not get passed between each process as a request travels through your system.
  • Tracing software can't always stitch together each segment (span) to show the entire trip of a request.

To resolve these problems, the W3C specification defines a standardized format for trace context headers. This makes sure header information, including a single unified trace identifier, is propagated across all of the services or systems in a transaction.

For more details about W3C Trace Context at New Relic:

For more help

Recommendations for learning more: