Netdata
Per-second metrics for a whole machine with no configuration, and no login on port 19999
Netdata auto-discovers what a machine is running and charts it at one second resolution, with hundreds of preconfigured alarms and its own tiered on-disk database. The agent is GPLv3 and works standalone; Netdata Cloud is a separate closed service for multi-node views, RBAC and mobile alerts.
Our verdict on Netdata#
Nothing else shows you this much about a machine ten seconds after installation, and nothing else in this category costs as much to run. The published figures are about 150 MiB of RAM, roughly 5% of a core, and about 4 GiB of disk by default. On a 2 GB Raspberry Pi monitoring three containers, the monitoring is the workload. The licensing is split and worth understanding: the agent is GPLv3 or later, but the dashboard you actually look at is the Netdata UI under NCUL1, a non-open licence, and by default the latest UI is pulled from Netdata's CDN. Without a Cloud account the local agent still does everything that matters: full dashboard on port 19999, hundreds of built-in alarms, notifications by email, Slack, Telegram and others, and streaming to a parent for multi-node views. Cloud adds remote access, RBAC and mobile push, and its free tier caps you at five nodes and one custom dashboard.
Who Netdata is for#
Choose it if
- Diagnosing a machine that misbehaves in ways one-minute metrics miss, like brief IO stalls or fan ramps
- A single beefy server or NAS where 150 MiB and 4 GiB of disk are rounding errors
- Someone who wants alerting on hundreds of subsystems without writing a single rule
- Parent and child setups where small nodes stream to one retention host and keep no local database
Look elsewhere if
- You are monitoring Raspberry Pis or 1 GB VPS instances where the agent competes with the workload
- Your host boots from an SD card and you will not move or disable the 4 GiB database
- You need an air-gapped dashboard and do not want to deal with serving the UI locally
What running it actually looks like#
Nominally one container, practically a privileged one. The documented compose uses pid: host, network_mode: host, cap_add of SYS_PTRACE and SYS_ADMIN, security_opt: apparmor:unconfined, and read-only mounts of /, /proc, /sys, /etc/passwd, /etc/group, /var/log, /run/dbus and the Docker socket. That is close to root visibility on the host, which is the price of monitoring the host from inside a container. The native package installer avoids most of it and is what the project pushes. Three volumes matter: /etc/netdata for config, /var/lib/netdata for the database and node identity, /var/cache/netdata for scratch. First run needs no configuration; the dashboard is live at port 19999 immediately.
Resource profile#
- Memory
- 150 MB idle, around 250 MB in ordinary use. Docs state roughly 150 MiB by default and about 100 MiB with machine learning and alerts disabled, built from about 16 KiB per unique metric plus 5 KiB per ML model.
- CPU and acceleration
- Documented at about 5% of one core on production systems, under 1% with ML and alerts off. Per-second collection is the cost; halving the update frequency roughly halves it.
- Storage growth
- Defaults to 3 GiB of metrics (1 GiB per tier across three tiers) and about 4 GiB including metadata, giving 14 days at per-second, 3 months at per-minute and 2 years at per-hour resolution.
- Operational load
- 2 of 5, Light. Install and it works, with no database to run and no dashboards to build. It earns a 2 rather than a 1 because the defaults are heavy enough to need tuning on small hardware, and because config lives across `netdata.conf`, `health.d` and `go.d` files that each behave differently.
Figures describe a small single-household install and are the working assumptions behind our stack planner. Your numbers will differ with library size, user count and hardware. See methodology.
Data and backup surface#
Back up /etc/netdata (netdata.conf, health.d alarm overrides, go.d collector config, stream.conf and its API keys) and /var/lib/netdata, which holds the dbengine files, netdata-meta.db and the node identity. Losing the identity means the node reappears as a new machine in a parent or in Cloud, breaking its history. /var/cache/netdata is regenerable and can be excluded. The metrics themselves are rarely worth restoring: a live file copy of dbengine is fine in practice because losing a few minutes of samples costs you nothing, whereas losing your alarm tuning costs an afternoon.
Derived backup shape
SQLite backup. sqlite3 <db> ".backup out.db" while running, or stop the container and copy. A live cp of a WAL-mode SQLite file can restore corrupt.
Traps and surprises#
Port 19999 has no authentication
The agent dashboard is wide open to anyone who can reach the port, including process lists, running containers, network connections and the full metrics API. It is not a bug, it is the design. Bind it to localhost or a private interface in netdata.conf, put it behind an authenticating reverse proxy, and never map 19999 to a public IP because a search engine will find it.
About 4 GiB of disk by default
dbengine defaults to 1 GiB per tier across three tiers, plus metadata, and it writes continuously. On an SD card or a small VPS that is both a capacity and a wear problem. Either cut the per-tier sizes in netdata.conf, drop to two tiers, or set the database mode to ram or alloc and stream to a parent, which removes agent disk writes entirely.
The dashboard is not open source
The agent is GPLv3 or later, but the UI is licensed NCUL1 and, since the v2 dashboard, the latest version is served from Netdata's CDN with Cloud used as an identity provider for some functions. It is free to use with your own agents, but it is not code you can fork, and an air-gapped install needs the locally packaged UI instead of the CDN version.
The Cloud free tier is capped and personal
Since November 2023 new Community accounts are limited to five concurrently viewable nodes and one custom dashboard, and the tier is for personal use. New signups start on a 30 day Business trial, so the limits appear a month in, after you have wired everything up. Nothing about the agents changes when the trial ends, but multi-node views past five nodes stop.
Container mode needs SYS_ADMIN
Without cap_add: SYS_PTRACE and SYS_ADMIN, plus apparmor unconfined and host pid and network namespaces, container and per-application metrics are simply missing, with no obvious error explaining why. People add the mounts, see charts, and never notice half the collectors are dead. If your security posture rules those out, install the native package on the host instead of half-crippling the container.
Specifications#
- Category
- Monitoring and observability
- Licence
- GPL-3.0-or-later (agent); dashboard UI under NCUL1 (Copyleft)
- Written in
- C and Go
- First release
- 2013
- Maturity
- Mature
- Datastore
- dbengine, its own tiered on-disk store, plus SQLite for metadata
- Default ports
19999- Ships as
- docker, deb/rpm package, static install script, kubernetes helm chart
- arm64 builds
- Yes
- Identity
- Auth proxy only. The local agent dashboard has no login of its own; identity comes either from signing in to Netdata Cloud or from an authenticating proxy you put in front of 19999.
- Replaces
- Datadog, New Relic, Zabbix, Munin
- Project site
- www.netdata.cloud
- Source
- github.com/netdata/netdata
- Documentation
- learn.netdata.cloud/docs/netdata-agent
Alternatives to Netdata#
Everything else in monitoring and observability, closest in operational weight first.
| Tool | Ops load | Idle RAM | Licence |
|---|---|---|---|
| Grafana | 2, Light | 150 MB | AGPL-3.0-only |
| Uptime Kuma | 2, Light | 120 MB | MIT |
| Beszel | 1, Set and forget | 40 MB | MIT |
| Dozzle | 1, Set and forget | 15 MB | MIT |
| Gatus | 1, Set and forget | 25 MB | Apache-2.0 |
| Prometheus | 3, Moderate | 150 MB | Apache-2.0 |
Where Netdata comes up elsewhere#
Sources#
Facts on this page were checked against the project's own material. Where a number is our own estimate rather than a published figure, the text says so.
Published . Last reviewed . Found something out of date? Tell us and we will fix it and log the change.