System Monitoring & Resource Usage

• Answer 'why is the site slow?' in minutes instead of guessing blindly.
• Establish a baseline of normal usage so anomalies stand out when they matter.
• Right-size capacity before a growth spike turns into an outage.
• Correlate symptoms across layers: a slow app is often a disk or memory problem elsewhere.
• The exact same commands work on bare metal, VMs, containers and cloud instances.

A pilot never flies by feel — gauges show fuel, altitude and engine RPM. top is the engine monitor, free is the fuel gauge, df and du are the cargo weight, ip and ss are navigation and radio, dmesg is the maintenance log. You cannot run a reliable system blind; these instruments tell you when to act.

• top reads /proc every few seconds and shows which processes are burning CPU and memory, sorted live, while htop adds colour and easier navigation.
• vmstat samples kernel counters: running and blocked processes, memory, swap, I/O and the us/sy/id/wa CPU breakdown.
• free reads /proc/meminfo to report total, used and available memory — with -m in megabytes — while df and du walk the filesystem for disk space.
• Network tools inspect the stack: ip a lists addresses, ss lists listening and connected sockets, and ping, traceroute and nslookup test reachability and DNS.
• For logs, tail -f streams a file, journalctl -f streams the systemd journal, and dmesg shows kernel ring-buffer messages from drivers and hardware.

• First-response diagnosis on any incident starts with top, free -m, df -h and ss -tulpn — four commands that localise most outages.
• Baselines captured with vmstat and free feed capacity planning, so you scale before the pager goes off.
• Alerting rules (e.g. Nagios, Prometheus) are just automated versions of these checks: CPU saturation, memory pressure, disk filling.
• Kubernetes and cloud consoles expose the same kernel counters, so the mental model transfers from a single VM to a fleet.
• ss -tulpn is the standard answer to 'what is listening on port 80 and which process owns it?' in any audit or runbook.

• Collect a baseline when the system is healthy — you cannot spot an anomaly without knowing what normal looks like.
• Watch the available column of free -m, not free: buff/cache memory is reclaimable and not wasted.
• In vmstat, focus on the r column (run queue) and the wa (I/O wait) and swap si/so columns — they reveal the real bottleneck.
• Scope log streams: journalctl -u <service> -f beats tailing the whole journal, and dmesg is for kernel/hardware issues only.
• Tie every check to a layer (CPU, memory, disk, network) so your diagnosis is a deliberate elimination, not a lucky guess.

• Panicking because free -m shows low 'free' memory, ignoring that buff/cache is reclaimable — check available instead.
• Treating a high load average as a CPU problem when it can also come from I/O wait or an overloaded run queue.
• Using netstat (deprecated) instead of ss, or ipconfig instead of ip a.
• Running top once and concluding, rather than sampling over time with vmstat 1 5 or watching top over a minute.

• top -b -n 1 | head -15 is script-friendly and can be captured to a file for later analysis.
• ps aux --sort=-%cpu pins down the top CPU consumer; --sort=-%mem does the same for memory.
• When vmstat shows a large 'wa' (I/O wait), the bottleneck is disk — confirm with iostat -x to find the busy device.
• If ping works but nslookup fails, the problem is DNS, not the network.