Skip to main content

NETDATA

Netdata is a real-time infrastructure monitoring tool that provides high-resolution metrics for servers and applications. It is commonly used on VPS environments to observe CPU, RAM, disk I/O, network traffic, system load, processes, containers, and many service-level metrics with minimal setup.

Netdata is useful when you need fast visibility into:

  • Sudden CPU spikes or sustained high load
  • Memory pressure, swapping, OOM events
  • Disk saturation and slow I/O (common cause of “slow WordPress”)
  • Network throughput, dropped packets, connection storms
  • Process-level resource usage (which service is actually consuming CPU/RAM)
  • Performance regression after changes (plugins, updates, caching configuration)
What Netdata provides
  • A web dashboard with per-second metrics (often 1s granularity)
  • Alerts and health checks
  • Optional cloud connectivity for multi-node views
Security posture

Exposing Netdata publicly without protection is risky. If you run Netdata on a public server, bind it to localhost and access it through SSH tunneling or restrict it with firewall/IP allow-listing.

Where Netdata Fits​

Netdata is not a firewall or an APM replacement. It is a system and service metrics layer used for:

  • Observability and diagnosis
  • Capacity planning
  • Early detection of resource exhaustion
  • Post-incident analysis

When Netdata Is a Good Fit​

Netdata is a strong choice when:

  • You want immediate visibility after provisioning a VPS
  • You need per-second resolution for troubleshooting bursts
  • You want a lightweight always-on dashboard for operational checks
  • You need quick answers to “what is causing the slowdown?”

When Netdata Is Not Suitable​

Netdata may not be the best solution when:

  • You need long-term historical metrics retention on the server without external storage
  • You require centralized enterprise observability with complex dashboards and log traces
  • You are extremely resource-constrained (very small VPS), where any monitoring overhead matters

Alternatives (depending on requirements):

RequirementBetter Fit
--
Deep APM and tracesOpenTelemetry + APM backend
Long-term metrics storagePrometheus + remote storage, VictoriaMetrics
Enterprise monitoring suiteGrafana stack, Datadog, etc.

Installation (Ubuntu / Debian)​

Netdata provides an official installer script. Use the safest pattern: download, verify (if possible), then run.

sudo apt update
sudo apt install curl -y

Install:

wget -O /tmp/netdata-kickstart.sh https://my-netdata.io/kickstart.sh
sudo bash /tmp/netdata-kickstart.sh

Check status:

sudo systemctl status netdata --no-pager

Default access (local):

  • http://127.0.0.1:19999

Access Methods (Secure Patterns)​

Most secure approach: keep Netdata local and access it through SSH.

Verify listening interface:

sudo ss -tulpn | grep 19999

If Netdata binds publicly and you want localhost-only, update Netdata config.

Edit:

sudo nano /etc/netdata/netdata.conf

Set:

[web]
  bind to = 127.0.0.1

Restart:

sudo systemctl restart netdata

Then use SSH tunnel from your local machine:

ssh -L 19999:127.0.0.1:19999 user@server_ip -p 2581

Open locally:

  • http://127.0.0.1:19999

Option B: Allow only your IP via firewall​

If you must access Netdata directly over the internet:

  • Keep it on port 19999
  • Restrict it by firewall allow-listing (example with UFW)
sudo ufw allow from YOUR_PUBLIC_IP to any port 19999 proto tcp comment "Netdata allow trusted IP"
sudo ufw deny 19999/tcp comment "Netdata deny others"
sudo ufw status numbered

First Checks After Installation​

Open the dashboard and validate:

  • CPU usage graph
  • RAM usage and swap activity
  • Disk I/O and latency
  • Network bandwidth and packet drops
  • Top processes

Server-side verification:

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

WordPress/VPS Monitoring Playbook​

1) Slow website, high TTFB​

In Netdata, check:

  • CPU saturation (100% on one or more cores)
  • Load average rising faster than CPU can handle
  • Disk I/O wait (iowait) and disk latency
  • Network congestion or packet drops
  • PHP worker exhaustion (PHP-FPM or lsphp processes)

Correlate with system commands:

top
sudo ss -s
sudo tail -n 200 /var/log/nginx/error.log 2>/dev/null || true
sudo tail -n 200 /usr/local/lsws/logs/error.log 2>/dev/null || true

2) Memory pressure and swapping​

In Netdata, look for:

  • RAM usage near maximum
  • Swap usage increasing steadily
  • Frequent swap in/out activity

If swap is growing, you may see degraded performance.

Confirm via CLI:

free -h
vmstat 1 10

3) Disk I/O bottleneck (common on small VPS)​

In Netdata, look for:

  • High disk utilization
  • High disk latency
  • High iowait

Confirm with CLI:

iostat -x 1 10 2>/dev/null || true

If iostat is missing:

sudo apt install sysstat -y

4) Network spikes or attacks​

In Netdata, look for:

  • Sudden inbound bandwidth spikes
  • Increased TCP connections
  • Packet drops
  • SYN floods (high connection attempts)

Confirm via CLI:

sudo ss -tan | head
sudo ss -tan state syn-recv | wc -l

Alerts and Health Monitoring​

Netdata includes health checks and alerting.

Check alert status:

sudo netdatacli health list

View current alarms:

sudo netdatacli alarms

Performance and Overhead​

Netdata is designed to be lightweight, but overhead depends on:

  • number of collectors enabled
  • retention settings
  • server size and workload

If running on a very small VPS, consider:

  • limiting retention
  • disabling collectors you do not need
  • using localhost-only access to reduce exposure

Uninstall (If Needed)​

If installed via kickstart, Netdata provides an uninstall option. Common uninstall path:

sudo /usr/libexec/netdata/netdata-uninstaller.sh

If the path differs, search:

sudo find / -name "netdata-uninstaller.sh" 2>/dev/null

Quick Reference​

TaskCommand
----
Install (kickstart)wget -O /tmp/netdata-kickstart.sh https://my-netdata.io/kickstart.sh && sudo bash /tmp/netdata-kickstart.sh
Service statussystemctl status netdata --no-pager
Local dashboardhttp://127.0.0.1:19999
Bind to localhostEdit /etc/netdata/netdata.conf → [web] bind to = 127.0.0.1
SSH tunnelssh -L 19999:127.0.0.1:19999 user@server_ip -p 2581
Check port listen`ss -tulpngrep 19999`
Health alarmsnetdatacli alarms