Server Monitoring 101: Which Metrics to Watch

Use a handful of basic commands to read CPU, memory, disk, network, and processes—and tell whether your server is healthy.

Once you've spun up a VPS or cloud server and put real workloads on it, you'll eventually ask: is it busy right now? Is it about to fall over? Monitoring is how you answer those questions. Its value isn't only forensic ("what went wrong last night")—it's about catching trouble before your users do. A disk filling up, memory getting eaten alive, a CPU pinned at 100%: these all give warning signs. Here are the core metrics to watch, and how to check them quickly on Ubuntu/Debian.

The core metrics

CPU usage and load average

CPU usage tells you how busy the processor is, but load average is often more telling—it's the number of tasks running plus waiting to run. Rule of thumb: divide the load by your core count. Around 1.0 means fully utilized; consistently well above your core count means tasks are queuing and the system is struggling.

uptime          # shows 1/5/15-minute load values
nproc           # how many cores you have, for the math

The three numbers are the last 1, 5, and 15 minutes—read left to right to see whether load is climbing or easing.

Memory and swap

When RAM runs short, the system falls back to swap (spilling to disk). Heavy swapping makes performance drop off a cliff.

free -h

Focus on the available column—the memory you can actually use—not free. Linux deliberately uses idle RAM for caching, which is normal and healthy. If Swap used keeps creeping up, memory is genuinely tight.

Disk space and IO

A full disk crashes services outright, yet it's easy to overlook.

df -h           # free space per mount point—watch Use%
du -sh /var/*   # find out what's hogging the space

Beyond space, watch IO—whether disk reads and writes have become the bottleneck. The wa (iowait) column in vmstat tells you: a high value means the CPU is idling while it waits on disk.

vmstat 1 5      # sample once per second, five times

Network bandwidth

Keep an eye on inbound and outbound traffic. A sudden spike might be legitimate demand—or an attack or data exfiltration.

cat /proc/net/dev          # cumulative bytes per interface
ss -s                      # connection summary

Processes

When a metric spikes, you need to know who's responsible.

top             # live view of CPU/memory hogs; press P / M to sort
ps aux --sort=-%cpu | head   # top CPU consumers

A one-minute health check

When you log into a server that's acting up, run these in order:

  • uptime — load trend
  • free -h — is memory tight?
  • df -h — is the disk nearly full?
  • top — pin down the culprit process

Four commands are usually enough to tell whether there's a problem and roughly where it lives.

When to reach for real monitoring

Everything above is manual and point-in-time—it only reflects the moment you type the command. Reach for a proper monitoring stack (Prometheus + Grafana, Netdata, or whatever dashboard your provider offers) when you need to:

  • see historical trends and replay what happened at 3 a.m. last night;
  • get alerts that ping you automatically when the disk hits 90%;
  • manage several servers, where typing commands on each one by hand doesn't scale.

Summary

Monitoring boils down to five families of metrics: CPU and load, memory and swap, disk space and IO, network, and processes. For everyday checkups, uptime, free, df, top, and vmstat will get you there fast. Bring in a dedicated monitoring system once you need history, automatic alerts, or fleet-wide visibility. Build the habit of running these few commands, and your feel for how your server is doing will get a lot sharper.