Monitoring, Optimising, and Troubleshooting the Network Environment
Baselines and measurement
You cannot optimise what you have not measured. Establish a performance baseline (CPU, memory, disk queue, network utilisation, latency, error rates) during normal operation, then compare against it during incidents. Candidates should know the four primary resource counters and how to interpret sustained versus spiky values. Understand the difference between a bottleneck (a resource at capacity) and a constraint (a design limit), and why adding memory will not fix a saturated disk.
Monitoring design
Design monitoring around what matters to the business: availability checks, threshold alerts, log aggregation, and capacity trending. Know the difference between polling and event-driven monitoring, and between reactive alerting and proactive trending. For troubleshooting, use a consistent method: identify the symptom, isolate the layer, form a hypothesis, test it with the least invasive change, and document the result.
Traps
Questions often present a high counter value as proof of a fault when the baseline shows it is normal. Another trap is choosing a monitoring tool that measures the wrong layer - e.g., pinging a server to prove a database is healthy. Watch for "optimisation" answers that add hardware when the real fix is configuration or indexing.
Worked example
Users report slow file access at month-end. Network utilisation is elevated but within baseline; disk queue length on the file server triples. The bottleneck is disk, not the network - the fix is storage or workload scheduling, not a bigger link.
Also know
Alert fatigue and tuning thresholds, log retention requirements, and the value of post-incident review in preventing recurrence.