Application Performance Monitoring (APM 360)
What the domain tests
APM 360 covers instrumentation and health analysis for distributed applications: agent deployment, transaction traces, distributed tracing, service maps, Errors Inbox, Apdex, service levels, and alert design. The exam favors decisions about which signal proves a problem and which alert will catch it without noise.
Core rules
- An APM agent instruments transactions; Apdex is (satisfied + tolerating ÷ 2) ÷ total, with thresholds set per app. It measures user satisfaction with response time, not error rate.
- Distributed tracing joins spans across services through trace headers. A trace shows where time is spent; service maps show dependency health and call counts.
- Errors Inbox groups error events and supports ownership and triage. Use error classes, stack traces, and entity links rather than a raw count.
- Service levels define an SLI (good requests ÷ valid requests) and an error budget; burn-rate alerts catch sustained tail latency or error regressions.
- Static, baseline, and outlier conditions answer different questions. Baseline conditions need history; static thresholds need a justified target; outlier conditions compare peers.
- Workloads group entities into a business service; health rolls up, but drill-down still matters.
Worked example
Checkout p95 latency rises while Apdex barely moves. A trace shows 80% of request time in one external payment call; database spans are normal. Because Apdex is dominated by the many fast requests, it hides the tail. Reason: alert on the external service's latency percentile and on the checkout SLO burn rate, not on average response time. Add a baseline condition only after enough history exists.
Traps
Alerting on throughput; treating Apdex as an error metric; assuming traces exist without compatible instrumentation; ignoring signal-loss alerts; using static thresholds on seasonal traffic; blaming the frontend for downstream errors.