Netdata: lightweight per-host agent with polished default dashboards

What is Netdata?

Netdata is a monitoring solution built on an unusual paradigm: each host installs its own agent that gathers metrics locally, stores them locally in its own time-series DB, and offers a complete local web UI. Optionally the agent forwards data to Netdata Cloud, where multiple hosts aggregate into one central view.

The project started in 2013 with Costa Tsaousis as a Linux server performance tool, became Netdata Inc. (US) in 2018, and as of May 2026 is in version 1.45+ – an established monitoring player. Licence: GPL-3 for the agent, proprietary for the cloud component. Open-core, but the agent alone is fully usable – nothing forces you into the cloud.

Footprint: the headline selling point. The agent uses under 1% CPU and typically 50 to 100 MB RAM. Netdata therefore runs in production on a Raspberry Pi, an old VPS, or a resource-tight container host. No Java, no heavy backend cluster, no separate database servers.

Auto discovery: the second selling point. At startup the agent scans the host and automatically detects every installed service – Docker, PostgreSQL, Redis, Nginx, Apache, MySQL, MongoDB, Elasticsearch, RabbitMQ, MQTT, and 200+ more. Each gets prebuilt dashboards with sensible default visualisations. Unlike Prometheus you do not need to install and configure exporters by hand.

Granularity: Netdata samples at 1-second resolution (default) – markedly finer than Prometheus default of 15 seconds. That makes it an excellent performance-debugging tool for acute problems. Long retention at 1-second granularity would be unaffordable in storage, so Netdata automatically rolls aging data into coarser tiers.

Why it matters

Netdata fills a specific gap in the monitoring market: the setup for SMEs that need a fast, beautiful overview without a configuration learning curve.

SME suitability: setup time is the lowest in the entire monitoring space. A single install command, then the UI on port 19999 is immediately fully usable – with 200+ dashboards already populated. No YAML config, no Promtail sidecars, no Grafana imports. For a fiduciary owner running a Hetzner server without a DevOps person: ideal.

CH DSG fit: the agent alone runs fully locally – no data leaves the host. Without cloud it is 100% CH/EU compliant. Whoever uses the cloud component should know: Netdata Inc. is a US company, cloud servers sit in the US, an EU region is announced for May 2026 but not yet available. For strict-confidential client setups: agent only, no cloud sync.

Very fine resolution: 1-second granularity is a real advantage for short-lived spikes. A RAG worker producing a 200ms CPU spike every 30 seconds is barely visible in Prometheus at 15s scrape – instantly visible in Netdata. For debugging sessions, Netdata is often the fastest path to root cause.

Hybrid model as SME bridge option: a fiduciary with 3 Hetzner servers and one MacBook for bookkeeping can install the agent on all three and have a central view in the cloud tier (free up to about 5 hosts) – without an own aggregation stack. Pro tier from USD 4 per host if more is needed.

What Netdata is not: not a full Prometheus replacement for industrial-strength setups. The TSDB is optimised for single-host speed, not cluster scaling with 1000+ nodes. Anyone running a microservice monster: Prometheus plus Thanos or VictoriaMetrics. For SMEs up to 50 hosts: Netdata suffices.

How it works

Netdata runs as a systemd service on every host (or in Docker as a container). Installation is a one-line curl-bash command that adds a repository and installs the package.

Installation via Docker:

```yaml services: netdata: image: netdata/netdata:v1.45.0 container_name: netdata hostname: server-prod-01 pid: host network_mode: host cap_add: [SYS_PTRACE, SYS_ADMIN] security_opt: [apparmor:unconfined] volumes: - netdataconfig:/etc/netdata - netdatalib:/var/lib/netdata - netdatacache:/var/cache/netdata - /:/host/root:ro,rslave - /etc/passwd:/host/etc/passwd:ro - /etc/group:/host/etc/group:ro - /proc:/host/proc:ro - /sys:/host/sys:ro - /var/run/docker.sock:/var/run/docker.sock:ro restart: unless-stopped volumes: netdataconfig: netdatalib: netdatacache: ```

After startup the UI on http://server:19999 is immediately usable. Auto-discovery has already detected every Docker container, every installed database, and every standard service.

Configuration: minimally needed. To add custom metrics, write a small plugin definition in /etc/netdata/python.d/ – typically under 20 lines. To set up alerts, edit /etc/netdata/health.d/ – the default config already has sensible defaults.

Cloud sync (optional): a claim token from app.netdata.cloud is added to the config; afterwards the host appears in the cloud dashboard. Multiple hosts under one cloud account are centrally visible – sorted by room, region, or own labels.

Alerting: standard alerts ship built in (CPU 95% over 10 minutes, disk 90%, RAM 95%, etc.) and go via notify plugin to Telegram, Slack, Discord, email, webhook. Custom alerts via simple YAML definitions in /etc/netdata/health.d/.

Tiers: high-resolution data (1-second) is kept for 24 hours, then automatically aggregated into 1-minute buckets (1 month), then 1-hour buckets (1 year). That makes long retention affordable.

Setup in 5 steps

1. 01Start docker-compose with netdata/netdata:v1.45 – host mode with pid/network_mode/host plus volume mounts for /proc, /sys, Docker socket.
2. 02Open UI on port 19999, let auto-discovery run – all containers and databases appear automatically in dashboards.
3. 03Review default alerts in /etc/netdata/health.d/, adjust thresholds to SME reality (e.g. CPU 95% -> 90%, disk 90% -> 80%).
4. 04Configure the notify plugin: Telegram bot, Slack webhook, or SMTP. Trigger a test alert, verify delivery.
5. 05For multiple hosts: open Cloud tier (free), enter claim token in /etc/netdata/cloud.d/, enable central view – or configure streaming to a master node for pure self-host.

When to use Netdata

Netdata is the right choice when (a) the setup has fewer than 25 hosts, (b) setup speed matters, (c) 1-second resolution is desired (performance debugging), (d) the team does not want to take on the PromQL learning curve.

Concrete SME cases: a single Hetzner server with 10 Docker containers for a fiduciary – Netdata installed, everything monitored in 10 minutes. A law firm with 3 distributed servers (prod, backup, dev) needing a central overview – Netdata agent plus Cloud Free suffices. A performance debugging session: "the server is slow, why?" – Netdata shows in 30 seconds which container/service is producing the spike.

Good complement to Prometheus: Netdata for ad-hoc debugging and polished dashboards, Prometheus for long-term trends and custom business metrics. At Fairlane, Netdata sits on the main Hetzner host as a quick-debug tool – complementary to the Prometheus stack, not a replacement.

When not to use

Netdata is the wrong choice when (a) the stack scales past 50+ hosts – TSDB scaling is not a design goal, (b) very long retention at high resolution is needed – tier aggregation reduces detail, (c) custom business metrics are central – Prometheus plus Grafana are more elegant for that, (d) strict CH/EU compliance without a US component is required and the cloud tier is planned.

Pitfalls: using the cloud tier without checking the data processing agreement – data goes to the US. Setting custom alerts without careful threshold definition – defaults are not always SME-appropriate (95% CPU alert can be nonsense for a build server). Picking Netdata Cloud as sole monitoring without Hetzner self-host even though 5 hosts would not justify it – the free tier is bounded.

Not recommended: installing Netdata and Prometheus on the same host and letting both collect all metrics – double CPU load. Instead: Netdata for host standard metrics, Prometheus for custom app metrics – division of labour rather than overlap.

Trade-offs

FAQ

Related topics

Sources

1. Netdata – Documentation · 2026-05
2. Netdata – GitHub repository · 2026-04
3. Netdata Cloud – Pricing tiers · 2026-05
4. Netdata vs Prometheus – Architecture comparison · 2026-03