AppDynamics CAAA cheat sheet

A Business Transaction is the unit of monitoring: a named, matching rule set over entry points (servlets, POJO methods, HTTP, message consumers).

Automatic discovery uses entry point types; custom match rules narrow by class/method, URI, or parameter value and can exclude noisy traffic.

Baseline modes: automatic (dynamic, adapts to seasonality), static (fixed thresholds), and custom (rolling or time-of-day); alerts compare the live metric to its baseline deviation.

Node health states are driven by the App Agent: healthy, alerting, and unmonitored; a stopped node stops reporting but retains historical metrics.

Call graphs are built from exit calls (JDBC, HTTP, JMS, sockets); downstream tiers appear as remote or backend segments, not as separate BTs.

Snapshot collection is triggered by slow-request, error, and diagnostic thresholds; the transaction snapshot is stored with its call graph for deep dive.

Metric hierarchy: Application > Tier > Node > BT; roll-up rules aggregate child metrics into parents, so a tier metric may be an average of node metrics.

Percentile metrics (e.g., 95th percentile response time) describe the tail; averages can hide slow outliers, so pair them with error rate and calls/min.

Agent lifecycle: install agent, restart the JVM/app server, verify registration, then configure BT detection; no restart is needed for most later config changes.

Two detection families: attack detection (SQL injection, command injection, path traversal, XSS, etc.) and data exfiltration (unusual outbound data volume or destinations).

An attack is a match of a transaction's request data against a detection rule; a threat is a correlated set of attacks scored by severity and confidence.

Exfiltration detection compares observed outbound bytes per transaction against learned baselines for that BT and flags outliers.

Policy scoping: security policies are applied per application and can be scoped to specific BTs, IP ranges, or environments to reduce false positives.

Blocking mode requires agent-side enforcement; in monitoring-only mode attacks are recorded and scored but not blocked.

Sensitive data detection can flag PII patterns (e.g., credit card, SSN) in request/response payloads; it is separate from injection attack rules.

Attack severity is derived from rule severity, confidence, and business risk of the affected BT; threat scores aggregate repeated attacks.

Security dashboards report attack counts, top attacked BTs, and source IPs; correlation links attacks to the same actor or campaign.

SAP monitoring uses dedicated agents (ABAP, Java, HANA, and HTTP-based) plus the SAP monitoring extension to collect SAP-specific metrics.

ABAP agent instruments SAP GUI, RFC, and web entry points; it reports dialog response time, work process utilization, and ABAP dumps.

HANA monitoring collects database metrics such as CPU, memory, disk, and expensive SQL statements via the HANA SQL interface.

Business transaction naming for SAP can use transaction codes (T-codes) and RFC destinations to map SAP workloads to BTs.

SAP agent health and connectivity are shown in the controller; a lost agent connection creates a gap in SAP metrics and an alert.

SAP-specific events include short dumps, update terminations, and lock waits; these are surfaced as events rather than only as BT errors.

The SAP solution integrates with infrastructure monitoring so that a slow SAP BT can be correlated to host or database metrics.

EUM has two halves: Browser RUM (JavaScript agent in the page) and Synthetic monitoring (scripted browser or API checks from locations).

Browser RUM measures page render time, DOM ready, resource load, AJAX calls, JavaScript errors, and end-user response time by geography/browser.

The JavaScript agent injects a beacon; session and page metrics are aggregated into browser applications mapped to BTs via correlation.

Synthetic checks run on a schedule from selected locations; they measure availability and response time independent of real users.

Synthetic browser scripts record the user journey (click, type, navigate); failures are reported per step with screenshots and waterfall data.

Apdex is computed from a target threshold T: satisfied (<=T), tolerating (T to 4T), and frustrated (>4T); score = (satisfied + tolerating/2) / total.

Web page waterfalls separate front-end time (DNS, connect, TLS, download, render) from back-end time so you can localize the bottleneck.

Correlation ties browser page performance to the back-end BT snapshot, linking user-perceived slowness to server-side calls.

The machine agent collects host metrics (CPU, memory, disk, network) and can run extensions for servers, databases, and middleware.

Server monitoring is organized as tiers and nodes with hardware and JVM metrics; infrastructure dashboards aggregate by tag or group.

Docker and Kubernetes monitoring use the cluster agent to collect pod, container, and node metrics and map them to applications.

Database monitoring collects query performance, wait states, and top SQL via collectors; it complements the JDBC exit calls seen in APM.

Business transactions can be enriched with business data (e.g., order value) via data collectors and analytics data sources.

Analytics uses ADQL to query transaction, log, and metric events; schemas define which fields are indexed and queryable.

Business journeys and funnels are built from analytics events; they measure conversion and drop-off across defined stages.

Health rules can fire on infrastructure and analytics metrics, not just APM metrics; actions include email, SMS, and webhook/HTTP.

Metric browser shows live and historical metrics; time ranges and roll-up granularity determine whether you see raw or aggregated values.