Monitoring your VPS: RAM, CPU and uptime

Print
  • 0

A VPS does not fail without warning signs: memory filling up, load rising, disk approaching saturation. Monitoring these three indicators is enough to anticipate most incidents, and to decide on an upgrade from facts rather than from an impression.

The signals to watch first

  • Memory and swap: swap used permanently announces an approaching saturation.
  • CPU load: to be compared with the number of vCPUs, not with an abstract percentage.
  • Disk space: above 85% usage, services start to fail.
  • Uptime: is the site still answering, as seen from outside?

The basic commands

free -h
uptime
df -h
vmstat 1 5

free -h gives available memory and swap used. uptime shows the load average over 1, 5 and 15 minutes. df -h shows file system usage. vmstat 1 5 produces five measurements one second apart: it shows a trend, not an isolated instant.

Watching in real time

apt install htop
htop

htop lists processes sorted by consumption, with memory and load. For a specific service, systemctl status tells you whether it is running and for how long; its logs are read with journalctl -u service-name.

Understanding the load average

A load of 2 on a server with 2 vCPUs means tasks are waiting their turn: the machine is saturated. The same load on 4 vCPUs leaves headroom. So always compare the load with the output of nproc. Also look at the I/O wait share: a slow disk produces a high load while the processor is resting.

Monitoring from outside

Local commands tell you nothing if the server becomes unreachable. External supervision checks the HTTP response and uptime at a regular interval, and warns you before your visitors notice. The 360 Monitoring plans are ordered separately and configured from the monitoring platform's dashboard.

Automating a simple alert

For a minimal need, a scheduled task can check disk space and memory, then send a message when a threshold is crossed. Active monitoring without alerts is pointless: what matters is being warned, not looking at numbers from time to time.

When to act

  • Swap used continuously and memory saturated: consider a higher tier.
  • Disk above 85%: clean up logs and move local backups elsewhere.
  • Load sustainably above the number of vCPUs: identify the responsible process before changing plan.

See also


Was this answer helpful?

« Back