Real-Time VPS Monitoring with Netdata: dbengine Storage, Tiered Retention and Hardened Remote Access

Netdata collects each metric once per second and stores the result compressed into a database, so the footprint stays small enough for a 1 GB VPS while still capturing spikes that one-minute polling averages away. That sub-second granularity is the reason it belongs on a small box, but it is also why careless configuration fills disk or exposes a full system-inspection API to the internet. This guide installs Netdata with persistent dbengine storage, calculates an honest retention window for the disk you have, enables tiering and a few high-signal alarms, and locks the dashboard down.

Run everything below as root or with sudo. If you are still choosing the machine for this, sizes and providers vary more than the marketing implies — compare VPS plans before you commit, because Netdata’s overhead is trivial but retention depends on disk you must actually pay for. A box you will monitor should also be one you can benchmark first; the same provider comparison lists the disk and steal figures that decide whether monitoring will show a healthy host or a noisy neighbour.

Install From the Official Repository

Distribution packages are often a year behind. Use the kickstart script, which also installs the systemd unit and a default netdata.conf:

wget -O /tmp/netdata-kickstart.sh https://get.netdata.cloud/kickstart.sh
sh /tmp/netdata-kickstart.sh --stable-channel --disable-telemetry
systemctl status netdata --no-pager

The service listens on port 19999 by default. Confirm it is up locally before touching the firewall:

curl -s http://127.0.0.1:19999/api/v1/info | head -c 300

Bound Memory and Switch to Persistent Storage

By default Netdata keeps everything in RAM and evicts the oldest samples, so history disappears on every reboot. On a VPS you almost always want the database on disk, with an explicit cap so it can never fill the volume. Edit /etc/netdata/netdata.conf:

[global]
    memory mode = dbengine
    page cache size = 32
    dbengine multihost disk space = 512
[web]
    bind to = 127.0.0.1

page cache size is MB of RAM for hot data; dbengine multihost disk space = 512 caps the on-disk database at 512 MB. On a 1 GB VPS a 32 MB page cache plus roughly 60 MB of resident collectors keeps total resident usage near 100 MB. After editing, verify with:

sudo systemctl restart netdata
curl -s http://127.0.0.1:19999/api/v1/info | grep -o '"version":[^,]*'
du -sh /var/cache/netdata

Retention Arithmetic and Tiering

Retention is a function of how many metrics you collect. A stock install writes around 2,000 metrics; at one-second resolution that is roughly 250 MB per day after compression. With a 512 MB cap expect about two days of full-resolution history, which is enough to answer “what happened last night.” For week-long retention without a bigger disk, enable tiering so older samples are downsampled instead of deleted:

[db]
    dbengine tiering = yes
    dbengine tier 1 = 60
    dbengine tier 2 = 3600

Tier 1 samples once a minute, tier 2 once an hour. Because coarse tiers compress far better, the same disk now holds weeks of hourly trend next to a couple of days of per-second detail. Re-read du -sh /var/cache/netdata after a day to confirm the cap is respected rather than assumed.

Alarms That Earn Their Keep

Netdata ships sane health defaults in /usr/lib/netdata/conf.d/health.d/. Override rather than edit them by dropping files in /etc/netdata/health.d/. A useful custom check for a web VPS alerts on sustained CPU steal, which indicates a noisy hypervisor neighbour rather than your own load:

# /etc/netdata/health.d/steal.conf
alarm: cpusteal_5min
   on: system.cpu
 lookup: average -5m percentage of steal
  every: 1m
   warn: $this > 5
   crit: $this > 15
    info: sustained CPU steal percentage

Reload health checks without a restart via sudo netdatacli reload-health, then list active alarms through http://127.0.0.1:19999/api/v1/alarms. Pair the steal alarm with one on system.io await and one on mem.available so the three failure modes of a small VPS — oversold host, saturated disk, exhausted memory — each page you independently.

Remote Access Without Exposing the API

Never bind Netdata to 0.0.0.0. Reach it over an SSH tunnel or a WireGuard interface. The tunnel approach needs no firewall change at all:

ssh -L 19999:127.0.0.1:19999 user@your-vps
# then browse http://localhost:19999 locally

If other people need read-only access, keep bind to = 127.0.0.1 and front it with an authenticating reverse proxy rather than opening the port. This keeps the full inspection API — which reveals process arguments and open sockets — off every untrusted network.

Tune Collector Overhead

Netdata auto-detects Nginx, PHP-FPM, MySQL and Redis, but each discovered plugin spends a little CPU building a page. On a busy box that can be a few percent, so disable the collectors you never look at. List what is running and silence the rest:

# /etc/netdata/netdata.conf
[plugins]
    proc = yes
    cgroups = no
    diskspace = yes
    idlejitter = no

Turn off cgroups unless you run containers, and idlejitter if you never tune scheduler latency. Fewer charts also means fewer metrics on disk, which directly extends retention under the same cap. Measure the difference with pidstat -p $(pgrep -f netdata) 1 before and after — on a single-vCPU VPS shaving two percent of a core is worth the missing graph.

What to Watch First

Once running, three charts pay for the whole exercise: system.cpu steal (hypervisor contention), system.io await per disk (queueing on shared storage), and mem.available against swap activity. Those three separate “the app is slow” into “the host is oversold,” “the disk is saturated,” and “we are out of memory” within seconds — and they are the metrics worth keeping when you later move to a longer-retention stack.