Monitoring and Troubleshooting
This domain tests whether you can tell a symptom from a cause. It covers the metrics that actually predict problems, the difference between utilization and saturation, where logs live, and a repeatable troubleshooting method rather than guesswork.
Core rules
- Utilization, saturation and errors are separate signals; a resource at 40% utilization can still be saturated if queue depth is high.
- For storage, watch latency and IOPS together: rising latency with flat IOPS points to queueing, not to extra load.
- CPU ready/wait time indicates the guest is waiting for physical CPU; high ready time with moderate host utilization means contention, not overload.
- Establish a baseline before you need it; thresholds derived from normal behaviour beat vendor defaults.
- Centralize logs and confirm time sync first, or correlating events across nodes is impossible.
- Troubleshoot methodically: define the scope, check the most recent change, then work bottom-up through physical, network, storage and application layers.
Worked example
A virtual machine reports slow response. Host CPU utilization is 40%, but the guest shows 15% CPU ready time. Reasoning: utilization is low, so the host is not overloaded overall - the guest is competing with co-located workloads for physical cores, or the vCPU-to-core ratio is overcommitted. Check per-core contention and the power policy before adding resources; adding vCPUs would worsen it.
Traps
Averaging away short spikes; alerting only on utilization and never on latency or errors; ignoring a full /var/log partition; chasing the loudest alert instead of the earliest one; not checking what changed immediately before the incident.