What Is New Relic Distributed Tracing?
New Relic distributed tracing is an application performance monitoring capability that tracks requests as they travel across microservices, applications, databases, and external services. It helps developers understand how requests are processed, identify performance bottlenecks, and investigate failures in distributed systems.
In modern applications, a single request may pass through multiple services before completing. Each service performs a specific operation, and delays in one component can affect the overall response time.
New Relic connects these operations using traces and spans. A trace represents the complete execution path of a request, while spans represent individual operations performed along that path.
By collecting and visualizing tracing data, New Relic helps engineers identify slow services, examine service dependencies, and troubleshoot application performance issues.
New Relic supports distributed tracing through its APM agents, OpenTelemetry instrumentation, and other compatible telemetry integrations.
In simple terms: New Relic distributed tracing tracks requests across multiple services, helping engineers understand application performance, identify slow operations, and troubleshoot errors in distributed applications.
Why Is New Relic Distributed Tracing Important?
Modern applications increasingly rely on microservices, containers, serverless functions, and cloud infrastructure. A single transaction may involve several independently deployed services before returning a response.
Traditional application monitoring can identify slow response times or increased error rates, but it may not reveal which downstream operation caused the problem.
Distributed tracing addresses this challenge by connecting related operations into a single request timeline.
For example, an e-commerce application takes four seconds to complete a checkout request. The request passes through authentication, inventory, payment, and order services. New Relic distributed tracing reveals that the payment service accounts for three seconds of the total request duration.
This information helps engineers focus on the affected dependency rather than investigating every service separately.
New Relic distributed tracing also helps teams understand how services interact, identify recurring latency patterns, and evaluate the impact of application changes.
How Does New Relic Distributed Tracing Work?
New Relic distributed tracing collects information about request execution across instrumented services and combines related operations into a distributed trace.
The process generally involves four stages.
1. Instrumenting Application Services
New Relic uses application monitoring agents and compatible instrumentation to capture operations performed during request processing.
These operations may include incoming HTTP requests, outgoing API calls, database queries, and internal application functions.
Each operation generates a span containing information such as its name, duration, identifiers, and attributes.
For example, when an order service sends a request to a payment API, instrumentation creates a span representing that outgoing operation.
2. Propagating Trace Context
When requests move between services, tracing identifiers must be preserved so the operations remain connected.
New Relic supports trace context propagation using compatible formats, including W3C Trace Context.
The trace ID identifies the complete distributed request, while span IDs and parent relationships connect individual operations.
This allows tracing systems to reconstruct the execution path across different services.
3. Collecting and Processing Spans
Instrumented services send tracing information to New Relic.
The platform processes received spans and associates them with their corresponding distributed traces.
Depending on the tracing configuration, sampling may occur before telemetry is sent or after trace data reaches a processing service.
Sampling helps manage the amount of tracing information retained for analysis.
4. Visualizing Distributed Traces
Once tracing data is available, engineers can search for and inspect traces through New Relic's distributed tracing interface.
New Relic provides trace details through Map, Timeline, and Latency views, along with a waterfall representation of individual operations.
For example, a trace may reveal that an API gateway takes 25 milliseconds, authentication takes 80 milliseconds, and a downstream database operation takes 950 milliseconds.
These views help engineers understand request execution and identify operations contributing to latency.
Learn more in the New Relic distributed tracing documentation.
Understanding Traces and Spans in New Relic
Traces and spans are the fundamental building blocks of distributed tracing.
A trace represents the complete path of a request through an application. Every span belonging to that trace shares the same trace ID.
A span represents an individual operation, such as processing an HTTP request, executing a database query, or calling another service.
Spans also contain attributes that provide additional context about the recorded operation.
Consider the following transaction:
API Gateway → Authentication Service → Order Service → Payment Service
New Relic can represent the operations as connected spans.
| Service | Operation | Duration |
|---|---|---|
| API Gateway | Receive request | 20 ms |
| Authentication | Validate user | 60 ms |
| Order Service | Process order | 120 ms |
| Payment Service | Process payment | 850 ms |
Example: The payment service consumes significantly more time than other operations, making it a useful starting point for investigating checkout latency.
Because spans can overlap, their individual durations should not automatically be added together to calculate total request time.
New Relic uses span relationships to reconstruct the request execution structure and help engineers understand how operations depend on one another.
What Is New Relic Infinite Tracing?
Infinite Tracing is an advanced distributed tracing capability in New Relic that uses tail-based sampling to select traces for retention.
Traditional tracing implementations often make sampling decisions when a request begins. This is known as head-based sampling.
Infinite Tracing allows trace data to be sent to New Relic's managed trace processing service, where sampling decisions can be made after observing the trace information.
This enables the system to prioritize traces based on characteristics such as duration, errors, and configured span attributes.
For example, an application processes thousands of successful requests alongside a small number of unusually slow transactions. Infinite Tracing can prioritize retaining traces with abnormal latency rather than relying entirely on random selection.
Infinite Tracing can analyze incoming trace data before deciding which traces to retain. However, this does not mean that every trace is permanently stored.
New Relic's documentation also notes that Infinite Tracing requires account activation, has regional availability restrictions, and is subject to edition requirements.
Head-Based vs. Tail-Based Sampling
Sampling determines which traces are retained for analysis.
New Relic supports different sampling approaches depending on the instrumentation and tracing configuration.
| Feature | Head-Based Sampling | Tail-Based Sampling |
|---|---|---|
| Sampling decision | Near the beginning of a request | After observing trace data |
| Trace visibility | Limited information when deciding | More information about completed operations |
| Processing requirements | Generally lower | Requires additional processing |
| Error prioritization | Depends on predefined sampling rules | Can prioritize traces containing errors |
| Common New Relic use | Standard distributed tracing | Infinite Tracing |
For example, head-based sampling may discard a request before its outcome is known. Tail-based sampling can examine the completed trace and choose to retain it because it contains an error or unusually high latency.
Both approaches involve trade-offs between data retention, processing requirements, and visibility.
The appropriate sampling strategy depends on application traffic, investigation requirements, and telemetry costs.
Key Features of New Relic Distributed Tracing
New Relic provides several capabilities for investigating distributed requests and understanding service-level performance.
End-to-End Request Visibility
New Relic connects spans generated across instrumented services into distributed traces.
This helps engineers follow requests through APIs, application services, and downstream dependencies.
For example, a checkout transaction passes through five microservices. New Relic displays the connected operations, allowing engineers to understand how the request was processed.
Trace Visualization
New Relic's trace details interface provides Map, Timeline, and Latency views for examining trace execution.
Engineers can also inspect individual spans through a waterfall visualization to understand operation timing and execution relationships.
These views help reveal slow operations, service dependencies, and potential bottlenecks.
Error Investigation
Spans can contain error information and attributes that help engineers understand where failures occurred.
For example, a transaction fails because a downstream API returns an error. Engineers can inspect the affected span to identify the failing service interaction.
Service Dependency Analysis
New Relic provides visualizations that help engineers understand relationships between participating services.
This information is useful when multiple components depend on the same downstream application or infrastructure resource.
OpenTelemetry Integration
New Relic supports OpenTelemetry instrumentation, enabling applications to report standardized tracing data.
This allows organizations to use OpenTelemetry APIs, SDKs, and collectors while analyzing supported telemetry in New Relic.
How New Relic Helps Troubleshoot Microservices
Distributed tracing is particularly useful when investigating performance issues involving multiple services.
Identifying Performance Bottlenecks
When application response times increase, engineers can examine distributed traces to identify which operations contribute most to the delay.
For example, an order-processing API takes two seconds to respond. A New Relic trace reveals that an inventory database query accounts for most of the request duration.
Investigating Failed Requests
Distributed tracing helps engineers follow a failed transaction across services.
By inspecting the relevant spans, teams can identify where errors occurred and determine which downstream operations require investigation.
For example, payment requests fail intermittently because a third-party API returns errors. Distributed tracing helps identify the affected service calls.
Understanding Service Dependencies
Applications often share common dependencies, making it difficult to determine how failures propagate.
Distributed tracing provides visibility into these relationships.
For example, checkout, billing, and subscription services all depend on the same authentication service. Trace data helps engineers understand how authentication failures affect these applications.
New Relic Distributed Tracing vs. Zipkin
New Relic and Zipkin both provide distributed tracing capabilities, but they differ in scope and implementation.
Zipkin is an open-source distributed tracing system primarily focused on collecting, storing, and visualizing traces.
New Relic distributed tracing is part of a broader commercial observability platform that combines tracing with application monitoring and other telemetry capabilities.
| Feature | New Relic | Zipkin |
|---|---|---|
| Primary purpose | Distributed tracing within an observability platform | Open-source distributed tracing |
| Trace visualization | Yes | Yes |
| Service dependencies | Supported | Supported |
| OpenTelemetry integration | Supported | Supported through compatible integrations |
| Trace sampling | Head-based and Infinite Tracing | Sampling through compatible instrumentation |
| Logs and metrics | Available within the broader platform | Requires additional monitoring tools |
| Deployment | Managed platform | Self-hosted deployment options |
Zipkin may suit teams seeking a dedicated open-source tracing backend, while New Relic provides integrated tracing alongside broader application monitoring capabilities.
New Relic Distributed Tracing vs. OpenTelemetry
New Relic distributed tracing and OpenTelemetry serve different purposes.
New Relic provides a platform for analyzing distributed traces and related application telemetry.
OpenTelemetry provides standardized APIs, SDKs, instrumentation libraries, and collection components for generating and exporting telemetry.
| Feature | New Relic | OpenTelemetry |
|---|---|---|
| Primary purpose | Observability and trace analysis | Telemetry instrumentation and collection |
| Distributed tracing | Supported | Supported |
| Trace visualization | Built-in interface | Requires a compatible backend |
| Trace storage | Managed by New Relic | Requires a storage backend |
| Instrumentation | New Relic agents and compatible integrations | Vendor-neutral instrumentation |
| Metrics and logs | Supported within the platform | Supported |
OpenTelemetry can send tracing data to New Relic through supported ingestion methods.
This separation allows applications to use standardized instrumentation without requiring every service to depend on proprietary telemetry APIs.
How to Enable Distributed Tracing in New Relic
Enabling New Relic distributed tracing generally involves instrumenting applications, configuring trace propagation, and verifying that tracing data reaches the platform.
1. Identify Application Services
Start by identifying the services involved in important application workflows.
These may include frontend applications, backend APIs, databases, and external services.
2. Configure Instrumentation
Use supported New Relic APM agents or OpenTelemetry instrumentation to capture tracing information.
The configuration process depends on the programming language, framework, and deployment environment.
3. Enable Trace Context Propagation
Ensure tracing information is propagated between services through compatible request headers or messaging metadata.
Missing or incorrectly configured propagation can result in disconnected traces.
4. Verify Trace Collection
Generate application traffic and examine the collected traces through New Relic.
For example, submit a test checkout request and verify that the resulting trace includes the checkout, payment, and inventory operations.
New Relic provides language-specific setup instructions and different configuration options for standard distributed tracing and Infinite Tracing.
See the official setup documentation.
Limitations of New Relic Distributed Tracing
New Relic distributed tracing provides detailed request visibility, but its effectiveness depends on instrumentation coverage and tracing configuration.
If an application service is not instrumented or does not propagate trace context correctly, traces may become incomplete.
Sampling can also limit visibility. When only a portion of requests is retained, some infrequent errors or performance problems may not appear in the collected data.
In distributed applications with asynchronous processing, traditional parent-child relationships may not represent every workflow. Span links can provide additional context for related operations across separate traces.
New Relic supports span links in its trace details interface, although visibility depends on correctly propagated context and retained trace data.
Organizations should also evaluate trace ingestion, data retention, and feature availability when planning distributed tracing deployments.
How Middleware Helps With Distributed Tracing
Middleware is an OpenTelemetry-native observability platform that provides distributed tracing, application performance monitoring, logs, metrics, and infrastructure visibility in a unified environment.
Like New Relic, Middleware helps engineering teams investigate distributed applications. Its OpenTelemetry-native approach emphasizes standardized instrumentation and telemetry portability.
Trace Requests Across Microservices
With Middleware Application Performance Monitoring, developers can follow requests across instrumented services and identify operations contributing to application latency.
For example, when a checkout API becomes slow, Middleware can help determine whether the delay originates in authentication, payment processing, or a downstream database.
Investigate Traces With Multiple Views
Middleware's Trace Explorer provides four connected visualization options: Waterfall, Flame Graph, Spans, and Map.
Engineers can examine request timing, identify the slowest spans, inspect execution relationships, and filter operations based on errors, logs, or events.
Selecting a span also provides access to its attributes and related diagnostic information.
Correlate Traces With Logs and Metrics
Middleware connects distributed traces with logs, metrics, and infrastructure information.
This helps engineers investigate performance issues without manually correlating telemetry across disconnected monitoring tools.
For example, a distributed trace identifies a slow database operation. Engineers can examine related logs and infrastructure metrics to determine whether the delay is associated with query execution, application errors, or resource pressure.
Use OpenTelemetry-Native Instrumentation
Middleware supports standard OpenTelemetry instrumentation, helping organizations maintain portability across application environments.
This approach allows teams to collect tracing information using open standards while analyzing it through Middleware's observability platform.
For implementation details, see the Middleware Trace Explorer documentation.
Best Practices for Distributed Tracing
Maintain instrumentation coverage: Ensure critical services and dependencies generate tracing data so request execution remains visible across service boundaries.
Preserve trace context: Configure compatible propagation formats to prevent disconnected traces and missing service relationships.
Apply appropriate sampling: Choose sampling policies based on application traffic, troubleshooting requirements, and telemetry retention costs.
Monitor critical transactions: Prioritize important workflows such as authentication, payments, and order processing.
Combine tracing with logs and metrics: Use multiple telemetry sources to understand both request-level symptoms and their underlying causes.
Review traces after deployments: Compare latency patterns and errors following application changes to identify potential performance regressions.
Frequently Asked Questions
What is New Relic distributed tracing in simple terms?
New Relic distributed tracing tracks requests as they travel across multiple application services. It helps engineers understand request execution, identify slow operations, and troubleshoot errors in distributed applications.
How does New Relic distributed tracing work?
New Relic collects spans from instrumented services and connects them using trace identifiers. These spans form distributed traces that show how requests move across services and how long individual operations take.
What is Infinite Tracing in New Relic?
Infinite Tracing is a New Relic capability that uses tail-based sampling to analyze trace data before deciding which traces to retain. It helps prioritize useful traces based on characteristics such as latency and errors.
What is the difference between New Relic distributed tracing and APM?
APM monitors application performance through metrics such as response time, throughput, and error rate. Distributed tracing provides request-level visibility across services, helping engineers investigate the operations responsible for performance problems.
Does New Relic support OpenTelemetry?
Yes. New Relic supports OpenTelemetry instrumentation and compatible telemetry ingestion, allowing applications to send standardized tracing data to the platform.
What is the difference between New Relic and Zipkin?
New Relic provides distributed tracing within a broader observability platform, while Zipkin is an open-source tracing system focused primarily on collecting and analyzing distributed traces.
Can New Relic trace Kubernetes applications?
Yes. New Relic can collect distributed tracing information from instrumented applications running in Kubernetes. Tracing can also be combined with Kubernetes infrastructure monitoring to investigate application and resource-level performance issues.
Does New Relic distributed tracing support sampling?
Yes. New Relic supports head-based sampling for standard tracing configurations and tail-based sampling through Infinite Tracing. The available sampling behavior depends on instrumentation and configuration.
Can New Relic identify the root cause of an application issue?
New Relic distributed tracing helps narrow down possible causes by revealing slow operations, errors, and service dependencies. Confirming the underlying cause may require additional information from logs, metrics, and infrastructure monitoring.
Conclusion
New Relic distributed tracing helps engineering teams understand how requests move through distributed applications. By collecting spans and connecting them into traces, it provides visibility into request execution, service dependencies, and performance bottlenecks.
Features such as trace visualization, sampling, Infinite Tracing, and OpenTelemetry integration help teams investigate application latency and errors across microservices.
However, distributed tracing is most effective when combined with logs, metrics, and infrastructure monitoring.
Observability platforms such as Middleware provide an alternative approach by bringing distributed tracing and related telemetry together through OpenTelemetry-native instrumentation, helping teams investigate performance issues with connected application context.