[gelöst] Überwachung Raspberry / FHEM mit Synology NAS

[FhemPiUser]

Hallo,

ich suche nach einer einfachen Möglichkeit zu überwachen, ob FHEM bzw. der Raspberry, auf dem FHEM läuft, läuft. Es sollte mindestens eine Email oder eine Push Nachricht gesendet werden, wenn FHEM nicht mehr läuft.

Bei mir läuft ständig ein Synology NAS. Hat mal jemand eine Überwachung von FHEM vom Synology NAS / DSM aus eingerichtet?

Eine Möglichkeit wäre ein Script, welches periodisch vom NAS aus ein wget auf die fhem URL macht und bei Fehlern eine custom notification mit Benachrichtigung (email, Push) in Synology wirft (http://www.beatificabytes.be/send-custom-notifications-from-scripts-running-on-a-synology-new/), aber einfach klingt das auch nicht wirklich...

[Fredi69]

Daran habe ich auch Interesse!

[Otto123]

Als Idee:
Eine Abfrage mit meinem HTTP Client, z.B. list DummyIrgendwas state
Rückgabe auswerten: no response
und oder/ script mit time aufrufen und Zeit auswerten. Falls FHEM "heiß" läuft und träge reagiert.

Probier mal ob der Client ohne Umstände auf der Synology läuft. Ansonsten kenn ich  mich mit der Synology nicht wirklich aus, wegen Benachrichtigung, zyklischer Start usw.

Gruß Otto

[FhemPiUser]

@otto123: danke, das meinte ich mit ,,periodisch vom NAS aus ein wget auf die fhem URL machen".

Was ist denn der Mehrwert/Unterschied zwischen Deinem fhem http client und wget oder curl?

[Otto123]

Probier es doch einfach aus
Der kümmert sich um den csrf Token.
Der liefert Dir z.B. keine Webseite in HTML Code sondern genau die response auf das was Du wolltest.

[Tedious]

Dafür nutzt man an sich Monit... das überwacht auch remote clients, schickt Nachrichten, startet Prozesse neu, etc...

[FhemPiUser]

Ich habe es mal kurz mit der für mich einfachsten Methode ausprobiert und es hat auf Anhieb funktioniert:

1. [Optional] Ein Dummy FhemMonitorNASDummy in FHEM anlegen.
2. [Optional] Eigene FHEMWEB-Instanz angelegen, die nur ein get auf FhemMonitorNASDummy machen darf und der Zugriff darauf nur von der IP des NAS erlaubt ist. Für diese Instanz kann man dann SSL, CSRF Token und Auth abschalten.
3. Eine custom notification "fhem_dead" mit Benachrichtigung (z.B. email, Push-Notification auf Handy) in Synology anlegen gemäß Anleitung unter http://www.beatificabytes.be/send-custom-notifications-from-scripts-running-on-a-synology-new/
4. Folgendes Skript "checkfhemalive.sh" irgendwo auf dem NAS ablegen:

Code Auswählen Erweitern


#/bin/sh
curl -m 15 http://<IP-Adresse FHEM>:<Port>/fhem?cmd=get%20FhemMonitorNASDummy
if [ $? -eq 0 ]
  then
   echo "ok"
else
  echo "failure"
  /usr/syno/bin/synonotify fhem_dead
fi

(Anmerkung: "get" ist eigentlich beim Dummy nicht definiert und fhem antwortet mit einer Fehlermeldung. Da es aber nur darum geht, ob fhem antwortet, spielt das keine Rolle. Alternativ kann man natürlich das get durch Befehle wie set oder list ersetzen...)
5. Im Aufgabenplaner in DSM ein periodisches Aufrufen (z.B. alle 5min) des Skripts "checkfhemalive.sh" konfigurieren. Fertig.

Testen kann man z.B., in dem man die IP-Adresse im Skript mal auf eine nicht-existierende IP setzt.

Jetzt überwacht der NAS fhem und fhem den NAS (ping modul)  . Verbesserungen/Anmerkungen sind willkommen. Danke Euch!

Update: Einziger Haken, von dem ich erst im Nachhinein gelesen habe: Offenbar werden die für die custom notifications zu ergänzenden Dateien nach einem DSM Update ersetzt, sodass man diese Dateien jedesmal nach einem Update wieder neu die  Ergänzungen hinzufügen muss. Das kann man aber mit einem kleinen Skript  machen, wenn man sich die Ergänzungen in Dateien (bei mir mit <Dateiname>_add) irgendwo auf dem NAS ablegt. Als Beispiel anbei mein Skript "reinstallcustomnotification.sh":

Code Auswählen Erweitern


#/bin/sh
if [ `grep fhem_dead /usr/syno/synoman/webman/texts/enu/mails |wc -l` -eq 0 ]
  then
    echo "fhem_dead in enu/mails nicht enthalten. Fuege hinzu."
    cat enu/mails_add >> /usr/syno/synoman/webman/texts/enu/mails
   else
     echo "fhem_dead in enu/mail enthalten"
  fi
if [ `grep fhem_dead /usr/syno/synoman/webman/texts/ger/mails |wc -l` -eq 0 ]
  then
    echo "fhem_dead in ger/mails nicht enthalten. Fuege hinzu."
    cat ger/mails_add >> /usr/syno/synoman/webman/texts/ger/mails
  else
    echo "fhem_dead in ger/mail enthalten"
  fi
if [ `grep fhem_dead /usr/syno/etc/notification/notification_filter.settings |wc -l` -eq 0 ]
  then
    echo "fhem_dead in notification_filter.settings nicht enthalten. Fuege hinzu."
    cat notification/notification_filter.settings_add >> /usr/syno/etc/notification/notification_filter.settings
  else
    echo "fhem_dead in notification_filter.settings enthalten"
  fi


Das Skript kann man auch im Aufgabenplaner anlegen, sodass man es periodisch oder einmalig nach dem Update direkt in DSM einfach ausführen kann. Evtl. ist noch ein Neustart notwendig.

Tipp: Damit man den manuellen Aufwand langfristig nicht mehr hat und das ganze deutlich komfortabler wird, gerne zahlreich den feature request bei synology unterstützen (https://community.synology.com/forum/17/post/76776?page=4), dass custom notifications von synology in dsm offiziell und per gui unterstützt werden.

@Tedious: Ja, Monit wäre wohl die professionelle und deutlich mächtigere Lösung, aber für meinen Use Case vermutlich überdimensioniert und für mich als Neuling für Monit vermutlich auch nicht so schnell und einfach einzurichten.

[Otto123]

Hi FhemPiUser,

Punkt 1. brauchst Du für deinen test nicht ->
punkt 2. bringt gar nichts. Du testest lediglich ob ein http Service reagiert. Egal ob der ablehnt oder was der liefert, irgendeine Reaktion von FHEM wird nicht getestet.

Tipp: Der Test auf $? -eq 0

Code Auswählen Erweitern

Befehl
if [ $? -eq 0 ]
then
...
ist redundant und kann normalerweise verkürzt werden:

Code Auswählen Erweitern

if Befehl
then
...

Die Option -m könnte ich in mein Script einbauen
Um allen Eventualitäten vorzubeugen müsste zusätzlich --connect-timeout <seconds> gesetzt werden?
Es gibt für beide Werte offenbar voreingestellte Werte im Minutenbereich.

Gruß Otto

[FhemPiUser]

@Otto123: Stimmt, es sollte auch ohne Punkt 1 und 2 funktionieren.

-m ist die max-time für die gesamte Ausführung von curl, beinhaltet also die connection-timeout...

[Otto123]

Ja stimmt -m erschlägt beide Zeiten