Application Performance Monitoring (APM 360)
The APM 360 domain tests how you interpret transaction telemetry, service relationships, errors, and service levels rather than how you install an agent. Expect questions that ask you to choose the right signal for a symptom, calculate Apdex, or explain why a service map shows a dependency that a dashboard does not.
Core rules
- A New Relic APM agent instruments transactions. Web transactions have a request entry point; non-web transactions are background jobs. Response time is broken into app server, database, and external segments, so a slow external call appears as a dependency span, not as application code.
- Apdex is (satisfied + tolerating/2) / total. With threshold T, requests at or below T are satisfied, T to 4T are tolerating, and above 4T are frustrated. The default APM T is 0.5s; changing T changes the score, so compare only like-for-like Apdex.
- Distributed tracing links spans by trace ID. The service map and trace views depend on instrumentation and sampling; a missing span is usually a configuration or sampling issue, not proof the call did not occur.
- Service levels define an SLI with NRQL (good events / valid events), an SLO target, and an error budget. Burn-rate alerts are more useful than raw error-rate alerts for SLOs.
Worked example
A service handles 10,000 requests in an hour with T=0.5s: 7,000 finish in 0.5s or less, 2,000 finish between 0.5s and 2.0s, and 1,000 take longer than 2.0s. Apdex = (7,000 + 2,000/2) / 10,000 = 0.80. If the SLO is 99.9% over a month with 1,000,000 requests, the budget is 1,000 bad events; 1,500 observed bad events means the budget is exhausted.
Traps
Averages hide tail latency; use percentiles. Do not treat errors as zero-duration successes. Confirm the Apdex T before comparing teams. Remember that SLO good-event definitions must exclude or include errors deliberately.