What to Measure on a VPS Before You Install Grafana

Grafana is a viewer. It does not invent truth. If you stand up dashboards before you know what a quiet hour looks like on the box, you will stare at pretty graphs and still not know whether 40 percent CPU is a problem. On a VPS you operate, the first observability skill is reading the host with the tools that already ship on Ubuntu: /proc, vmstat, iostat, ss, and df. Spend an afternoon capturing a baseline. Then Grafana has something to agree with.

Why a baseline beats a blank dashboard

A panel that shows 1.2 load average is meaningless until you know this machine idles at 0.2 and peaks at 3.0 during nightly backups. A memory graph that hugs 80 percent might be healthy page cache or a leak. The kernel already publishes the numbers. Grafana later just polls them through node_exporter. If you cannot explain a number from the CLI, you will not explain it in PromQL.

On a typical VPS in Lucknow DC01 you get Intel Xeon Platinum cores, High-Speed SSD storage, and L3/L4 DDoS filtering in front of the public NIC. Those facts change what you measure. CPU steal is the virtualization tax. Disk latency is the High-Speed SSD telling you whether the guest is waiting on I/O. Packet drops at the edge can be your application or the filter dropping junk. A baseline taken on a quiet Sunday is the control sample you will compare every incident against.

CPU: utilization is not the whole story

Idle percent from top is the number everyone quotes and the least useful by itself. Break CPU time into user, system, iowait, irq, softirq, steal, and idle. User high with a busy app is expected. System high often means too many syscalls or packet processing. Iowait high means the CPU is idle because storage is not. Steal high means the hypervisor is scheduling someone else onto the physical core you thought you had.

Capture a 60-second sample and read the columns, not a sparkline. If wait sits above 10 percent for minutes, your next question is disk, not add more vCPU. If steal sits above 5 percent for minutes, you are fighting contention or an undersized plan, not a missing index. Record the idle, wait, and steal averages for a quiet hour and a busy hour. Those two rows are the CPU baseline.

vmstat 5 12
mpstat -P ALL 5 12
sar -u 5 12

Load average is a queue length, not a percent. On a 2 vCPU plan, load 2.0 means the run queue is as long as the core count. Load 4.0 means work is waiting. Compare load to CPU idle: high load plus high idle often means uninterruptible sleep on disk, not compute starvation.

Memory: free is a lie, available is not

Linux uses spare RAM for page cache. A box with 256 MB free and 3 GB available is healthy. A box with 256 MB available and climbing si/so in vmstat is dying. Measure MemAvailable, Cached, SwapUsed, and the rate of paging, not the free column from a screenshot of htop.

awk '/MemTotal|MemAvailable|Cached|SwapTotal|SwapFree/' /proc/meminfo
vmstat 5 12
ps -eo rss,vsz,pid,cmd --sort=-rss | head -n 15

If SwapTotal is zero, you have no safety net; the OOM killer is the next step after MemAvailable collapses. If SwapTotal is large and SwapFree is shrinking during the day, you have a leak or a working set that does not fit. Note the RSS of your main process so you know which service owns the RAM. Do not write $PID with braces in scripts you paste into docs; keep it as a plain variable and pin the process name with pgrep -a instead of guessing.

Disk: space, inodes, and latency

df -h tells you space. df -i tells you inodes. A mail queue or session store can exhaust inodes with 40 percent space left. iostat -x 5 12 tells you await and util. On High-Speed SSD, await should be low single-digit milliseconds at modest queue depths. If await climbs while utilization sits at 100 percent, you are I/O bound even if df looks fine.

Also watch the path that fills first: /var/log, /var/lib/docker, PostgreSQL WAL, or a backup directory sharing the OS filesystem. One filesystem for everything is common on a small VPS. That makes logrotate and journald vacuum part of observability, not housekeeping trivia. Record used percent, inode percent, and await at idle and during backup. Those three numbers explain most "the server got slow at 02:00" tickets.

Network: sockets, drops, and the public path

ss -s summarizes sockets. ss -tulpn shows what is listening. ip -s link shows drops and errors. A VPS with L3/L4 DDoS filtering will drop a lot of garbage before it hits your guest. That is not your app dying. Correlate guest drops with application accept queues. If ListenOverflows increment, you are accepting too slowly, not being flooded.

ss -s
ss -tulpn
ip -s link
nstat -az | awk '/ListenOverflows|ListenDrops|TcpExtTCPTimeouts/'

Capture established connection counts at noon and at 2 a.m. Capture retransmission counters. Those two samples tell you whether the site is slow because of congestion, a full accept queue, or a disk that stopped flushing. Write down the listening ports and expected process names so a later surprise listener is obvious. Keep a text file next to the host with quiet-hour CPU user, system, iowait, steal, MemAvailable, RSS of the main process, root used percent, inode used percent, disk await at idle and during backup, and the established TCP count range. When node_exporter later publishes the same facts as time series, your first dashboard is a comparison against this page, not a fishing expedition.

Takeaway

Measure the host with vmstat, mpstat, /proc/meminfo, iostat, and ss until you can narrate a quiet hour. Grafana is how you keep watching after you stop staring at SSH. You can spin up an Ubuntu 24.04 instance on Netbay in Lucknow in under 60 seconds and take that baseline today — netbayhosts.in.