Zum Hauptinhalt springen
S-EDV news
← Alle Anleitungen
📘 Anleitung Monitoring 11.09.2026 · 11 min Lesezeit

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.

Netdata auf dem NAS: CPU und RAM, Container, Echtzeit-Metriken. Illustration mit Laptop und Administrationsoberfläche. KI-generiert

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 /volume1 fü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.

ParameterWertZweck
Imagenetdata/netdata:stableStabile Version; :latest enthält Nightly-Builds
Port19999 (Host-Mode)Web-Dashboard, HTTP, kein Login erforderlich
network_modehostVollständige Netzwerk-Stack-Sichtbarkeit
pidhostProzess-Monitoring und Service-Discovery
cap_addSYS_PTRACE, SYS_ADMINPflicht für vollständige Monitoring-Funktionalität
Ressourcen~5 % CPU, ~150 MiB RAMNAS-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:

  1. 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.
  2. Docker-Container-Metriken: Im Abschnitt „Containers" erscheinen alle laufenden Container mit Name, CPU und RAM. Wenn dieser Bereich fehlt, ist /var/run/docker.sock nicht korrekt gemountet.
  3. 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:ro ist 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:ro aus 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:unconfined fehlt. Ohne diesen Eintrag blockieren DSM-AppArmor-Profile Netdatas Plugins. Eintrag ergänzen, Container neu starten.
  • Dashboard startet, zeigt aber kaum Metriken: pid: host oder network_mode: host fehlt. Ohne pid: host sind 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: host als auch eine ports:-Sektion in der compose.yaml. Bei Host-Mode die ports:-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 — per docker exec -it netdata bash in 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

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).