Synology NAS überwachen: Möglichkeiten und Grenzen

Eine Synology NAS überwachen Sie mit inping auf zwei Wegen: Ein Runner prüft per HTTP(S), ob sie antwortet, und auf Modellen mit Container Manager meldet der Agent als Container CPU, Arbeitsspeicher, Volumes und alle Container. Den Zustand von RAID und Festplatten sieht inping nicht, den meldet weiterhin DSM.

Was sieht inping auf einer NAS und was nicht?

Schwachstellen meldet inping auf einer NAS nur für Projekte, deren Verzeichnis mit Lockfiles Sie dem Agenten zusätzlich einhängen. Wie das geht, steht in der Anleitung Docker-Container überwachen.

Weg 1: Erreichbarkeit prüfen

Das ist der einfachste Weg und funktioniert auf jedem Modell, denn auf der NAS muss dafür nichts installiert werden. DSM antwortet standardmäßig auf Port 5000 (HTTP) und 5001 (HTTPS). Besser als die Anmeldeseite ist oft der Dienst, auf den es wirklich ankommt, etwa eine Website oder eine Anwendung hinter dem Reverse Proxy von DSM. Legen Sie die Adresse im Projekt an und stellen Sie den erwarteten Statuscode ein, Standard ist 200.

Das Zertifikat ist die häufigste Falle

Der Runner prüft Zertifikate immer. Ein selbstsigniertes Zertifikat, wie es Synology als Ursache der Browser-Warnung beschreibt, zählt als TLS-Fehler und damit als Ausfall. Eine Einstellung, die Prüfung auszuschalten, gibt es nicht. Auch ein Umweg über HTTP hilft nicht, wenn DSM auf HTTPS weiterleitet: Weiterleitungen auf denselben Hostnamen verfolgt der Runner, und die Prüfung endet wieder am Zertifikat.

NAS aus dem Internet erreichbar

Hat die Adresse einen öffentlichen Namen und ein gültiges Zertifikat, zum Beispiel von Let's Encrypt über die DSM-Systemsteuerung, prüfen die Runner von inping sie ohne weitere Einrichtung. Geben Sie DSM aber nicht nur für die Überwachung frei: Eine Anmeldeseite im offenen Internet ist ein höheres Risiko, als es diese Prüfung wert ist.

NAS nur im lokalen Netz

Die Runner von inping erreichen keine privaten Adressen. Dafür brauchen Sie einen eigenen Runner im selben Netz: ein Linux-Gerät mit amd64 oder arm64, zum Beispiel ein Raspberry Pi. Der Free-Tarif enthält 1 eigenen Runner. Nehmen Sie möglichst nicht die NAS selbst dafür, sonst fällt die Prüfung mit ihr aus.

1. Legen Sie den Runner als Team-Admin an, unter Runner → Runner hinzufügen oder im Projekt unter Runner → Runner hinzufügen. Der Dialog zeigt den Befehl mit Token. Einzelheiten stehen in der Installationsanleitung.
2. Erlauben Sie dem Runner private Netze. Im Docker-Betrieb setzen Sie stattdessen INPING_PRIVATE_NETWORKS=true in der .env. Starten Sie den Runner danach neu.
3. Tragen Sie die Adresse als private IP oder mit einer internen Endung ein (.lan, .local, .internal, .home.arpa oder ohne Punkt), zum Beispiel http://192.168.1.10:5000/.

# /etc/inping/runner.toml auf dem Gerät mit dem Runner
private_networks = true

Die dritte Regel ist wichtig: Nur solche Adressen gehen gar nicht erst an die Runner von inping. Ein öffentlicher Name, der nur intern aufgelöst wird oder auf eine private IP zeigt, wird von ihnen weiter geprüft. Sie melden dann einen Fehler, und weil die Mehrheit der Runner entscheidet, entsteht ein falscher Ausfall.

Für solche internen Adressen bleibt praktisch nur HTTP, denn ein Zertifikat einer eigenen Zertifizierungsstelle lässt sich in inping nicht hinterlegen. Dafür darf DSM die Prüfadresse nicht auf HTTPS umleiten (Systemsteuerung → Anmeldeportal → DSM). Ob Sie das in Ihrem Netz möchten, ist Ihre Abwägung; die Prüfung selbst sendet keine Anmeldedaten.

Beachten Sie die Grenze: Fällt der Internetzugang oder der Runner aus, kommen keine Ergebnisse an, und der Status bleibt auf dem letzten Stand. Einen Alarm für einen stillen Runner gibt es derzeit nicht. Der Agent aus Weg 2 schließt diese Lücke teilweise, denn sein Offline-Alarm wird von der Plattform ausgelöst.

Weg 2: Agent über den Container Manager

Dieser Weg ist nicht von uns auf dieser Hardware getestet. Er verwendet das normale Docker-Image des Agenten. Die Verbindung geht nur nach außen zu inping über Port 443, auf der NAS muss kein Port geöffnet werden.

Voraussetzungen

• Container Manager. Ob Ihr Modell ihn bekommt, zeigt das Paket-Zentrum. Üblich ist er auf Plus- und xs-Modellen. Die Versionshinweise von Synology nennen außerdem einzelne ARMv8-Modelle wie DS223 und DS420j sowie DSM 7.2 als Voraussetzung neuerer Versionen.
• Architektur. Das Image gibt es für amd64 und arm64. uname -m muss x86_64 oder aarch64 ausgeben, 32-Bit-ARM wird nicht unterstützt.
• SSH unter Systemsteuerung → Terminal & SNMP, mit einem Administratorkonto. Der Token wird einmalig über die Kommandozeile übergeben. Sie können SSH danach wieder abschalten.
• Ein Agent in inping. Unter Agents → Agent hinzufügen entsteht der Token, einmal sichtbar und 24 Stunden gültig. Version und Digest des Images stehen in den Release-Hinweisen unter /agents/install in der App. Im Free-Tarif sind 2 Agenten enthalten.

1. Dateien anlegen

Erstellen Sie in der File Station den Ordner /volume1/docker/inping-agent und darin die Dateien docker-compose.yml und agent.toml. Setzen Sie Version und Digest ein und nehmen Sie niemals einen beweglichen Tag.

name: inping-agent

services:
  inping-agent:
    image: ghcr.io/medienakzent/inping-agent:<version>@sha256:<digest>
    restart: unless-stopped
    read_only: true
    cap_drop: [ALL]
    security_opt:
      - no-new-privileges:true
    volumes:
      - ./agent.toml:/etc/inping/agent.toml:ro
      - inping-agent-state:/var/lib/inping-agent
      - /proc:/host/proc:ro
      - /sys:/host/sys:ro
      - /:/host/root:ro
    networks: [default, inping]
    depends_on: [inping-docker-proxy]

  inping-docker-proxy:
    image: tecnativa/docker-socket-proxy:0.3.0
    restart: unless-stopped
    environment:
      CONTAINERS: 1
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
    networks: [inping]

volumes:
  inping-agent-state:

networks:
  inping:
    internal: true

api_url = "https://www.inping.io"
state_dir = "/var/lib/inping-agent"

[docker]
endpoint = "tcp://inping-docker-proxy:2375"
all = true

Die Konfiguration liegt hier bewusst in einer eigenen Datei. Unsere allgemeine Vorlage schreibt sie direkt in die Compose-Datei, das braucht aber Compose 2.23.1 oder neuer, und welche Version Ihr Container Manager mitbringt, zeigt erst sudo docker-compose version. Die Datei agent.toml enthält kein Geheimnis. all = true meldet alle Container der NAS statt nur die eines Compose-Projekts.

Der Socket-Proxy lässt nur Lesezugriffe auf /containers durch, er schützt also den Host vor dem Agenten. Er erlaubt aber das Lesen aller Containerdaten einschließlich der Logs. Die Variante ganz ohne Proxy beschreibt die Installationsanleitung; sie ist weniger sicher, weil der Docker-Socket keinen Nur-Lese-Modus kennt.

2. Einmal registrieren

Melden Sie sich per SSH an und führen Sie Folgendes aus. Der Token kommt aus dem Dialog in der App.

cd /volume1/docker/inping-agent
chmod a+r agent.toml
echo "<token>" | sudo docker-compose run --rm -T inping-agent register --token -

Der Agent läuft als Benutzer 65532 und muss agent.toml lesen können, daher das chmod. In freigegebenen Ordnern von DSM können zusätzlich Zugriffsrechte greifen. Die Befehle verwenden docker-compose, weil Container Manager es mitbringt. Falls es fehlt, versuchen Sie docker compose.

3. Projekt im Container Manager starten

Öffnen Sie Container Manager → Projekt → Erstellen, wie Synology es beschreibt. Nennen Sie das Projekt inping-agent, damit es denselben Namen und dasselbe Volume wie die Registrierung nutzt, wählen Sie den Ordner als Pfad und die vorhandene docker-compose.yml als Quelle.

Innerhalb einer Minute sollte der Agent in inping Online sein. Die Container erscheinen unter Services nach zwei Messungen, die Kennzahl schalten Sie falls nötig unter Einstellungen → Erfasste Metriken ein. Ordnen Sie den Agenten unter Agents → (Agent) → Einstellungen → Projekte einem Projekt zu, damit dessen Benachrichtigungsregeln greifen.

Updates

Im Container aktualisiert sich der Agent nicht selbst. Tragen Sie die neue Version und den neuen Digest in die docker-compose.yml ein und führen Sie Folgendes aus:

cd /volume1/docker/inping-agent
sudo docker-compose pull inping-agent
sudo docker-compose up -d inping-agent

Wenn nichts ankommt

• Der Container startet nicht und meldet die Konfiguration: Der Benutzer 65532 kann agent.toml nicht lesen. Prüfen Sie die Rechte der Datei und des Ordners.
• cannot start: Der Agent wurde nicht registriert, oder Registrierung und Projekt nutzen verschiedene Volumes. Vergleichen Sie den Projektnamen mit name: in der Datei.
• registration failed: Der Token ist abgelaufen oder bereits benutzt.
• docker source unusable: Der Proxy ist nicht erreichbar. Die Host-Werte kommen trotzdem an.
• Die Werte passen nicht zur NAS: Eine der Host-Einhängungen fehlt, der Agent misst dann nur seinen Container. Das Log nennt die fehlende.
• Kernel älter als 5.13: Die zusätzliche Dateisystemsperre über Landlock greift dann nicht, der Agent läuft trotzdem. Der Container bleibt schreibgeschützt.

Was sollten Sie an einer NAS überwachen?

In inping

• Offline-Alarm des Agenten. Er meldet, wenn die NAS oder ihre Verbindung ins Internet weg ist, ohne dass Sie etwas freigeben. Auch ein DSM-Update mit Neustart löst ihn aus, wählen Sie die Zahl der verpassten Meldungen passend.
• Volume-Belegung. Neue Server starten mit der Regel „jede Platte über 90 %“. Für ein Datenvolume ist eine eigene, frühere Schwelle für /volume1 sinnvoll, denn der Platz lässt sich auf einer NAS selten kurzfristig erweitern. Gemeldet wird das Dateisystem, nicht der freie Platz im Storage Pool.
• CPU über längere Zeit. Datensicherungen und RAID-Bereinigung lasten eine NAS länger aus. Verlängern Sie das Zeitfenster der CPU-Regel, wenn der Standard von 5 Minuten zu oft auslöst.
• Dienste. Ein gestoppter Container löst den Alarm Service steht aus. Ergänzen Sie für wichtige Anwendungen eine HTTP-Prüfung, denn ein laufender Container sagt nicht, dass die Anwendung antwortet.

In DSM: RAID und Festplatten

Ein degradiertes RAID ist das wichtigste Ereignis auf einer NAS, und inping sieht es nicht: Das Volume bleibt eingehängt, die Belegung unverändert, alle Werte wirken normal. Richten Sie deshalb in DSM ein:

• Benachrichtigungen per E-Mail, Push oder Webhook, und prüfen Sie, ob die Testnachricht ankommt.
• S.M.A.R.T.-Tests im Speicher-Manager, geplant als wiederkehrende Aufgabe.
• Für mehrere Geräte: Active Insight, der Cloud-Dienst von Synology. Prüfen Sie dessen Lizenz- und Datenschutzbedingungen selbst.
• Für eine bestehende Netzwerküberwachung: SNMP in DSM, mit den MIB-Dateien von Synology für Laufwerke und RAID. Das übernehmen SNMP-fähige Werkzeuge, inping fragt SNMP nicht ab.

Warum nicht das normale Installationsskript?

Auf einem Linux-Server richtet das Installationsskript ein Dienstkonto, Dateien unter /etc und einen Update-Timer ein. Es ist für gängige Linux-Distributionen gebaut, nicht für DSM, das Synology als eigene Appliance pflegt. Wir unterstützen es dort nicht, auch nicht mit --user. Der Container hält die NAS frei von Änderungen und liegt vollständig im Volume und im Projektordner.

Was kostet das?

Beide Wege funktionieren im Free-Tarif: 2 Agenten, 1 eigener Runner und 10 URLs pro Projekt, geprüft höchstens alle 60 Sekunden. Die übrigen Tarife finden Sie unter Preise, weitere Installationswege unter Einbindung.

Häufige Fragen