When Your Server Lags but htop Isn’t Fast Enough
Have you ever experienced a sudden 5-10 second web freeze, users blowing up your inbox, but when you SSH in and run top or htop, CPU usage is sitting at a calm… 5%? Everything looks perfectly normal, as if nothing happened. The problem is that CLI tools only take a snapshot of the exact instant you look at your screen. Meanwhile, Prometheus or Zabbix clusters typically scrape metrics every 15 to 30 seconds. That collection interval is simply too slow. A brief disk I/O bottleneck or a sudden query loop can completely disappear before the monitoring agent even logs a single data point.
I used to manage over 20 VPS instances hosting everything from Node.js to Laravel. My absolute first step after provisioning the OS was always installing Netdata. It tracks detailed metrics down to per-second granularity. Best of all, the agent only sips around 1-2% CPU.
Under the Hood: Why Does Netdata Achieve 1-Second Granularity?
Netdata is a distributed performance monitoring daemon that runs natively on Linux. Instead of shipping raw data to a centralized server for processing, Netdata analyzes metrics right on the node:
- Per-second data collection: Netdata reads directly from the kernel via
/proc,/sys, and eBPF probes. Its core engine is written in pure C, parsing binaries blisteringly fast with virtually zero OS overhead. - In-memory storage and dbengine compression: Real-time metrics live in RAM so charts render seamlessly without stuttering. Older data is tiered, compressed, and flushed to disk, using only a few hundred megabytes of memory.
- Automatic service discovery (Zero-config): Once started, Netdata automatically detects processes listening on ports—like Nginx, MySQL, Docker, and Redis. It auto-generates the corresponding dashboards without requiring you to fumble around writing YAML exporter configs.
- Built-in web dashboard: No need to waste RAM spinning up a heavy Grafana instance; you get an ultra-responsive web dashboard out of the box, complete with per-second zoom-in via mouse scroll.
Hands-on: Installing and Securing Netdata on Ubuntu
Step 1: Update the System
First, update your package lists on the VPS:
sudo apt update && sudo apt upgrade -y
sudo apt install -y curl wget apt-transport-https
Step 2: Install via the Official Kickstart Script
Using Netdata’s official script is the fastest and most reliable approach. The script auto-detects your Ubuntu version (20.04, 22.04, or 24.04), configures the APT repository, and pulls the stable release:
wget -O /tmp/netdata-kickstart.sh https://get.netdata.cloud/kickstart.sh
sh /tmp/netdata-kickstart.sh --stable-channel --disable-telemetry
The --disable-telemetry flag disables sending anonymous analytics back to Netdata cloud. For private or production servers, keeping this flag enabled is recommended for privacy.
Wait 1-2 minutes for the installation to finish, then verify the service:
sudo systemctl status netdata
If you see a green active (running) status, the daemon is up and running properly.
Step 3: Block Port 19999 from the Internet
Here is a common mistake many administrators make: by default, Netdata binds port 19999 to all interfaces (0.0.0.0:19999) without requiring authentication. Anyone scanning your IP can inspect your process list, RAM usage, and network traffic.
Force Netdata to listen locally on localhost only:
sudo /etc/netdata/edit-config netdata.conf
Find the [web] block and modify the bind to directive:
[web]
bind to = 127.0.0.1
Save the file and restart the service:
sudo systemctl restart netdata
Verify the port binding using ss:
sudo ss -tulpn | grep 19999
# Expected output: tcp LISTEN 0 4096 127.0.0.1:19999
Once you see the IP bound to 127.0.0.1, your port is secure.
Step 4: Configure Nginx Reverse Proxy and HTTP Basic Auth
To safely access the dashboard from your personal browser, route the connection through Nginx secured with password authentication.
Create the credentials file:
sudo apt install -y apache2-utils
sudo htpasswd -c /etc/nginx/.netdata_auth devops_admin
Enter a strong password when prompted by the terminal.
Next, create a virtual host file at /etc/nginx/sites-available/netdata.conf:
upstream netdata_backend {
server 127.0.0.1:19999;
keepalive 64;
}
server {
listen 80;
server_name monitor.example.com;
auth_basic "Server Monitor - Authentication Required";
auth_basic_user_file /etc/nginx/.netdata_auth;
location / {
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-Server $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_pass http://netdata_backend;
proxy_http_version 1.1;
proxy_pass_request_headers on;
proxy_set_header Connection "keep-alive";
proxy_store off;
}
}
Enable the new site and reload Nginx configuration:
sudo ln -s /etc/nginx/sites-available/netdata.conf /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl reload nginx
Open your browser and navigate to your domain or server IP. When the authentication prompt appears, enter your username and password to access the dashboard.
Step 5: Memory Optimization for 1GB – 2GB VPS
On low-spec VPS instances (1GB – 2GB RAM) already running workloads like MySQL or Redis, you should prevent Netdata from consuming too much cache. Open the configuration file again:
sudo /etc/netdata/edit-config netdata.conf
Locate the [db] section and tune the storage limits:
[db]
mode = dbengine
dbengine tier 0 disk space MB = 256
dbengine tier 0 retention days = 7
This setting caps 1-second metric disk storage at 256MB and retains history for 7 days. That gives you plenty of data to troubleshoot last week’s incidents while keeping the agent’s RAM footprint pinned around 100-150MB.
Choosing the Right Tool for Small Servers
Spinning up a full Prometheus, Alertmanager, and Grafana stack is undeniably powerful, but it comes at a steep resource cost. The exporters and Java/Go daemons alone can chew up several hundred megabytes of RAM. For a large multi-node cluster, that overhead makes sense. But for standalone servers, Netdata is vastly more practical: installs in 2 minutes, detects metrics automatically, and catches every single micro-spike without dragging down your host system.

