External services

The external services feature allows you to look closely at the upstream and downstream activity of a single service. Those upstream or downstream external services may be your own services you instrumented, or they may refer to services you simply call in the course of a transaction. External services does not include some backend components such as MemCache and the database itself.

The external services feature is not just for New Relic APM agent users. It also includes OpenTelemetry and uses the power of distributed tracing to give you insights into service activity. The classic external services feature is still available behind a UI toggle, but we recommend you try out the full power the expanded external services.

This feature provides a combination of maps and charts to help you:

• Find sources of latency and errors
• Assess the impact of latency to upstream callers
• Review transaction-level performance
• Find traces that involve the transactions you're interested in

To use the external services feature, you need a New Relic account with an installed APM agent with distributed tracing enabled. If you don't already have one, sign up for a free account.

Here's a short video (1:30 minutes) showing how to use the external services dashboard to track all the dependencies and services your application depends on.

When would you use external services?

The external services feature is a tool you can use by itself to tune or troubleshoot a specific service. You can also use it as a starting point for additional troubleshooting with distributed tracing.

Let's say you're a developer responsible for service A:

1. You get an alert that the average response time has increased anomalously.
2. You look at your service and see that time spent in calls to other services has increased around the time of the alert.
3. You drill into external services and see that the total time calling one service in particular, service B, increased just before the alert was fired.
4. You select service B on the map, and see the performance of individual transactions in service A that call transactions in service B. You notice that one particular transaction on service A is slower than normal, and that it calls one transaction on service B.

Then, you can use distributed tracing to drill into more detail:

1. Drill into distributed tracing and see in the trace that the calls in this transaction are doing something odd.
2. Jump to that transaction on service B and see that it got slow after a deploy.

Relationship to classic external services

While you can still reach classic external services by using the UI toggle, the main external services UI is populated by data from distributed tracing. It still provides transaction data similar to classic external services, but here are some key things you need to know about the expanded external services:

• Dependency: To use the external services feature, you need to enable distributed tracing on services that make calls to each other.
• Compatibility: Distributed tracing is not backwards compatible with cross application tracing, so if you currently rely on classic external services, please note that you will only have visibility into calls between services using the same protocol.
• Data: Unlike classic external services, the transaction-level detail of distributed tracing is based on sampling instead of metrics. This sampled data links into distributed tracing, which can give you deeper insights into what's driving the performance of the transactions.

What's next?

If you're ready to enable this feature, check out our setup steps.