Application Performance Monitoring
Application Performance Monitoring
The APM domain tests whether you can install and configure language agents, read the four golden signals, and use transaction and trace data to find the cause of a slowdown.
Core rules
- An APM agent (Java, .NET, Node.js, Python, Ruby, PHP, Go and others) instruments the app and reports to the account identified by the license key in newrelic.yml, newrelic.config, or newrelic.ini.
- Each monitored app becomes an entity with a service name and reporting agent; tags and entity metadata drive grouping, alert scoping, and access.
- Golden signals: throughput (requests per minute), response time, error rate, and Apdex.
- Apdex with threshold T: satisfied is at or below T, tolerating is above T and up to 4T, frustrated is above 4T. Apdex = (satisfied + tolerating / 2) / total.
- Distributed tracing links spans across services through trace.id and span.id propagation; transaction traces sample slow transactions; service maps summarize dependencies.
- Service levels define SLIs (latency, success) with SLO targets and error budgets.
Worked example
Threshold T = 0.5 s. Of 1,000 requests, 700 finish within 0.5 s, 200 finish between 0.5 s and 2.0 s, and 100 take longer than 2 s. Apdex = (700 + 200 / 2) / 1,000 = 800 / 1,000 = 0.80. The tolerating bucket counts half, which is why moving a request across the 4T boundary shifts the score more than ordinary latency noise does.
Traps
- Treating Apdex as an error percentage; it measures latency satisfaction, not correctness.
- Forgetting the x4 multiplier and calling every request above T frustrated.
- Assuming browser injection and log forwarding are on by default; both need explicit configuration.
- Renaming an app or changing the entity name splits history and breaks alert scoping.