Monitoring, Logging and Troubleshooting
Concepts
Monitoring is layered: statistics (tmsh show ltm virtual, tmsh show sys tmm-traffic), logs (/var/log/ltm for TMM and iRule output, /var/log/audit for configuration changes, /var/log/messages for system events), and packet capture (tcpdump on a VLAN or interface). Remote syslog is configured under sys syslog, and log levels decide how much noise reaches each file. SNMP, statistics profiles and analytics provide trend data rather than point-in-time snapshots.
Troubleshooting follows the packet: client → VLAN → virtual server → profile → pool → node/member → server. Each hop has a distinct symptom - no ARP reply, VIP not listening, profile mismatch, pool with no available members, or a monitor failing for its own reasons.
Traps
- Running tcpdump on the management interface and concluding no traffic arrives; data traffic is on the TMM interfaces.
- Reading
/var/log/messageswhen an iRule'slog local0.output went to/var/log/ltm. - Forgetting that a virtual server with no default pool and no iRule returns nothing useful.
- Ignoring the audit log when a configuration that worked yesterday stopped working.
- Assuming a monitor failure means the server is down; the monitor's source, route or receive string may be wrong.
- Changing logging levels and assuming existing entries are reclassified.
Worked example
Users report a timeout to 203.0.113.10:443. From an external host, curl -kv https://203.0.113.10. On the BIG-IP, tmsh show ltm virtual vs_web (is it available?), tmsh show ltm pool web_pool members (any up?), then tcpdump -ni 1.1 host 203.0.113.10. If SYNs arrive but no SYN-ACK leaves toward the client, check the client SSL profile and member health.
Rule of thumb: capture on both sides of the BIG-IP and compare; the side that first goes silent points at the hop to investigate.