Netdata: leichter Per-Host-Agent mit polierten Default-Dashboards

Was ist Netdata?

Netdata ist eine Monitoring-Lösung, die auf einem ungewöhnlichen Paradigma basiert: Jeder Host installiert seinen eigenen Agent, der lokal Metriken sammelt, lokal in einer eigenen Time-Series-Datenbank speichert und lokal eine vollständige Web-UI anbietet. Optional kann der Agent seine Daten an Netdata Cloud weiterleiten, wo mehrere Hosts in einer zentralen Ansicht aggregiert werden.

Das Projekt startete 2013 bei Costa Tsaousis als Performance-Tool für Linux-Server, wurde 2018 zur Firma Netdata Inc. (USA) und ist Mai 2026 in Version 1.45+ ein etablierter Spieler im Monitoring-Bereich. Lizenz: GPL-3 für den Agent, proprietär für die Cloud-Komponente. Damit Open-Core, aber der Agent allein ist vollwertig nutzbar – niemand zwingt Sie zur Cloud.

Footprint: das Verkaufsargument. Der Agent verbraucht unter 1% CPU und typischerweise 50 bis 100 MB RAM. Damit läuft Netdata auch auf einem Raspberry Pi, einem alten VPS oder einem ressourcen-knappen Container-Host produktiv. Kein Java, kein dicker Backend-Cluster, keine separaten Datenbank-Server.

Auto-Discovery: der zweite Verkaufspunkt. Beim Start scannt der Agent den Host und entdeckt automatisch alle installierten Services – Docker, PostgreSQL, Redis, Nginx, Apache, MySQL, MongoDB, Elasticsearch, RabbitMQ, MQTT, und 200+ weitere. Für jeden gibt es vorgefertigte Dashboards mit sinnvollen Default-Visualisierungen. Anders als Prometheus müssen Sie keine Exporter manuell installieren und konfigurieren.

Granularität: Netdata sammelt mit 1-Sekunden-Auflösung (Standard) – deutlich feiner als Prometheus mit Standard-15s. Das macht es zu einem hervorragenden Performance-Debugging-Tool für akute Probleme. Lange Retention auf 1-Sekunden-Auflösung wäre unbezahlbar im Storage, daher rollt Netdata älter werdende Daten automatisch in groebere Tiers.

Warum es zählt

Netdata schliesst eine spezifische Lücke im Monitoring-Markt: das Setup für KMU, die schnell, schön und ohne Konfigurations-Lernkurve einen Überblick brauchen.

KMU-Tauglichkeit: Setup-Zeit ist die niedrigste im gesamten Monitoring-Bereich. Ein einziger Installations-Befehl, danach ist die UI auf Port 19999 sofort vollständig nutzbar – mit 200+ Dashboards bereits gefüllt. Keine YAML-Konfiguration, keine Promtail-Sidecars, keine Grafana-Imports. Für einen Treuhand-Inhaber, der einen Hetzner-Server unterhalten will und keine DevOps-Person hat: ideal.

CH-DSG-Fit: der Agent allein läuft komplett lokal – keine Daten verlassen den Host. Wer ohne Cloud bleibt, ist 100% CH/EU-konform. Wer die Cloud-Komponente nutzt, sollte wissen: Netdata Inc. ist US-Firma, die Cloud-Server stehen in den USA, eine EU-Region ist Mai 2026 angekündigt aber noch nicht verfügbar. Daher für streng-vertrauliche Mandanten-Setups: Agent only, kein Cloud-Sync.

Sehr feine Auflösung: 1-Sekunden-Granularität ist ein echter Vorteil bei kurzlebigen Spikes. Ein RAG-Worker, der alle 30 Sekunden einen 200ms-CPU-Spike erzeugt, wird in Prometheus mit 15s-Scrape kaum sichtbar – in Netdata sofort. Für Debugging-Sessions ist Netdata oft der schnellste Weg zur Ursache.

Hybrid-Modell als KMU-Brückenoption: ein Treuhand-Büro mit 3 Hetzner-Servern und einem MacBook für Buchhaltung kann den Agent auf alle drei installieren und im Cloud-Tier (Free bis ca. 5 Hosts) eine zentrale Sicht haben – ohne eigenen Aggregations-Stack. Pro-Tier ab USD 4 pro Host, wenn mehr nötig.

Was Netdata nicht ist: kein vollwertiger Prometheus-Ersatz für industrial-strength Setups. Die TSDB ist auf Single-Host-Geschwindigkeit optimiert, nicht auf Cluster-Skalierung mit 1000+ Knoten. Wer ein Microservice-Architektur-Monstrum betreibt: Prometheus plus Thanos oder VictoriaMetrics. Für KMU bis 50 Hosts: Netdata reicht.

Wie es funktioniert

Netdata läuft als systemd-Service auf jedem Host (oder in Docker als Container). Die Installation ist ein einzeiliger curl-bash-Befehl, der ein Repository hinzufügt und das Paket installiert.

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: ```

Nach dem Start ist die UI auf http://server:19999 sofort nutzbar. Auto-Discovery hat bereits alle Docker-Container, alle installierten Datenbanken und alle Standard-Services entdeckt.

Konfiguration: minimal nötig. Wer Custom-Metriken einbinden will, schreibt eine kleine Plugin-Definition in /etc/netdata/python.d/ – typischerweise weniger als 20 Zeilen. Wer Alerts einrichten will, editiert /etc/netdata/health.d/ – die Standard-Konfig hat bereits sinnvolle Defaults.

Cloud-Sync (optional): ein claim-Token von app.netdata.cloud wird in die Konfig eingetragen, danach erscheint der Host im Cloud-Dashboard. Mehrere Hosts unter einem Cloud-Account werden zentral sichtbar – sortiert nach Raum, Region, oder eigenen Labels.

Alerting: Standard-Alerts sind eingebaut (CPU 95% über 10 Minuten, Disk 90%, RAM 95%, etc.) und gehen via Notify-Plugin an Telegram, Slack, Discord, E-Mail, Webhook. Custom-Alerts via einfachen YAML-Definitionen in /etc/netdata/health.d/.

Tiers: hochauflösende Daten (1-Sekunden) werden 24 Stunden behalten, danach automatisch auf 1-Minuten-Buckets aggregiert (1 Monat), dann auf 1-Stunden-Buckets (1 Jahr). Damit ist auch lange Retention bezahlbar.

Setup in 5 Schritten

1. 01Docker-Compose mit netdata/netdata:v1.45 starten – Host-Mode mit pid/network_mode/host plus Volume-Mounts für /proc, /sys, Docker-Socket.
2. 02UI auf Port 19999 öffnen, Auto-Discovery laufen lassen – alle Container und Datenbanken erscheinen automatisch in den Dashboards.
3. 03Standard-Alerts in /etc/netdata/health.d/ prüfen, Schwellwerte an KMU-Realität anpassen (z.B. CPU 95% -> 90%, Disk 90% -> 80%).
4. 04Notify-Plugin konfigurieren: Telegram-Bot, Slack-Webhook oder SMTP. Test-Alert auslösen, Empfang prüfen.
5. 05Bei mehreren Hosts: Cloud-Tier (Free) anlegen, claim-Token in /etc/netdata/cloud.d/ eintragen, zentrale Ansicht aktivieren – oder Streaming an einen Master-Knoten konfigurieren für reines self-host.

Wann Netdata einsetzen

Netdata ist die richtige Wahl, wenn (a) das Setup unter 25 Hosts hat, (b) der Bedarf an Setup-Geschwindigkeit hoch ist, (c) 1-Sekunden-Auflösung gewünscht ist (Performance-Debugging), (d) das Team keine PromQL-Lernkurve auf sich nehmen will.

Konkrete KMU-Fälle: Ein einzelner Hetzner-Server mit 10 Docker-Containern für ein Treuhand-Büro – Netdata installiert, in 10 Minuten ist alles überwacht. Eine Anwaltskanzlei mit 3 verteilten Servern (Prod, Backup, Dev) und Bedarf an zentralem Überblick – Netdata Agent plus Cloud Free reicht. Ein Performance-Debugging-Einsatz: "der Server ist langsam, warum?" – Netdata zeigt in 30 Sekunden, welcher Container/Service den Spike verursacht.

Gute Ergänzung zu Prometheus: Netdata für ad-hoc-Debugging und schöne Dashboards, Prometheus für Long-Term-Trends und benutzerdefinierte Business-Metriken. Bei Fairlane ist Netdata auf dem Haupt-Hetzner-Host installiert als Quick-Debugging-Tool – komplementär zum Prometheus-Stack, nicht statt.

Wann NICHT

Netdata ist die falsche Wahl, wenn (a) der Stack über 50+ Hosts skaliert – TSDB-Skalierung ist nicht das Design-Ziel, (b) sehr lange Retention auf hoher Auflösung gefragt ist – Tier-Aggregation reduziert Detail, (c) Custom-Business-Metriken im Vordergrund stehen – Prometheus plus Grafana sind dafür eleganter, (d) striktes CH/EU-Compliance ohne US-Komponente verlangt wird und Cloud-Tier eingesetzt werden soll.

Fallen: Cloud-Tier ohne Prüfung des Auftragsverarbeitungs-Vertrags einsetzen – Daten gehen in die USA. Custom-Alerts ohne sorgfältige Schwellwert-Definition setzen – Defaults sind nicht immer KMU-passend (95%-CPU-Alert kann für Build-Server unsinnig sein). Netdata-Cloud als alleinige Monitoring-Lösung wählen, obwohl Hetzner self-host und 5 Hosts nicht justifizieren würden – der Free-Tier ist begrenzt.

Nicht empfohlen: Netdata und Prometheus parallel auf demselben Host installieren und beide alle Metriken sammeln lassen – doppelte CPU-Last. Stattdessen: Netdata für Host-Standard-Metriken, Prometheus für Custom-App-Metriken – Aufgabenteilung statt Overlap.

Vor- und Nachteile

Häufige Fragen

Verwandte Themen

Quellen

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