Monitoring a Small VPS with Prometheus and Grafana

Monitoring often gets indefinitely postponed because it sounds like it belongs to a completely different scale of operation. It brings to mind a dozen servers, a dedicated ops team, and massive dashboards on a wall.

For one small VPS running a client's application, "setting up monitoring" feels like massive overkill compared to just SSHing in and running htop when something feels slow.

But the actual setup for a single server is extremely small. And the difference between "SSH in when something feels slow" and "look at a precise graph of the last week" is far bigger than the setup effort suggests.

The pieces for one server

node_exporter runs directly on the server itself. It exposes system metrics like CPU, memory, disk, and network usage in a format Prometheus natively understands:

wget https://github.com/prometheus/node_exporter/releases/download/v1.8.0/node_exporter-1.8.0.linux-amd64.tar.gz
tar xzf node_exporter-*.tar.gz
sudo mv node_exporter-*/node_exporter /usr/local/bin/

A small systemd unit keeps it running in the background:

# /etc/systemd/system/node_exporter.service
[Unit]
Description=Node Exporter
After=network.target

[Service]
ExecStart=/usr/local/bin/node_exporter
Restart=always

[Install]
WantedBy=multi-user.target

Prometheus itself can run on the exact same VPS for a single-server setup. Alternatively, you can put it on a separate small monitoring VPS if you want it to survive the monitored server having a truly bad day. Either way, the configuration is incredibly short:

# prometheus.yml
scrape_configs:
  - job_name: 'node'
    static_configs:
      - targets: ['localhost:9100']

Grafana simply connects to Prometheus as a data source and turns those raw metrics into dashboards. The official community dashboard for node_exporter gives you CPU, memory, disk, and network graphs instantly, without building a single panel from scratch.

What this actually buys you

The obvious answer is graphs. But the far more useful answer is history.

"The server feels slow today" transforms into "memory usage has climbed steadily over the past two weeks and is now hitting the limit." That is a completely different, infinitely more actionable statement. A slow memory leak, a gradually filling disk, or a creeping increase in load average as traffic grows are completely invisible in a single htop snapshot. They are painfully obvious in a week-long graph.

Alerting: The part worth doing even minimally

Dashboards require a human to actively look at them. Alerting means the server actively tells you when something is wrong. Even a minimal Alertmanager setup with two or three rules firmly covers the situations that actually matter for a small VPS:

# alert.rules.yml
groups:
  - name: basic
    rules:
      - alert: DiskSpaceLow
        expr: node_filesystem_avail_bytes{mountpoint="/"} / node_filesystem_size_bytes{mountpoint="/"} < 0.10
        for: 30m
        annotations:
          summary: "Disk space below 10% on {{ $labels.instance }}"

      - alert: HighMemoryUsage
        expr: (1 - (node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes)) > 0.90
        for: 15m
        annotations:
          summary: "Memory usage above 90% on {{ $labels.instance }}"

These two rules alone catch the two most common "the server has been slowly degrading and nobody noticed" scenarios. Alertmanager can then route that alert to email, Slack, or a webhook—whatever actually gets your attention.

Scaling it up costs nothing extra later

The absolute best reason this is worth setting up for one server is that the core setup does not change when a second server shows up. It just gets another scrape_configs entry and another node_exporter installation.

There is no massive "monitoring project" to kick off later. There is no painful migration from "no monitoring" to "monitoring." You just append one more target in a config file that was already there. Starting with one server means the second, third, and tenth servers seamlessly join a system that already works perfectly, rather than serving as the panic trigger to build one under pressure.