Analytics and Monitoring
Analytics and Monitoring
This domain covers AVR analytics, statistics, alerts, SNMP, syslog, and health monitors. Questions ask which tool reports a given metric and how to turn raw data into an actionable alert.
Core rules
- AVR collects application-level metrics such as HTTP response codes, latency, throughput, and user agents through an analytics profile attached to a virtual server.
- AVR has dashboards, custom reports, and alerts. Alerts can trigger on thresholds and send SNMP traps, emails, or syslog messages.
- LTM statistics are per-object counters for virtual servers, pools, and members, available through tmsh, the GUI, and SNMP.
- Health monitors test availability; they do not measure application performance. A monitor can be a simple ICMP check or an HTTP or HTTPS check with send and receive strings.
- HSL and IPFIX export flow data to external collectors; SNMP exposes OIDs for polling.
- Analytics data retention depends on AVR configuration and disk space; high-cardinality metrics can fill the database.
Worked example
An administrator attaches an analytics profile to an HTTPS virtual server and enables HTTP response-code and latency collection. A custom report shows a spike in 5xx responses and increased server-side latency. The administrator creates an alert that fires when 5xx exceeds five percent for five minutes, sending an SNMP trap to the monitoring system. The LTM pool statistics confirm one member is returning errors; the monitor still shows up because it checks only TCP 443.
Traps
- Expecting AVR data without an analytics profile on the virtual server.
- Treating a monitor as a performance metric; a TCP monitor can pass while the application returns 500 errors.
- Forgetting that AVR and LTM statistics have different scopes and retention.
- Creating alerts that fire on every sample instead of using a threshold and duration.
- Overlooking SNMP community and trap destination configuration.