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.
Geprüft am 04.10.2026 · für netdata 2.12.0
WerbelinksMit * markierte Links sind Werbelinks: Bei einem Kauf erhalten wir eine Provision, der Preis bleibt gleich. Als Amazon-Partner verdiene ich an qualifizierten Verkäufen. Mehr dazu

Wer wissen will, wie viel CPU ein Container belegt, ob der RAM knapp wird oder welche Festplatte warm läuft, braucht auf dem Synology NAS kein separates Grafana und keinen eigenen Monitoring-Server. Netdata bringt ein Web-Dashboard, automatische Erkennung von über 800 Integrationen und eine lokal trainierte Anomalie-Erkennung mit. Die aktuelle stabile Version v2.12.0 (Stand Oktober 2026) läuft als Docker-Container auf Synology-Modellen mit Intel-, AMD- oder ARM64-CPU. Diese Anleitung zeigt, wie Sie Netdata im Container Manager unter DSM 7.2 einrichten, mit allen nötigen Mounts, Capabilities und typischen Fehlerquellen.
Voraussetzungen
- Synology NAS mit Intel/AMD- (amd64) oder ARM64-CPU
- 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 Sie ein Compose-Projekt anlegen, erklärt die Grundanleitung Container Manager: Docker-Compose-Projekt anlegen, starten und aktualisieren
- Optional: kostenloses Netdata-Cloud-Konto für ein zentrales Dashboard mehrerer Systeme und Benachrichtigungen
Schritt 1: Netdata im Überblick: warum dieser Compose-Aufbau?
Netdata arbeitet anders als ein normaler Webdienst: Es liest Kernel-, Prozess- und Netzwerkdaten des Hosts und braucht dafür erweiterte Rechte. Die folgenden Parameter erklären, warum die compose.yaml ungewöhnlich aussieht.
Was network_mode: host bedeutet: Netdata lauscht direkt auf Port 19999 des NAS, ohne Bridge-Netzwerk. So sieht es alle Netzwerkschnittstellen. Mit network_mode: host darf die Compose-Datei keine ports:-Sektion enthalten, sonst meldet der Container Manager einen Fehler.
Was pid: host bedeutet: Der Container sieht alle Prozesse des Hosts direkt. Ohne diesen Parameter fehlen Prozessliste, Service-Discovery und viele Plugin-Checks; das Dashboard startet trotzdem, nur ohne Fehlermeldung und mit deutlich weniger Daten.
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 kann Nightly-Builds enthalten |
| 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: Ihre compose.yaml aus Schritt 2 enthält jeden Parameter aus der Tabelle (pid, network_mode, beide cap_add-Einträge, security_opt).
Schritt 2: compose.yaml erstellen
Legen Sie die folgende compose.yaml an oder fügen Sie den Inhalt im Container Manager unter „Projekt erstellen“ direkt ein.
Die Anleitung verwendet Named Volumes (empfohlen). Für Bind Mounts ersetzen Sie die Named Volumes durch Pfade wie /volume1/docker/netdata/config:/etc/netdata und legen die Ordner vorher in der File Station an (Docker-Ordner und Berechtigungen auf dem Synology NAS). PUID/PGID-Variablen entfallen: Das offizielle Image unterstützt sie nicht, der Container läuft für vollständiges Monitoring als root.
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. Bleibt der Container nach dem Start im Fehlerstatus, entfernen Sie diesen Mount und starten erneut.
Verifizieren: Prüfen Sie die Datei: 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
Öffnen Sie den Container Manager, wechseln Sie zu „Projekt“ und klicken Sie auf „Erstellen“. Vergeben Sie den Projektnamen netdata, fügen Sie den Inhalt der compose.yaml ein und bestätigen Sie. Der Container Manager lädt das Image von Docker Hub und startet den Container. Details stehen in der Grundanleitung Container Manager: Docker-Compose-Projekt anlegen, starten und aktualisieren.
Das Tag :stable entspricht aktuell v2.12.0 (Stand Oktober 2026). :latest zeigt auf den jeweils neuesten Build, auch Nightly-Builds, und eignet sich nicht für den Dauerbetrieb.
Verifizieren: Im Container Manager zeigt der Container nach ca. 30 bis 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
Öffnen Sie im Browser http://<NAS-IP>:19999. Ein Login ist nicht nötig. Das Dashboard zeigt Echtzeit-Metriken für CPU, RAM, Disk-I/O, Netzwerk-Interfaces und laufende Prozesse.
Prüfen Sie drei Bereiche:
- System-Metriken: Unter „System Overview“ sehen Sie 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 finden Sie 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.
Schritt 5: Firewall-Regel für Port 19999 prüfen (optional)
Ist die DSM-Firewall aktiv, geben Sie Port 19999/TCP frei: Systemsteuerung → Sicherheit → Firewall, Regel für TCP-Port 19999 nur für das lokale Subnetz. Details erklärt die Grundanleitung DSM-Firewall auf dem Synology NAS: Ports für Docker-Container freigeben.
Da Netdata ohne Login arbeitet, machen Sie Port 19999 nicht aus dem Internet erreichbar. Für Fernzugriff schalten Sie einen Reverse Proxy mit Authentifizierung vor (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 funktioniert vollständig ohne Cloud-Konto. Für die zentrale Überwachung mehrerer Server bietet Netdata Cloud unter app.netdata.cloud einen kostenlosen Tarif. Ergänzen Sie dafür die environment-Sektion in der compose.yaml:
environment:
- NETDATA_CLAIM_TOKEN=<token-aus-der-cloud-ui>
- NETDATA_CLAIM_ROOMS=<room-id>
- NETDATA_CLAIM_URL=https://app.netdata.cloud
Token und Room-ID zeigt die Netdata-Cloud-Oberfläche beim Hinzufügen eines Nodes („Add Nodes“). Tragen Sie die Werte ein und aktualisieren Sie das Projekt im Container Manager.
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. Verbinden Sie sich per SSH mit dem NAS (SSH auf dem Synology NAS aktivieren und verbinden) und führen Sie im Projektordner aus:
docker compose pull
docker compose up -d
Alternativ wählen Sie im Container Manager das Projekt aus und klicken auf „Aktualisieren“.
Hinweis zum Update von v2.11 auf v2.12: Für den hier gezeigten Aufbau sind laut Release Notes keine Änderungen an der compose.yaml nötig. Anpassen müssen Sie nur eigene Konfigurationen in zwei Fällen: Eine selbst angepasste otel.yaml aus v2.10 oder älter muss auf das neue Schema umgestellt werden, sonst startet das OpenTelemetry-Plugin nicht. Und go.d-Jobs für Ceph mit eigenen Headern wie Authorization schlagen ab v2.12 in der Validierung fehl. Wer keines von beidem nutzt, aktualisiert wie oben beschrieben.
Verifizieren: Nach dem Update ist das Dashboard weiterhin unter Port 19999 erreichbar und historische Metriken sind vorhanden. docker exec netdata netdata -W buildinfo zeigt die neue Version.
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: Die Datei enthält 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: 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 funktioniert ohne Konto. Netdata Cloud lohnt sich erst, wenn Sie mehrere Geräte zentral überwachen möchten.
Wie viele Ressourcen verbraucht Netdata auf dem NAS?
Laut offiziellem GitHub benötigt Netdata auf Produktionssystemen ca. 5 % CPU und 150 MiB RAM. Historische Metriken belegen dank Tiered Storage etwa 0,5 Byte pro Messwert, der Plattenbedarf bleibt auch bei langer Aufbewahrung gering.
Was ist der Unterschied zu Grafana, Zabbix und Checkmk?
Netdata läuft ohne Konfiguration mit eingebautem Dashboard direkt nach dem Start. Grafana hingegen braucht eine separate Datenquelle (z.B. Prometheus) und manuell erstellte Dashboards: mehr Flexibilität, 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 überwacht agentenbasiert und eignet sich für IT-Abteilungen, ist aber aufwendiger einzurichten.
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 automatisch der Bereich „Containers“ mit CPU und RAM je Container. Ohne den Mount fehlt er ohne Fehlermeldung.
Kann ich Alarme konfigurieren?
Ja. Netdata bringt Hunderte vorkonfigurierter Alarme mit (z.B. RAM > 90 %, Disk > 80 %). Eigene Alarme legen Sie als .conf-Dateien in /etc/netdata/health.d/ an (Volume netdataconfig oder per docker exec). Benachrichtigungen per E-Mail, Slack oder PagerDuty funktionieren auch ohne Cloud.
Warum fehlen PUID und PGID in der Compose?
Das offizielle Image wertet PUID/PGID nicht aus. Netdata läuft als root, weil Kernel-, Prozess- und Container-Netzwerkmetriken Root-Rechte erfordern.
Was passiert bei :latest statt :stable?
:latest zeigt auf den neuesten Build, auch auf Nightly-Builds, und kann instabile Änderungen enthalten. Die Netdata-Dokumentation empfiehlt :stable. Wer Updates selbst steuern will, schreibt die Version fest, z. B. :v2.12.0.
Fazit
Netdata ist das schnellste Monitoring-Setup für das Synology NAS: Compose-Datei einfügen, Container starten, Browser öffnen. Das Dashboard liefert sekündliche Metriken für System und Container ohne Datenbank, Grafana oder Cloud-Konto. Wer später eigene Dashboards oder eine Übersicht mehrerer Systeme braucht, ergänzt Netdata Cloud oder wechselt zu Checkmk, Grafana oder Zabbix. Für ein Heim- oder KMU-NAS genügt Netdata im Alltag meist.
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), Release Notes v2.12.0 (github.com/netdata/netdata/releases).


