Application Performance Monitoring (APM 360)
What this domain tests
APM 360 questions ask you to read application health from New Relic APM data - response time, throughput, errors and Apdex - and to follow a slow request across services using transaction traces, distributed tracing and service maps. Expect to distinguish symptom from cause and to know which metric answers which question.
Core rules
- Every monitored app is an entity with its own settings: Apdex T, ignored error classes, transaction trace thresholds.
- Apdex = (satisfied + tolerating ÷ 2) ÷ total requests. Satisfied is under T, tolerating runs from T to 4T, frustrating is above 4T. T is per app (default 0.5s), so a score of 0.79 is only meaningful next to the T that produced it.
- The summary response time is an average; outliers hide there. Use NRQL such as
SELECT percentile(duration, 95) FROM Transactionto see the tail. - Throughput is requests per minute; error rate is errors ÷ throughput and depends on what the agent classifies as an error - 4xx is not automatically an error.
- Transaction traces capture the slowest requests with a segment breakdown (database, external, middleware). This is where 'the app is slow' becomes 'this SQL statement is slow'.
- Distributed tracing stitches spans across services. Infinite Tracing uses tail-based sampling at a trace observer, so span counts do not equal request counts.
Worked example
An app serves 1,200 rpm. Response times: 800 requests under 0.5s, 300 between 0.5s and 2.0s, 100 above 2.0s. Apdex = (800 + 300/2) ÷ 1,200 = 950 ÷ 1,200 = 0.79. With T = 0.5s the frustrating boundary is 4T = 2.0s, so all 100 slow requests are frustrating; shaving 0.3s off them would not change the score at all. They must drop under 2.0s.
Traps
- Comparing Apdex across apps that use different T values.
- Assuming a flat average means health when the p95 is climbing.
- Reporting span counts from Infinite Tracing as real traffic volume.
- Reading a service map as a dependency list rather than as observed call relationships.