Application Performance Monitoring
What you must know
Application Performance Monitoring (APM) in AppDynamics is built on business transactions (BTs) - the unit of work the controller tracks end to end. Candidates must understand how BTs are discovered (automatic discovery via entry points such as servlets, POJO methods, and async entry points, plus custom match rules), how transaction snapshots capture call graphs, and how baselines (rolling, statistically derived) drive health rules. Know the difference between node-level and tier-level metrics, the role of exit calls and backends in cross-tier correlation, and how information points and data collectors extract business data from method arguments and return values.
Traps
The biggest trap is confusing average response time with percentile/health-rule behavior: a fast average can hide a long tail. Another is mixing up BT discovery (what counts as a transaction) with metric collection (what gets measured). Questions often ask whether a snapshot is retained after a health-rule violation - remember snapshot collection policies control that, not the health rule itself. Also watch for tier vs. node scoping in health rules and for transaction correlation requiring matching exit calls and backends across tiers.
Worked example / rule of thumb
A BT shows p99 latency at 4s while average is 300ms. Rule of thumb: investigate with percentiles and snapshots, not averages. Open a slow snapshot, follow the call graph to the deepest slow method or exit call, and check whether the delay is in application code, a downstream backend, or infrastructure. If the exit call is slow but the downstream tier's own BT is fast, suspect network or correlation gaps.
Key concepts checklist
- BT discovery & custom match rules
- Snapshots and call graphs
- Baselines and health rules
- Exit calls, backends, cross-tier correlation
- Data collectors and information points