Netdata: per-second monitoring you can install in one command

What Netdata solves, and for whom

The README frames the origin of the project around a specific failure: silent transaction failures that existing tooling could not explain, because those tools offered "so few metrics and with such low resolution". Netdata's answer is collection at one-second resolution, processed on the same host that produces the data, with dashboards generated from that host rather than from a remote query engine.

The audience is therefore narrow but common. It is an engineer who has one machine, or a handful, and wants to see what is happening right now without first writing scrape configs, choosing a time-series database, and building panels. The README calls the setup "zero configuration" because the agent auto-discovers what runs on the node. Whether that holds depends on your workload, but the intent is clear: the default path should produce graphs without a modelling step.

It is not aimed at teams whose primary need is a shared, centrally governed metrics warehouse. Netdata's own ecosystem table splits the product into an agent (GPL v3+), a Cloud service with a free community tier, and a UI under a separate licence. The agent does the work; the rest is optional around it.

The agent, the parent, and where the data lives

The architecture is edge-first. Each agent collects, stores, runs anomaly detection and evaluates alerts locally. The README describes the storage as roughly 0.5 bytes per sample using tiered storage, which is the mechanism that makes per-second retention affordable: recent data stays at full resolution while older data is downsampled into lower tiers instead of being deleted or moved to another system.

Scaling out is done with a parent-child arrangement, described in the README as "Parent-Child centralization with multi-million samples/s". A child agent streams to a parent, and the parent holds the aggregated view. That is a different shape from a pull-based scraper: the node itself decides what to collect and pushes it, and the collector does not need to know the node's metric names in advance.

The Dockerfile shows how the agent is assembled for containers. It installs from source inside a builder image and passes explicit plugin flags, including --enable-plugin-otel and --enable-plugin-netflow, while disabling eBPF with --disable-ebpf. That tells you the container image is a build of the same installer, not a separate lightweight rewrite, and that some collection paths are opt-in at build time.

Installing Netdata and reading the first dashboard

The repository ships netdata-installer.sh at the top level, and the README points to it as the entry point. The Dockerfile runs it with the flags that skip the interactive prompts and skip starting the service, so you can inspect what was installed before it runs.

./netdata-installer.sh --dont-wait --dont-start-it

The --dont-wait flag suppresses the confirmation prompt and --dont-start-it leaves the service stopped. Netdata answers on port 19999, the default the README and the Dockerfile build both assume, and it is the port people search for when the dashboard will not load. Point a browser at that port on the host to reach the agent's own interface.

For a container, the project publishes netdata/netdata on Docker Hub, and the Dockerfile builds from netdata/builder:v3 with a RELEASE_CHANNEL argument that accepts nightly or stable. In a container the agent needs host access to see host metrics, which is why the Docker path is usually run with host mounts rather than as an isolated process. The README does not document rollback or an uninstall procedure for the installer, so plan for that gap before you run it on a machine you cannot rebuild.

Where Netdata is the wrong tool

The clearest limitation is the one the README advertises as a feature: there is no query language. The feature table says you can "slice and dice data without query language", which means the dashboard is the interface. If your workflow depends on ad-hoc aggregation across many services, joining metrics with deployment metadata, or reproducing a chart in a notebook, you will be working against the grain.

Retention is the second constraint. The 0.5 bytes per sample figure comes with tiered storage, and tiering implies downsampling: older data is kept at lower resolution. Per-second detail does not persist indefinitely at per-second fidelity, so any investigation that starts a month after the incident will see a coarser picture than the live dashboard showed.

The third is scope. Netdata monitors the nodes it runs on and the things it can discover there. It is not a log search engine, not a tracing backend, and not a configuration management system. The README's comparison material is framed against Prometheus, which is a signal about where the project expects to be evaluated, and also a signal about what it is not trying to replace.

Finally, the licence split matters operationally. The agent is GPL v3+, while the UI is under the NCUL1 licence linked from app.netdata.cloud. If you are packaging Netdata into a product, those two components do not carry the same terms.

Netdata against Prometheus and Grafana

The honest comparison is about who holds the data and who decides what to collect. Prometheus scrapes targets over HTTP on an interval you configure, stores samples in its own TSDB, and exposes PromQL as the primary interface; Grafana then reads from it and draws panels. You choose the scrape interval, you write the recording rules, and the metric set is whatever your exporters expose.

Netdata inverts that. The agent collects per-second by default, auto-discovers what is present, and renders its own dashboards. There is no PromQL equivalent to learn, and there is also no PromQL equivalent to reach for when the built-in charts do not answer your question. If your team already has Prometheus and Grafana running and a set of dashboards people trust, adding Netdata means a second, parallel view of the same hosts with its own storage and its own alert rules.

That is not automatically bad. Per-second resolution is expensive in a scrape-based system, and Netdata's edge processing means the alert evaluation happens next to the data rather than after a round trip. But the decision is really about whether you want one queryable store with a language on top, or a fast local view with a fixed interface. Teams that need the former should stay where they are.

Maintenance, releases and licence cost

The repository is not archived, and the last push was on 2026-08-12, which is the same timestamp as the v2.11.0 release. The two preceding releases, v2.10.4 and v2.10.3, landed on 2026-07-15 and 2026-04-27. That cadence tells you patches arrive between feature releases, and it also tells you the upgrade path is real work: an agent that is installed from source on every node has to be reinstalled on every node.

That is the practical maintenance cost. The installer script is the install mechanism, and the Dockerfile shows the same script being driven non-interactively with a fixed set of flags. If you deploy via containers, upgrades are a tag change plus a restart. If you deploy via the installer on bare metal, you are re-running it per host and verifying that the flags you chose the first time are still the flags you want.

On licensing, the agent is GPL v3+ and the UI is NCUL1. GPL-3.0 on the agent is the ordinary open-source obligation: if you distribute a modified agent, the source goes with it. The UI licence is a separate document at app.netdata.cloud/LICENSE.txt, and it is not the GPL. Read both before you bundle anything. This is a description of what the repository states, not legal advice.

Editorial conclusion

Adopt Netdata if you want per-second visibility on individual nodes and are willing to accept its own storage engine and dashboard. Do not adopt it if you already run Prometheus and Grafana and need PromQL, or if you need a central long-term store for cross-service analytics. Before rolling it out, verify the agent version your package manager ships against the v2.11.0 release, confirm that port 19999 is reachable from wherever you will read dashboards, and read the GPL-3.0 and NCUL1 licence terms for the agent and the UI separately.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes