Netdata: Per-Second Infrastructure Monitoring Without the Setup Tax
Netdata turns live system and application metrics into high-resolution dashboards and alerts with little setup.
At a glance
- What is it?
- Netdata is an open-source monitoring agent that collects and visualizes per-second metrics with zero configuration. This review covers its architecture, deployment, and the trade-offs of its edge-based, ML-driven approach.
- Who is it for?
- Adopt Netdata if you need immediate, per-second visibility on a small fleet and want to avoid a heavy setup. Skip it if you require a centralized, queryable long-term metrics store with strict data governance, since Netdata keeps data at the edge and its Cloud tier is proprietary.
- Can I use it commercially?
- Yes, with conditions. GPL-3.0 is a copyleft licence: if you distribute software that includes it, you must release that software's source code under the same licence. Running it internally without distributing it does not trigger that obligation.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly Go, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The Problem: Monitoring That Waits for You
Most monitoring tools sample every 15 to 60 seconds, which means a spike can vanish before you see it. Netdata targets that gap. It collects per-second metrics and renders them immediately, so you can watch a CPU spike or a memory leak as it happens. The intended user is an engineer who wants answers fast, without writing queries or configuring a pipeline. The README claims zero configuration: install the agent, and it auto-discovers services on the node. That promise is the core value. If you have ever spent an afternoon setting up exporters and service discovery, Netdata's pitch is direct: click and see results.
How It Works: Edge Processing, Not Central Collection
Netdata's architecture is the opposite of a centralized metrics system. The agent runs on each node, handles collection, storage, ML, alerts, and exports locally. The README calls this 'edge-based' processing: it distributes code instead of centralizing data. There is no central collector that pulls metrics from agents. Instead, each agent stores its own data, and you can view it through a local dashboard or connect it to Netdata Cloud. The cloud does not store your metrics. It provides user management, RBAC, and centralized alerts, but the data stays on your machines. This design reduces network overhead and keeps sensitive metrics on-premises. For scaling, the parent-child model lets one agent act as a parent and aggregate from children, handling millions of samples per second.
Getting It Running: Install, Then Do Nothing
The README does not list a specific install command, but it emphasizes zero configuration and immediate deployment. The standard path is a one-line installer from the GitHub releases page, or a Docker image from hub.docker.com/r/netdata/netdata. The agent runs on Linux, FreeBSD, macOS, and Windows. Once installed, it auto-discovers everything on the node, so there are no config keys to set for basic monitoring. For advanced setups, you would configure parent-child relationships and alert rules, but the README does not document those keys. The UI is included in standard packages, with the latest version served via CDN. If you want to test it without installing, the README links to a demo at app.netdata.cloud.
Storage and ML: The Hidden Engineering
Netdata claims high-performance storage at about 0.5 bytes per sample, with tiered storage for archiving. That number is impressive if true, but the README does not explain the compression mechanism. The ML component trains multiple unsupervised models per metric at the edge, which means anomaly detection runs locally rather than in a central server. This is a significant difference from tools that require a separate ML pipeline. The trade-off is that the ML models consume CPU on every node. The README cites a University of Amsterdam study that found Netdata the most energy-efficient tool for Docker monitoring. That claim comes from an external paper, not from Netdata's own benchmarks, so treat it as third-party evidence.
Limitations: When Netdata Is the Wrong Tool
Netdata's edge-first design has a real cost. If you need to query historical metrics across many nodes, you have to either access each agent's dashboard or set up a parent-child hierarchy. There is no central database that you can query with SQL or PromQL. The README does not mention any query language, only 'slice and dice data without query language.' That is fine for ad-hoc viewing but painful for programmatic access. Also, the ML anomaly detection is unsupervised, which means it may generate false positives on unusual but benign workloads. The README warns that people get 'addicted' to Netdata, but that is marketing. A more concrete limitation is that the Cloud tier is proprietary, so if you rely on its centralized features, you are dependent on Netdata's SaaS.
Alternatives: Prometheus and the Centralized Approach
The README itself links to a comparison against Prometheus. Prometheus uses a pull model: it scrapes metrics from exporters at a set interval, typically 15 seconds. It stores data in a time-series database on a central server, and you query it with PromQL. Netdata uses a push model where each agent collects and stores locally. The core difference is where data lives. Prometheus centralizes, which makes it easier to run global queries and alerts, but it requires you to configure scrape targets and manage storage. Netdata decentralizes, which gives you instant local visibility and lower setup overhead, but you lose a single queryable store. If you already use Prometheus for long-term retention, Netdata could complement it, but not replace it.
Maintenance and License Costs
The agent is written in Go, and the repository shows frequent releases: v2.11.0 in August 2026, v2.10.4 in July, and v2.10.3 in April. That cadence means you need to track updates for bug fixes and security patches. The license is GPL-3.0, which is a strong copyleft license. If you distribute the agent as part of your product, you may need to release your modifications under the same license. That is a real consideration for commercial vendors. The Netdata UI has a separate license, NCUL1, which is not OSI-approved. The Cloud tier is proprietary. So while the agent is open source, the full ecosystem has proprietary components. You should verify which parts you are using and what obligations they carry.
Editorial conclusion
Adopt Netdata if you need immediate, per-second visibility on a small fleet and want to avoid a heavy setup. Skip it if you require a centralized, queryable long-term metrics store with strict data governance, since Netdata keeps data at the edge and its Cloud tier is proprietary. Before deploying, verify that the auto-discovery covers your specific services and that the GPL-3.0 license fits your distribution model. Check the parent-child configuration for multi-node setups, and confirm the ML models' false-positive rate against your workload.
Community notes