A distributed tracing feature is now available. Distributed tracing improves on cross application tracing and is recommended for monitoring activity in large, distributed systems.
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.
Follow these requirements to use cross application tracing with the Ruby agent:
- Make sure the requests being instrumented use a supported HTTP client library.
- Install or update to the latest Ruby agent (version 126.96.36.199 or higher).
- Follow the requirements for 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 framwork, manually add the
NewRelic::Rack::AgentHooksmiddleware to your stack.
Cross application tracing can be controlled by a configuration flag.
cross_application_tracer enabled: true
The default for
true, even when unspecified. To disable cross application tracing, you must set this flag to
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.