Install Netdata for Real-Time Monitoring

Netdata gives you per-second metrics for CPU, RAM, disks, network, containers, and hundreds of application plugins — all in a browser-based dashboard with zero configuration. You can run it fully self-hosted or connect to Netdata Cloud for multi-node views and persistent history. This guide walks through installation, cloud connection, alarm tuning, and plugin management, with notes on keeping overhead low.

Install Netdata with the Kickstart Script

Netdata's official kickstart.sh script detects your distro, installs the correct package or builds from source, creates the netdata system user, and enables the systemd service. It is the recommended path on every major distro.

Run the installer

wget -O /tmp/netdata-kickstart.sh https://get.netdata.cloud/kickstart.sh
sh /tmp/netdata-kickstart.sh

If you prefer to inspect the script first — always a good idea — open the URL in a browser or pipe it through less before executing. The script accepts flags; the most useful ones are shown below.

# Install and claim to Netdata Cloud in one step (get token from cloud.netdata.cloud)
sh /tmp/netdata-kickstart.sh --claim-token YOUR_TOKEN --claim-rooms YOUR_ROOM_ID --claim-url https://app.netdata.cloud

# Install without any Cloud connection (fully offline / self-hosted)
sh /tmp/netdata-kickstart.sh --disable-cloud

On Debian/Ubuntu the script installs from the Netdata APT repository. On Fedora, RHEL, Rocky, or Alma it uses the DNF/YUM repo. On Arch it builds from the AUR package netdata via the script or you can install with your AUR helper directly.

# Arch — alternative via AUR helper
yay -S netdata

Enable and start the service

The kickstart script enables the service automatically, but verify it is running:

sudo systemctl enable --now netdata
systemctl status netdata

Expected output shows active (running). Netdata listens on port 19999 by default.

Access the Local Dashboard

Open a browser on the same machine and navigate to:

http://localhost:19999

From another machine on the same network, replace localhost with the server's IP address. The dashboard is unauthenticated by default — see the firewall section below before exposing it beyond localhost.

Restrict access with a firewall

Allow port 19999 only from your management subnet, not the open internet.

# ufw (Ubuntu/Debian)
sudo ufw allow from 192.168.1.0/24 to any port 19999

# firewalld (Fedora/RHEL family)
sudo firewall-cmd --add-rich-rule='rule family=ipv4 source address=192.168.1.0/24 port port=19999 protocol=tcp accept' --permanent
sudo firewall-cmd --reload

# nftables (manual / Arch)
sudo nft add rule inet filter input ip saddr 192.168.1.0/24 tcp dport 19999 accept

Connect to Netdata Cloud

Netdata Cloud is free for the basic tier. It stores metric metadata (not raw data) and lets you view multiple nodes in one place, set up alert routing, and keep dashboards across reboots without running your own backend.

1. Create a free account at app.netdata.cloud.
2. Click Connect Nodes and copy the claim token and room ID shown.
3. Run the claim command on the target server:

sudo netdata-claim.sh \
  --token=YOUR_TOKEN \
  --rooms=YOUR_ROOM_ID \
  --url=https://app.netdata.cloud

sudo systemctl restart netdata

The node should appear in your Cloud space within 30 seconds. All metric data stays on the local agent; Cloud only receives the stream of aggregated data needed for the UI and alerts.

Configure Alarms

Netdata ships with hundreds of pre-written alarm definitions in /usr/lib/netdata/conf.d/health.d/. Do not edit those files — they are overwritten on upgrade. Override them in /etc/netdata/health.d/.

Edit or disable a built-in alarm

# Copy the alarm file you want to modify into the override directory
sudo cp /usr/lib/netdata/conf.d/health.d/cpu.conf /etc/netdata/health.d/cpu.conf
sudo nano /etc/netdata/health.d/cpu.conf

To raise the CPU warning threshold from 75 % to 90 %, find the relevant alarm block and change the warn line:

warn: $this > (($status >= WARNING) ? (85) : (90))
crit: $this > (($status >= CRITICAL) ? (95) : (98))

Set up email notifications

sudo nano /etc/netdata/health_alarm_notify.conf

Set these values (at minimum) and save:

SEND_EMAIL="YES"
DEFAULT_RECIPIENT_EMAIL="[email protected]"
EMAIL_SENDER="[email protected]"

sudo systemctl restart netdata

Netdata also supports Slack, PagerDuty, Telegram, and more — all in the same config file.

Manage Plugins and Collectors

Netdata auto-detects running services and enables the matching collector. You can list what is active:

sudo netdatacli active-collectors

Common plugins live in /usr/libexec/netdata/plugins.d/. External (Python, Go) collectors are configured under /etc/netdata/go.d/ and /etc/netdata/python.d/.

Enable the Nginx collector as an example

Netdata's Go collector handles Nginx if the stub status module is enabled. First enable stub status in Nginx:

# Inside your nginx server block
location /stub_status {
    stub_status;
    allow 127.0.0.1;
    deny all;
}

sudo nginx -t && sudo systemctl reload nginx

Then confirm Netdata picked it up automatically (it polls http://127.0.0.1/stub_status by default):

sudo netdatacli active-collectors | grep nginx

If it is not listed, create an explicit config:

sudo nano /etc/netdata/go.d/nginx.conf

jobs:
  - name: local
    url: http://127.0.0.1/stub_status

sudo systemctl restart netdata

Performance Impact and Tuning

Netdata is designed to be low-overhead, but the defaults favour completeness over minimal resource use. On a busy production server, tune these settings in /etc/netdata/netdata.conf:

sudo nano /etc/netdata/netdata.conf

[global]
    # Increase update interval from 1s to 2s to halve CPU usage
    update every = 2

    # Limit in-memory history (seconds of data kept in RAM)
    history = 3600

[db]
    # Use RAM-mapped storage to reduce disk writes
    mode = dbengine
    # DB engine disk space per tier (MB)
    dbengine multihost disk space MB = 512

Under dbengine mode (the default since Netdata v1.23), metrics are stored in compressed pages on disk, so RAM usage stays low even with long retention. On a typical four-core VM, Netdata at update every = 1 uses roughly 1–3 % CPU and 150–300 MB RAM depending on plugin count. Raising the interval to 2 seconds cuts that roughly in half.

Verify Everything Is Working

# Service health
systemctl status netdata

# Confirm the API is responding
curl -s http://localhost:19999/api/v1/info | python3 -m json.tool | head -20

# Check the agent log for errors
sudo journalctl -u netdata -n 50 --no-pager

The /api/v1/info endpoint returns a JSON object with version, operating system, active alarms, and collector counts. Any ERROR lines in the journal indicate misconfigured plugins or permission problems.

Troubleshooting

• Dashboard is blank or refuses to load: Confirm the service is running (systemctl status netdata) and that port 19999 is not blocked. On SELinux systems (Fedora/RHEL), run sudo ausearch -m avc -ts recent to check for denials.
• Node not appearing in Netdata Cloud: Check sudo journalctl -u netdata | grep claim. A common cause is a proxy or firewall blocking outbound HTTPS to app.netdata.cloud.
• High CPU from Netdata itself: Raise update every to 2 or 5, and disable unused collectors by setting enabled: no in the relevant config file under /etc/netdata/go.d/.
• Alarms not sending email: Test with sudo -u netdata /usr/libexec/netdata/plugins.d/alarm-notify.sh test and check that a working MTA (sendmail, msmtp, etc.) is installed.
• Collector not auto-detected: Run sudo -u netdata bash /usr/libexec/netdata/plugins.d/go.d.plugin -d -m nginx to see why auto-detection fails.