If you manage more than a handful of Linux servers, you have probably had the monitoring conversation: Prometheus plus Grafana plus Alertmanager plus Node Exporter plus cAdvisor plus exporters for each service, all orchestrated by yaml. It works, and at scale it is the right answer, but for fleets of 10 to 200 hosts it is too much overhead. Netdata takes a different path: a tiny agent per host collecting thousands of metrics at one-second resolution out of the box, with zero configuration, and an optional cloud dashboard that unifies your fleet without shipping all metrics off the host. In 2026 Netdata has become the pragmatic pick for sysadmins who want full observability with a ten-minute install.
## What Netdata Actually Collects
The agent auto-discovers running services and enables exporters for MySQL, PostgreSQL, nginx, Redis, Docker, systemd, and over 300 others. It collects per-second metrics, keeps recent data in a tiered database on the host (seconds for one day, minutes for a week, hours for a year), and shows everything in a built-in web dashboard. No central time series database required.
If you want centralized views, Netdata Cloud ties your agents together through an encrypted control channel. Metrics stay on the hosts; the cloud coordinates dashboards and alerts. That is very different from Prometheus, where every scrape sends data upstream.
## Installing the Agent
On Ubuntu 24.04 or AlmaLinux 9:
“`bash
wget -O /tmp/netdata-kickstart.sh https://get.netdata.cloud/kickstart.sh
sudo sh /tmp/netdata-kickstart.sh –stable-channel –disable-telemetry
“`
The installer detects your distribution, adds the official repo, installs the agent, and starts it. Within 30 seconds, visit `http://
Default port is 19999. Bind it to localhost only if you plan to front it with nginx or expose it through Netdata Cloud:
“`
sudo tee /etc/netdata/netdata.conf <
“`
Scrape it alongside your existing targets. You get Netdata’s rich metric set in your Prometheus instance without installing twenty exporters.
## Securing Exposed Dashboards
If you do expose the HTTP dashboard directly (not through Netdata Cloud), put it behind basic auth and HTTPS. With nginx:
“`
server {
listen 443 ssl http2;
server_name metrics.acme.com;
ssl_certificate /etc/letsencrypt/live/metrics.acme.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/metrics.acme.com/privkey.pem;
location / {
auth_basic “metrics”;
auth_basic_user_file /etc/nginx/metrics.htpasswd;
proxy_pass http://127.0.0.1:19999;
proxy_set_header Host $host;
}
}
“`
Netdata Cloud avoids all this — agents initiate outbound connections and no inbound ports are needed.
## Resource Footprint
Netdata is intentionally efficient. On a typical host, expect 50–150 MB RAM and 1–3% CPU for the agent. The tiered database compresses hard: a year of data for 2,000 metrics fits in under 1 GB on disk.
Compare that to Prometheus with multiple exporters, retention, and query load — which can easily consume 10x the resources on a central node.
## Streaming Between Agents
Netdata supports parent-child streaming: child hosts send metrics to a parent for long retention and unified queries. Enable on the parent:
“`
[parent]
enabled = yes
“`
On children in `stream.conf`:
“`
[stream]
enabled = yes
destination = parent.acme.com:19999
api key =
“`
The parent stores weeks of high-resolution data; children keep only recent. This is useful if you want central metrics but do not want the cost of a full Prometheus stack.
## When Netdata Is Not the Right Tool
At fleets over 500 hosts or with strict central retention and query requirements (alertmanager federation, long-range PromQL, Grafana dashboards shared across teams), stick with Prometheus plus Mimir or VictoriaMetrics. Netdata shines in the 10–200 host range and for teams that want observability now, not next quarter.
## FAQ
**Is Netdata Cloud required?** No, the agent works fully standalone. Cloud adds fleet views, centralized alerting, and role-based access.
**Is Netdata open source?** Yes, GPLv3. The cloud UI is a managed service but the agent and its plugins are open.
**Can I use Netdata in Kubernetes?** Yes, the Helm chart deploys a DaemonSet plus a parent pod. Netdata discovers services via the Kubernetes API.
**Does Netdata store metrics forever?** Only if you configure it to. Default retention is a day of per-second, weeks of per-minute, years of per-hour.
**How does it compare to Datadog?** Much cheaper but fewer integrations for non-infrastructure domains like APM and RUM. For infrastructure monitoring alone, it is competitive.
**Does Netdata support Windows?** Yes, the Windows agent collects performance counters, ETW events, and IIS metrics, with the same dashboard experience as Linux.
**Is Netdata Cloud truly free for any size?** Up to five nodes with full feature set, beyond that you need a paid plan. Self-hosted parent-child streaming has no node limit but lacks the unified Cloud UI.
**How long does setup take on a fresh host?** Under five minutes from `apt install` to a populated dashboard. Custom collectors and alerts add an hour or two depending on the services involved.
## Custom Collectors
Beyond auto-discovery, Netdata supports custom collectors written in Python, Go, or shell. A simple bash collector that exposes the count of files in a queue directory:
“`bash
#!/bin/bash
echo “BEGIN queue.count”
echo “SET pending = $(find /var/spool/myapp -type f | wc -l)”
echo “END”
“`
Drop it into `/usr/libexec/netdata/plugins.d/` and Netdata charts the metric automatically. The same pattern wraps any business KPI you want plotted alongside infrastructure metrics — orders per minute, queue depth, cache hit rate from your application’s own telemetry endpoint.
## Functions and Live Diagnostics
Netdata 2026 introduced “functions” — interactive queries you can run from the dashboard against the agent. Examples include `top`-style process tables, network connection lists, systemd service statuses, and even live tcpdump captures. This bridges the gap between dashboards and SSH sessions: when an alert fires, you click into the function view and see exactly which process is consuming the resource, without leaving the browser.
## Anomaly Detection in Practice
The bundled ML engine flags metrics that deviate from learned norms. In a real fleet this surfaces things like a slow memory leak that has not yet hit a hard threshold but is clearly anomalous compared to the host’s history. Tune the sensitivity per chart in the dashboard if it produces too many or too few flags. The training period is 24 hours by default; expect noise in the first day after install.
For the highest-value use case, combine anomaly scores with traditional alerts: alert only when both an anomaly score and a static threshold trip simultaneously. This dramatically cuts false positives versus thresholds alone.
## Integrating With Existing Stacks
Netdata is not all-or-nothing. You can run it alongside Prometheus, ship its metrics to Prometheus or VictoriaMetrics for long-term storage, send alerts through Alertmanager, and use Netdata Cloud purely for ad-hoc deep-dive investigation while keeping Grafana as your primary dashboard. The integrations are first-class because the Netdata team understands that most teams already have observability investment and switching costs are real.
## Securing Streaming Between Agents
Parent-child streaming sends metrics over a TCP connection that defaults to plaintext. For untrusted networks, terminate it with stunnel or run streaming over a Tailscale or WireGuard mesh. Better, configure native TLS in the streaming config:
“`
[stream]
ssl skip certificate verification = no
CApath = /etc/ssl/certs
“`
Combined with a private CA, this gives you authenticated, encrypted metric flow without external proxies.
## Operational Patterns at Scale
Past 200 hosts, the parent-child topology with one parent per region is the standard pattern. Each parent retains 30 days of data; children only keep 24 hours, dramatically lowering disk usage on the workers. Queries from Netdata Cloud route through the parent, so dashboards still show data even if children are temporarily offline. For really large fleets (over 1,000 hosts), shard parents by service tier or business unit so a single parent does not become the bottleneck.
## Comparing Resource Cost
A real comparison: a 50-host fleet running Prometheus + node-exporter + Alertmanager + Grafana plus the operational glue typically needs a dedicated 4 vCPU, 16 GB RAM monitoring host. The same fleet with Netdata needs nothing extra — each agent is self-contained. The Cloud UI is hosted by Netdata. Total cost difference: hundreds of dollars per year and several hours of weekly maintenance. The trade-off is less customization at the high end and a different querying mental model. For most teams the trade is worth it.
## Practical Alerting Recipes
A handful of alerts that cover 80% of common incidents on a Linux host:
“`yaml
alarm: oom_kill_recent
on: system.intr
lookup: max -10m
warn: $this > 0
to: oncall
alarm: ssh_brute_force
on: ipv4.connerror
lookup: sum -5m
warn: $this > 100
“`
Add disk fill prediction, swap pressure, TCP retransmits, package updates available, and certificate expiry. Netdata ships these as built-in alerts you can enable with a single config flag, which is part of why the time-to-value is so short compared to building the same coverage in Prometheus from scratch.
## Migration Strategy from Prometheus
If you decide to migrate, do it incrementally. Install Netdata alongside existing Prometheus exporters, point both at the same hosts, and run them in parallel for a month. Compare metric coverage and identify gaps. Build the highest-priority dashboards in Netdata Cloud first. After validation, decommission Prometheus on a per-host basis. The reverse migration (Netdata to Prometheus) is also possible if Netdata stops fitting — the metric semantics are similar enough that custom dashboards translate without major rework.
Was this article helpful?