Cross application tracing in Ruby

If you use a non-standard middleware framework, follow these procedures to install and configure New Relic's cross application tracing feature. If you have problems, follow the troubleshooting procedures for cross application tracing.

New Relic also supports distributed tracing. Distributed tracing improves on cross application tracing and is recommended for large, distributed systems.


Follow these requirements to use cross application tracing with the Ruby agent:

  1. Make sure the requests being instrumented use a supported HTTP client library.
  2. Install or update to the latest Ruby agent (version or higher).
  3. Follow the requirements for middleware installation.

Middleware installation

Cross application tracing works with Rack, and therefore requires Rails 2.3 or greater, or another compatible framework.

  • If you use Rails, the Ruby agent will install the middleware automatically.
  • If you use a different Rack-based framework, manually add the NewRelic::Rack::AgentHooks middleware to your stack.


Cross application tracing can be controlled by a configuration flag.

	  enabled: true

The default for cross_application_tracer.enabled is true, even when unspecified. To disable cross application tracing, you must set this flag to false.

Cross application trace measurements

The external measurement (from the calling application) will always be larger than the internal measurement (from the called application). The external measurement is collected by New Relic's instrumentation of the HTTP client library (such as Net::HTTP). The internal measurement is taken by New Relic's instrumentation of the web framework (such as Rails) in the called application.

Here are some of the major components included in the external measurement that are not included in the internal measurement:

From calling app to target host
  • DNS time to resolve the target hostname
  • Time to establish a new TCP connection with the target host (TCP 3-way handshake plus SSL negotiation, if SSL is in use)
  • Time spent in the HTTP client library to prepare and serialize the HTTP request
  • Network latency to send the request across the wire to the target host
Receiving host
  • Time for the front-end web server on the receiving host to process the request and send it to the back-end web server on the receiving host
  • Time for the request to be parsed in the back-end web server on the receiving host
  • Time for the request to "percolate" through Rack middlewares on the receiving host
  • Time for the web framework to route the request to the appropriate controller action

Once the web framework has routed it to the appropriate controller action, this is where the internal measurement happens. Then:

  • Time for the request to "percolate" back up through the Rack middlewares
  • Network latency to write the response back to the requesting server
  • Time on the requesting host for the HTTP response to be parsed by the HTTP client library

Some of these components are easier to control than others. For example, to capture timings for the Receiving host items above, make sure you have request queue monitoring set up on the receiving application.

Get distributed tracing

New Relic also offers distributed tracing. Distributed tracing is an improvement on cross application tracing and is recommended for large, distributed systems.

For more help

If you need more help, check out these support and learning resources: