New Relic’s APM and Infrastructure products are fundamentally different tools, often conflated, that address distinct but complementary aspects of application and system health.
Let’s see them in action. Imagine a web application running on a few servers.
Here’s a simplified view of what an APM agent might be reporting:
{
"transaction": {
"name": "WebTransaction/MVC/UserController/GET_index",
"duration": 0.550, // seconds
"error_count": 0,
"database_call_count": 3,
"external_call_count": 1
},
"database": {
"name": "MySQL",
"query": "SELECT * FROM users WHERE id = ?",
"duration": 0.210 // seconds
},
"external_service": {
"host": "api.thirdparty.com",
"duration": 0.300 // seconds
}
}
And here’s what the Infrastructure agent might be reporting for one of those servers:
{
"host": "webserver-01",
"cpu_percent": 65.5,
"memory_used_gb": 12.8,
"disk_io_read_ops": 1500,
"network_in_mbps": 50.2
}
The Problem They Solve:
APM (Application Performance Monitoring) solves the problem of understanding what your application is doing and why it’s slow or erroring. It dives into the code, tracing requests as they flow through your services, identifying bottlenecks in your application logic, database queries, or external API calls.
Infrastructure monitoring solves the problem of understanding the health of the environment your application runs on. It tells you if your servers are overloaded, if disks are filling up, or if network latency is spiking, all of which can indirectly impact application performance.
How They Work Internally:
- APM Agents: These are small pieces of code (agents) you install directly into your application’s runtime (e.g., a Java JAR, a Python module, a .NET DLL). They hook into your application’s frameworks and libraries, observing method calls, database queries, and network requests. They then aggregate this data into transactions and send it to New Relic’s backend for analysis and visualization.
- Infrastructure Agents: These are separate daemons that run on your servers (VMs, bare metal, containers). They collect system-level metrics from the operating system and cloud provider APIs. This includes CPU, memory, disk, network usage, and process information. This data is also sent to New Relic, but it’s distinct from the application-specific traces.
Your Levers:
- APM:
- Transaction Tracing: The core of APM. You can configure sampling rates (how many transactions are fully traced) to balance detail with performance overhead.
- Error Reporting: APM automatically captures unhandled exceptions and allows you to instrument custom error reporting.
- Custom Instrumentation: You can add custom attributes or events to transactions to track business-specific metrics (e.g., user ID, order value).
- Alerting: Set thresholds on transaction errors, latency, throughput, and custom metrics.
- Infrastructure:
- Metric Collection Intervals: Control how frequently system metrics are gathered.
- Discovery: Configure which network interfaces, disks, or processes to monitor.
- Alerting: Set thresholds on CPU, memory, disk space, network I/O, etc.
- Integrations: Connect to cloud providers (AWS, Azure, GCP) or services (Kubernetes, Docker) to pull in more specific environmental data.
The most surprising thing about New Relic’s APM is its ability to correlate application-level transaction details directly with the specific host and container at the time of the transaction, even if that host or container is ephemeral. You don’t just see "slow transaction"; you see "slow transaction on webserver-03, which was experiencing 95% CPU utilization." This direct link, without manual configuration to stitch them together, is what makes the combined offering so powerful for debugging.
Understanding how these two products interact is key to troubleshooting performance issues that span both your code and your underlying infrastructure.
The next frontier you’ll likely explore is how to integrate these insights with your deployment pipelines to automatically roll back bad releases.