Netdata

What is Netdata?

Netdata collects thousands of metrics per second from a machine and everything running on it, and shows them in dashboards that work the moment you install it. No agent configuration, no query language to learn first.

Best for

Seeing what a single machine is doing right now

Why choose Netdata

Netdata's promise is that it works in the time it takes to install it. It collects thousands of metrics per second per node and presents them immediately, with no query language to learn, no dashboard to build and no agent configuration file to edit. It is the fastest way to answer 'what is this machine actually doing right now', including per-container, per-disk and per-process detail that other tools make you construct. Its anomaly detection highlights metrics that are behaving unusually relative to their own history, which often points at a problem before you have written a rule for it. For a small server or a first homelab, it turns an opaque box into something legible in minutes.

Replaces

• Datadog
• Nagios
• Zabbix

Key features

• Automatic discovery of services and containers
• Per-second resolution collection
• Built-in anomaly detection
• Alerting to many notification channels

What to watch out for

Netdata is heavy in the sense that matters least obviously: high-frequency collection and per-second retention consume real CPU and RAM on the host it is watching, which is a poor fit for the smallest VPS instances. Its own retention is short by default, so 'why was this slow three weeks ago' is not answerable without configuring external storage or the parent-child streaming architecture. Running it per-node means each machine has its own view, and centralising many nodes into one dashboard is a genuine configuration exercise. The cloud features and open-source installation have overlapping capabilities that change between versions, so what is free in a tutorial may not be in your build.

How to deploy

• One-line install or Docker
• Enable the parent/child setup for multiple hosts
• Lock the dashboard behind authentication

Getting started

Install it on one machine first and spend ten minutes in the charts before configuring anything — the defaults are the product. Then decide whether you need central retention, because if you do, that shapes whether you run it standalone or with a parent node. Add a disk and memory budget to your monitoring of the monitoring tool itself, since it is not free. Configure at least one health notification so an alert reaches you rather than waiting to be noticed. On constrained hardware, reduce the collection frequency or disable the modules you do not need instead of accepting the defaults and watching the load average rise.

Typical setup

Installed on each machine that matters, either standalone or with a parent node collecting from children when history is needed centrally. It runs as a service with a small reporting budget, on hosts sized with its own footprint in mind rather than squeezed onto the smallest instance available. A handful of health notifications are configured to reach a real channel, and the modules that are not relevant are disabled to keep the load down. Where longer retention or fleet-wide views are required, external storage or the parent-child setup is configured early, since retrofitting it means starting the history over.

Who should look elsewhere

Do not use Netdata as your only monitoring on a large fleet or for long-term trend analysis — it is a per-machine explorer, not a centralised long-retention system, and the gap shows once you need months of history across many hosts. Avoid it on very small instances where its own footprint matters. And if you need alerting with fine-grained routing and silence policies, a Prometheus and Alertmanager pair expresses that far better than per-node checks.

Project health

• GitHub stars: 80,777
• Last code push: 2026-10-02
• Open issues: 428
• Status: actively developed

Figures pulled from the GitHub API and refreshed periodically.