Enabling New Relic Distributed Tracing in Java Microservices: Setup, Trade‑offs, and Verification

Why Distributed Tracing Matters for Java Microservices

When a request hops from Service A to Service B, Service C, and so on, latency can creep in at any hop. New Relic Distributed Tracing stitches the individual Transaction spans into a single end‑to‑end trace, letting you see exactly where the slowdown occurs. Without it, you’re left with a collection of unrelated metrics.

Prerequisites & Quick Checklist

• Java agent version 8.0 or newer installed on each service.
• APM plan that includes Distributed Tracing (not all free tiers).
• Network connectivity from agents to New Relic ingest endpoints.
• Root‑level or equivalent shell access to modify the agent configuration.

Step 1: Enable the Feature in the Agent

Open the newrelic.yml (or newrelic.ini) that ships with the Java agent and add or modify the following line:

distributed_tracing.enabled: true

Save the file and restart the Java process. The agent will emit a log line on startup:

2026-10-12 23:25:00,123 [INFO] New Relic Java Agent 8.2.1: Distributed tracing enabled.

To confirm the setting is read, run the helper command from the agent’s bin directory:

./newrelic-admin check

Look for Distributed tracing: enabled in the output.

Step 2: Tune Sampling and Trace Duration

Tracing every request can overwhelm your agent and ingest pipeline. Two knobs help:

• trace_sample_rate – the fraction of transactions to trace (default 1%).
• max_trace_duration – maximum span duration to include in a trace (default 30 s).

Example newrelic.yml snippet:

distributed_tracing:
  enabled: true
  max_trace_duration: 120000   # 120 s in milliseconds
  trace_sample_rate: 0.05      # 5% of transactions

After changing these, restart the service.

Step 3: Verify Traces in the UI and via NRQL

1. Send a test request to Service A (e.g., curl -X GET http://service-a.local/api).
2. Navigate to APM → Traces in the New Relic UI. You should see a new trace entry with spans for Service A, B, C, etc.
3. Use NRQL to query the same data: SELECT * FROM Transaction WHERE traceId = '...' . Replace '...' with the traceId shown in the UI.
4. Alternatively, check the ingestion rate: SELECT count(*) FROM Transaction WHERE traceId IS NOT NULL. A non‑zero count indicates traces are being collected.

Trade‑offs and Limitations

• Performance Impact: Enabling tracing adds ~5–10 % CPU and memory overhead. Monitor nrjvm metrics and adjust trace_sample_rate if necessary.
• Log Size: Traces increase log volume. Ensure your log aggregation pipeline can handle the extra data.
• Plan Restrictions: Distributed Tracing is not available on all free plans. Verify your plan in the New Relic account settings.
• Agent Compatibility: Older agents (<8.0) do not support Distributed Tracing. Upgrade if you see missing trace columns.

Actionable Takeaway

Start by enabling distributed_tracing.enabled on a single service, set a conservative trace_sample_rate, and verify a trace appears in the UI. Once you’re comfortable with the overhead, roll the change out to the rest of the microservices. Keep an eye on CPU usage and adjust sampling or max_trace_duration as traffic grows.