Netdata auf dem Synology NAS installieren: Echtzeit-Monitoring für NAS und Container
Netdata liefert Echtzeit-Metriken für CPU, RAM, Disk und Docker-Container — ohne Datenbank, ohne Grafana, ohne Account. Compose-Projekt anlegen, starten, Dashboard unter Port 19999 aufrufen. Diese Anleitung zeigt den vollständigen Aufbau mit korrekten Mounts und Capabilities für DSM 7.2.

Wer wissen will, was auf dem Synology NAS gerade passiert — wie viel CPU ein Container frisst, ob der RAM zur Neige geht oder welche Festplatte sich aufwärmt — braucht dafür kein separates Grafana, keine Prometheus-Datenquelle und keinen eigenen Monitoring-Server. Netdata bringt alles mit: ein eingebautes Web-Dashboard, automatische Plugin-Erkennung für über 800 Integrationen und ML-basierte Anomalie-Erkennung, die sich lokal am Edge trainiert. Version v2.10.3 (April 2026, 79.100 GitHub-Stars) läuft als Docker-Container auf jedem Synology NAS mit Intel-, AMD- oder ARM64-CPU. Dieser Artikel zeigt, wie du das Projekt in DSM 7.2 Container Manager sauber aufsetzt — mit allen Mounts, Capabilities und Fallstricken, die der offizielle Weg erfordert.
Voraussetzungen
- Synology NAS mit Intel/AMD (amd64) oder ARM64-CPU — beide Architekturen werden unterstützt
- DSM 7.2 mit installiertem Container Manager (Package Center)
- Mindestens 256 MB freier RAM (empfohlen: 512 MB+); Netdata benötigt im Betrieb ca. 150 MiB
- Mindestens 500 MB freier Speicherplatz auf
/volume1für Container-Image und Named Volumes - Internetzugang für den einmaligen Image-Download von Docker Hub
- Grundkenntnisse im Container Manager — wie du ein Compose-Projekt anlegst, erklärt die Grundanleitung Container Manager: Docker-Compose-Projekt anlegen, starten und aktualisieren
- Optional: kostenloser Netdata Cloud Account für zentrales Multi-Node-Dashboard und Alert-Benachrichtigungen
Schritt 1: Netdata im Überblick — warum dieser Compose-Aufbau?
Bevor du die compose.yaml einfach kopierst, lohnt ein kurzer Blick auf das „Warum" hinter den ungewöhnlichen Parametern. Netdata arbeitet anders als ein normaler Web-Dienst: Es muss tief ins Betriebssystem schauen, Prozesse beobachten und den Netzwerk-Stack des Hosts verstehen — das geht nur mit erweiterten Rechten.
Was network_mode: host bedeutet: Netdata lauscht direkt auf Port 19999 des NAS, ohne Bridge-Netzwerk. Das ermöglicht vollständige Sichtbarkeit des Netzwerk-Stacks. Wenn du network_mode: host verwendest, darfst du keine ports:-Sektion in der Compose angeben — das schließt sich gegenseitig aus und führt zu einem Container-Manager-Fehler.
Was pid: host bedeutet: Der Container sieht alle Prozesse des Hosts direkt. Ohne diesen Parameter fehlen Prozess-Liste, Service-Discovery und zahlreiche Plugin-Checks — das Dashboard startet zwar, zeigt aber deutlich weniger Daten, ohne dass eine Fehlermeldung erscheint.
Warum zwei Capabilities: SYS_PTRACE braucht Netdata für Prozess-Monitoring und automatische Service-Discovery; SYS_ADMIN für Container-Netzwerk-Monitoring und tiefe System-Metriken. Ohne SYS_ADMIN bleiben Container-Netzwerk-Statistiken blind.
Warum apparmor:unconfined: Synology DSM setzt AppArmor-Profile ein, die Netdatas Plugin-Zugriffe blockieren. Ohne dieses security_opt schlagen Plugins mit Permission-Denied-Fehlern fehl.
| Parameter | Wert | Zweck |
|---|---|---|
| Image | netdata/netdata:stable | Stabile Version; :latest enthält Nightly-Builds |
| Port | 19999 (Host-Mode) | Web-Dashboard, HTTP, kein Login erforderlich |
| network_mode | host | Vollständige Netzwerk-Stack-Sichtbarkeit |
| pid | host | Prozess-Monitoring und Service-Discovery |
| cap_add | SYS_PTRACE, SYS_ADMIN | Pflicht für vollständige Monitoring-Funktionalität |
| Ressourcen | ~5 % CPU, ~150 MiB RAM | NAS-freundlich, laut offiziellem GitHub |
Verifizieren: Du verstehst, warum jeder dieser Parameter gesetzt ist, und kannst gezielt troubleshooten, wenn ein Wert fehlt oder falsch konfiguriert ist.
Schritt 2: compose.yaml erstellen
Öffne einen Texteditor und lege die folgende compose.yaml an. Alternativ kannst du den Inhalt direkt im Container Manager unter „Projekt erstellen" einfügen — der Dateiname muss exakt compose.yaml lauten, nicht docker-compose.yml.
Die Anleitung verwendet Named Volumes (empfohlen). Wenn du stattdessen Bind Mounts bevorzugst, tausche die Named Volumes gegen Pfade wie /volume1/docker/netdata/config:/etc/netdata aus — lege die Ordner dann vorher in der File Station an (Docker-Ordner und Berechtigungen auf dem Synology NAS). PUID/PGID-Variablen brauchst du hier nicht — das offizielle Netdata-Image unterstützt sie nicht; der Container läuft als root für volle Monitoring-Fähigkeiten.
services:
netdata:
image: netdata/netdata:stable
container_name: netdata
hostname: synology-nas
pid: host
network_mode: host
restart: unless-stopped
cap_add:
- SYS_PTRACE
- SYS_ADMIN
security_opt:
- apparmor:unconfined
volumes:
- netdataconfig:/etc/netdata
- netdatalib:/var/lib/netdata
- netdatacache:/var/cache/netdata
- /proc:/host/proc:ro
- /sys:/host/sys:ro
- /etc/passwd:/host/etc/passwd:ro
- /etc/group:/host/etc/group:ro
- /etc/localtime:/etc/localtime:ro
- /etc/os-release:/host/etc/os-release:ro
- /var/log:/host/var/log:ro
- /var/run/docker.sock:/var/run/docker.sock:ro
- /run/dbus:/run/dbus:ro
volumes:
netdataconfig:
netdatalib:
netdatacache:
Ein kurzer Hinweis zum Mount /run/dbus:/run/dbus:ro: Auf einigen Synology-Modellen ist D-Bus nicht aktiv, weshalb dieser Pfad nicht existiert. Falls der Container nach dem Start im Fehler-Status bleibt, entferne diesen Mount und starte erneut — das ist der häufigste Startfehler nach dem ersten Deployment.
Verifizieren: Prüfe die Datei auf Syntaxfehler: Kein ports:-Block vorhanden (da network_mode: host aktiv ist), beide Capabilities eingetragen, alle :ro-Suffixe korrekt gesetzt. Der Container Manager zeigt bei YAML-Syntaxfehlern eine Fehlermeldung beim Speichern an.
Schritt 3: Container Manager-Projekt anlegen und starten
Öffne den Container Manager in DSM, wechsle zu „Projekt" und klicke auf „Erstellen". Vergib den Projektnamen netdata, füge den Inhalt der compose.yaml ein und bestätige. Der Container Manager lädt das Image von Docker Hub (ca. 250–400 MB, je nach Architektur) und startet den Container automatisch. Die detaillierte Schritt-für-Schritt-Beschreibung findest du in der Grundanleitung Container Manager: Docker-Compose-Projekt anlegen, starten und aktualisieren.
Das Image wird mit dem Tag :stable gezogen — das entspricht aktuell v2.10.3 (Stand April 2026). Das Tag :latest enthält Nightly-Builds und ist ausdrücklich nicht für den Dauerbetrieb geeignet.
Verifizieren: Im Container Manager zeigt der Container nach ca. 30–60 Sekunden den Status „Wird ausgeführt" (grünes Symbol). Im Log-Tab erscheint keine kritische Fehlermeldung. Eine Zeile wie AGENT This agent has not been claimed ist normal — sie zeigt nur, dass keine Netdata Cloud-Anbindung konfiguriert ist.
Schritt 4: Dashboard aufrufen und Metriken prüfen
Öffne im Browser http://<NAS-IP>:19999 — kein Login, kein Passwort, kein weiterer Konfigurationsschritt. Das Dashboard lädt sofort und zeigt Echtzeit-Metriken für CPU, RAM, Disk-I/O, Netzwerk-Interfaces und laufende Prozesse.
Prüfe gezielt drei Bereiche:
- System-Metriken: Unter „System Overview" siehst du CPU-Auslastung, RAM-Verbrauch und Disk-I/O in Echtzeit (sekündliche Aktualisierung). Wenn diese Bereiche leer sind, fehlt der
/proc- oder/sys-Mount. - Docker-Container-Metriken: Im Abschnitt „Containers" erscheinen alle laufenden Container mit Name, CPU und RAM. Wenn dieser Bereich fehlt, ist
/var/run/docker.socknicht korrekt gemountet. - Alerts: Unter dem Glocken-Symbol oben rechts findest du aktive Alarme. Netdata bringt Hunderte vorkonfigurierter Schwellenwerte mit (z.B. RAM > 90 %, Disk > 80 %).
Verifizieren: Das Dashboard ist unter http://<NAS-IP>:19999 erreichbar, zeigt Echtzeit-Graphen für CPU und RAM, und der „Containers"-Bereich listet mindestens den Netdata-Container selbst. Alle drei Prüfpunkte bestanden = vollständig funktionsfähige Installation.
Schritt 5: Firewall-Regel für Port 19999 prüfen (optional)
Wenn du das Dashboard im lokalen Netzwerk erreichst, aber die DSM-Firewall aktiv ist, musst du Port 19999 TCP freigeben. Öffne Systemsteuerung → Sicherheit → Firewall und füge eine Regel für TCP-Port 19999 hinzu. Wie das genau funktioniert, erklärt die Grundanleitung DSM-Firewall auf dem Synology NAS: Ports für Docker-Container freigeben.
Da Netdata kein Login erfordert, solltest du Port 19999 nur im lokalen Netzwerk freigeben und nicht aus dem Internet erreichbar machen — oder alternativ einen Reverse Proxy mit Authentifizierung vorschalten (Nginx Proxy Manager auf der Synology einrichten).
Verifizieren: Das Dashboard ist von einem anderen Gerät im lokalen Netzwerk unter http://<NAS-IP>:19999 erreichbar. Falls nicht: Firewall-Regel prüfen oder per SSH mit docker ps sicherstellen, dass der Container tatsächlich läuft.
Schritt 6: Netdata Cloud optional anbinden (Gratis-Tier)
Netdata ist vollständig ohne Cloud-Account nutzbar. Wenn du aber mehrere Server zentral überwachen oder Alert-Benachrichtigungen per E-Mail und Slack erhalten möchtest, bietet Netdata Cloud einen kostenlosen Tier unter app.netdata.cloud. Ergänze dafür die environment-Sektion in der compose.yaml:
environment:
- NETDATA_CLAIM_TOKEN=<dein-token-aus-der-cloud-ui>
- NETDATA_CLAIM_ROOMS=<room-id>
- NETDATA_CLAIM_URL=https://app.netdata.cloud
Den Token und die Room-ID findest du in der Netdata Cloud UI unter „Connect Nodes". Trage die Werte ein, aktualisiere das Projekt im Container Manager und der Node erscheint innerhalb weniger Sekunden im Cloud-Dashboard.
Verifizieren: Nach dem Neustart des Containers mit den Claim-Variablen erscheint der Node unter dem Hostnamen synology-nas in der Netdata Cloud UI. Im Container-Log erscheint AGENT This agent has been claimed.
Schritt 7: Netdata aktualisieren
Durch die Named Volumes bleiben alle Konfigurationen und historischen Daten bei einem Update erhalten. Verbinde dich per SSH mit dem NAS (SSH auf dem Synology NAS aktivieren und verbinden) und führe im Projektordner aus:
docker compose pull
docker compose up -d
Alternativ kannst du im Container Manager das Projekt auswählen und „Aktualisieren" klicken — das entspricht denselben Befehlen.
Verifizieren: Nach dem Update ist das Dashboard weiterhin unter Port 19999 erreichbar und historische Metriken sind vorhanden. docker inspect netdata | grep Image zeigt die neue Image-ID.
Troubleshooting / Typische Fehler
- „Docker"-Tab im Dashboard fehlt komplett: Der Mount
/var/run/docker.sock:/var/run/docker.sock:roist nicht eingetragen. compose.yaml prüfen, Mount ergänzen, Container neu starten. - Container startet nicht — Fehler bei
/run/dbus: Auf dem NAS existiert der D-Bus-Socket nicht. Den Mount/run/dbus:/run/dbus:roaus der compose.yaml entfernen und erneut deployen. D-Bus ist optional und wird nicht für die Kern-Metriken benötigt. - Plugin-Fehler „Permission denied" in den Container-Logs:
security_opt: apparmor:unconfinedfehlt. Ohne diesen Eintrag blockieren DSM-AppArmor-Profile Netdatas Plugins. Eintrag ergänzen, Container neu starten. - Dashboard startet, zeigt aber kaum Metriken:
pid: hostodernetwork_mode: hostfehlt. Ohnepid: hostsind Prozess-Monitoring und Service-Discovery nicht verfügbar — es erscheint keine explizite Fehlermeldung, die Daten fehlen stillschweigend. - Container Manager meldet Fehler zu ports und network_mode: host: Du hast sowohl
network_mode: hostals auch eineports:-Sektion in der compose.yaml. Bei Host-Mode dieports:-Zeilen vollständig entfernen. - Dashboard unter Port 19999 nicht erreichbar: DSM-Firewall blockiert den Port. Unter Systemsteuerung → Sicherheit → Firewall eine Regel für TCP 19999 anlegen.
- Fehlalarm „mdstat_mismatch_cnt" oder SSD-Cache-Warnung: Bekanntes Kompatibilitätsproblem zwischen Netdata und Synologys SSD-Cache-Implementierung (GitHub Discussion #17902, Stand Juni 2024 ohne offizielle Lösung). Workaround: Den betreffenden Alarm in
/etc/netdata/health.d/deaktivieren — perdocker exec -it netdata bashin den Container wechseln. - Bind Mount fehlgeschlagen, Container startet nicht: Der Ordner
/volume1/docker/netdata/wurde nicht vorab angelegt oder hat unzureichende Rechte. Named Volumes verwenden oder Ordner in der File Station anlegen und Rechte für „Everyone" setzen.
Häufige Fragen
Brauche ich einen Netdata-Account?
Nein. Das lokale Dashboard unter http://NAS-IP:19999 ist vollständig ohne Account nutzbar — keine Registrierung, kein Login. Ein kostenloser Netdata Cloud Account ist nur sinnvoll, wenn du mehrere Geräte zentral überwachen oder Alert-Benachrichtigungen per E-Mail oder Slack empfangen möchtest.
Wie viele Ressourcen verbraucht Netdata auf dem NAS?
Laut offiziellem GitHub benötigt Netdata auf Produktionssystemen ca. 5 % CPU und 150 MiB RAM — für ein Synology NAS absolut vertretbar. Der Speicherverbrauch für historische Metriken beträgt dank Tiered Storage nur ca. 0,5 Bytes pro Sample, sodass selbst bei langen Aufbewahrungszeiten der Disk-Footprint überschaubar bleibt.
Was ist der Unterschied zu Grafana, Zabbix und Checkmk?
Netdata ist die Sofort-Lösung für Einsteiger: Zero-Config, eingebautes Dashboard, direkt nach dem Container-Start einsatzbereit. Grafana hingegen braucht eine separate Datenquelle (z.B. Prometheus) und manuelle Dashboard-Erstellung — mehr Flexibilität, deutlich mehr Aufwand. Zabbix setzt eine Server-Agent-Architektur voraus und ist für professionelles IT-Monitoring mit komplexer Infrastruktur ausgelegt. Checkmk auf dem Synology NAS ist die Profi-Alternative mit agentenbasierter Überwachung für IT-Abteilungen — leistungsstärker, aber deutlich komplexer in der Einrichtung als Netdata.
Wie sehe ich Container-Metriken?
Der Mount /var/run/docker.sock:/var/run/docker.sock:ro muss in der compose.yaml eingetragen sein. Dann erscheint im Dashboard automatisch ein „Containers"-Bereich mit CPU, RAM und Name pro Container. Ohne diesen Mount fehlt dieser Abschnitt vollständig — ohne Hinweis oder Fehlermeldung.
Kann ich Alarme konfigurieren?
Ja. Netdata bringt Hunderte vorkonfigurierter Alarme mit (z.B. RAM > 90 %, Disk > 80 %). Eigene Alarme werden als .conf-Dateien in /etc/netdata/health.d/ angelegt — direkt über den Named Volume netdataconfig oder per docker exec. Benachrichtigungen per E-Mail, Slack, PagerDuty und weitere Kanäle sind ohne Cloud-Anbindung konfigurierbar.
Warum fehlen PUID und PGID in der Compose?
Das offizielle Netdata-Image unterstützt PUID/PGID-Umgebungsvariablen nicht — sie haben schlicht keine Wirkung. Netdata läuft als root, da für vollständiges Monitoring (Kernel-Metriken, Prozess-Monitoring, Container-Netzwerk) Root-Rechte erforderlich sind. Einige Drittquellen setzen diese Variablen trotzdem — das ist irreführend, aber harmlos.
Was passiert bei :latest statt :stable?
Das Tag :latest enthält Nightly-Builds und kann Breaking Changes oder instabile Features enthalten. Die offizielle Netdata-Dokumentation empfiehlt ausdrücklich :stable für Produktivumgebungen. Alternativ kannst du eine gepinnte Version wie :v2.10.3 verwenden, um unkontrollierte Updates zu verhindern.
Fazit
Netdata ist das schnellste Monitoring-Setup für das Synology NAS: Compose-Datei einfügen, Container starten, Browser öffnen — fertig. Das eingebaute Dashboard liefert sekündliche Metriken für System und Container, ohne dass eine Datenbank, ein separates Grafana oder ein Cloud-Account erforderlich wäre. Der entscheidende Unterschied zu anderen Lösungen liegt nicht im Funktionsumfang, sondern in der Zeit bis zur ersten sinnvollen Übersicht: bei Netdata unter zwei Minuten. Wer später mehr will — benutzerdefinierte Dashboards, Multi-Node-Übersicht, Alert-Benachrichtigungen — kann Netdata Cloud kostenfrei ergänzen oder auf den Profi-Stack mit Checkmk, Grafana oder Zabbix wechseln. Für den Einstieg und den Alltag auf einem Heim- oder KMU-NAS ist Netdata die ehrlichste Empfehlung: minimaler Aufwand, maximale Sofort-Übersicht.
Weiterführende Anleitungen und Quellen
- Checkmk auf dem Synology NAS installieren: professionelles IT-Monitoring — der nächste Schritt für komplexere Infrastruktur
- Grafana-Dashboards bauen – von der Datenquelle zum Panel — wenn benutzerdefinierte Visualisierungen gefragt sind
- Zabbix-Server aufsetzen und ersten Host überwachen — agentenbasiertes Profi-Monitoring
- Container Manager: Docker-Compose-Projekt anlegen, starten und aktualisieren
- DSM-Firewall auf dem Synology NAS: Ports für Docker-Container freigeben
- Nginx Proxy Manager auf der Synology mit Container Manager einrichten — Reverse Proxy für Dashboard-Absicherung
Quellen: Offizielle Netdata Docker-Installationsdokumentation (learn.netdata.cloud), Netdata GitHub Repository (github.com/netdata/netdata), Netdata Docker Hub (hub.docker.com), Netdata Synology-Installationsseite (learn.netdata.cloud/synology).