Ideen zu SYSMON

[xenos1984]

Seit einiger Zeit benutze ich SYSMON, um Statistiken über die verschiedenen Geräte in meinem Netwerk zu sammeln (ein Server, 2 Laptops, ein paar RPi, alles unter Linux und über ssh, bis auf den FHEM-Server selbst). Das Modul kann schon sehr viel und liefert viele Daten, von daher bin ich ziemlich begeistert davon. Ein paar Dinge sind mir aufgefallen:

• Wenn ein Gerät nicht im Netzwerk vorhanden ist (Laptop ausgeschaltet oder mitgenommen), liefert das Modul im Minutentakt Fehlermeldungen, dass keine Verbindung hergestellt wurde. Die kann man natürlich unterdrücken, aber "eleganter" fände ich, wenn man das Modul einfach an- und abschalten könnte, z.B. in Abhängigkeit von ping-Antwort oder PRESENCE (was dann auch z.B. ping nutzen kann). So weit ich bisher sehe, hat man derzeit nur die Möglichkeit, das SYSMON-Gerät über ein Attribut abzuschalten (was, wenn man es automatisch tut, auch ein Ändern der Konfiguration, mit dem "roten Fragezeichen" angezeigt bedeutet). In der Doku hatte ich auch gefunden, dass man alle Intervall-Faktoren per set auf 0 setzen kann, um gewisse Abfragen zu unterdrücken, aber scheinbar nicht alle.
• Das Modul öffnet für viele readings jeweils eine eigene ssh-Verbindung, führt dann einen Befehl aus und liest die Daten ein. Das sind pro Intervall recht viele Verbindungen. Bei einigen langsamen Geräten (z.B. einen alten RPi) dauert der Verbindungsaufbau aber so lange, dass das Auslesen aller Daten auf diesem Wege über eine Minute dauert und das Modul einen Timeout liefert.
• Ein paar Werte werden nicht gefunden. Bei einem Server z.B. finde ich Temperaturwerte unter /sys/class/hwmon/hwmonX/tempY_input - dort wird aber nicht gesucht. Auch scheinen Pfade z.B. für die CPU Temperatur fest codiert zu sein - wobei ich mir nicht sicher bin, ob die z.B. immer die erste ACPI-Temperatur ist.

Als Workaround habe ich einen Perl-Skript geschrieben, der gewissermaßen umgekehrt funktioniert - also statt aus FHEM heraus die Daten über ssh abzurufen, läuft der Skript (derzeit im Minutentakt über cron) auf dem jeweils überwachten System, liest dort die Daten aus und schickt sie über MQTT an den FHEM-Server. Auf dem Server werden die Daten dann in ein MQTT2_DEVICE gelesen. (Alternativ könnte man sicher auch ein Dummy über Telnet setzen, aber so erscheint es mir eleganter, zumal die Daten JSON-codiert sind.)

Der Vorteil besteht nun darin, dass statt einer periodischen Abfrage - auch dann, wenn das zu überwachende Gerät nicht im Netzwerk vorhanden ist - die Daten immer dann gesendet werden, wenn das Gerät vorhanden ist und läuft, und zwar in einem Rutsch als MQTT Nachricht. Wenn das Gerät offline ist, kommen einfach keine Daten, und es wird auch nicht danach gesucht.

Nachteil ist natürlich, dass man den Skript auf dem jeweiligen Zielsystem laufen lassen muss, und auf diesem dann z.B. auch Perl braucht, den Skript installieren / kopieren und z.B. über cron aktivieren muss. "Eleganter" ist SYSMON in dem Sinne, dass die gesamte Kontrolle - was wann abgefragt wird - zentral in FHEM liegt, und man nur den Zugriff über ssh auf das Zielsystem einrichten muss, aber sonst am Zielsystem nichts machen.

Den Skript in seiner derzeitigen, sicher verbesserungsfähigen Form habe ich angehängt, als Idee oder Inspiration. Ein paar Hinweise dazu:

• Dinge wie z.B. Überwachung des Dateisystems / dessen Auslastung sind (noch) nicht implementiert.
• Temperaturen werden dort gesucht, wo ich sie auf meinen Systemen gefunden habe - also etwas anders als bei SYSMON. Statt fest codierter Werte (z.B. immer thermal_zone0) werden alle gefundenen Werte mit Namen / Fundort übergeben.
• Zur Berechnung von Dingen wir CPU-Nutzung und Netzwerk-Datenrate werden die Werte bei jedem Aufruf mittels Storable in eine temporäre Datei gespeichert und beim nächsten Programmaufruf von dort gelesen. Das könnte man natürlich auch anders machen, z.B. den Skript als Daemon laufen lassen und eine Minute pausieren, oder die Berechnung der Differenz in FHEM vornehmen. Allerdings müsste man da bei meiner derzeitigen Lösung mittels MQTT2_DEVICE wohl etwas mehr Aufwand betreiben.
• Zur Umwandlung in JSON nutze ich nicht das JSON-Perl Modul, um eine Abhängigkeit zu verringern. Da es sich nur um einen einzelnen zu codierenden Hash handelt, reichen auch ein paar einfache String-Funktionen.
• Die Daten werden über mosquitto_pub gesendet (was natürlich dann dieses Programm auf dem Zielsystem erfordert). Sicher könnte man das auch anders lösen, z.B. über MQTT in Perl oder über Telnet, mit weniger Abhängigkeiten.

Kommentare und Ideen sind natürlich sehr willkommen!

[Wernieman]

Ich finde es schon mal gut, hätte da aber eine Anmerkungen:

Würde Dir Empfehlen, für jeden "Wert" ein Unterprogramm zu schreiben. So kann man es dann einfacher Anpassen". Wenn Ein Wert z.B. auf einem Rechner nicht existiert, klammert man einfach "nur" diesen Aufruf aus.

[xenos1984]

Würde Dir Empfehlen, für jeden "Wert" ein Unterprogramm zu schreiben. So kann man es dann einfacher Anpassen". Wenn Ein Wert z.B. auf einem Rechner nicht existiert, klammert man einfach "nur" diesen Aufruf aus.

Gute Idee, das werde ich bei Gelegenheit mal umsetzen.

[Otto123]

Hi,

ich finde die Umkehrung der Datenübertragung goldrichtig. Ich meine das ssh Setup ist jetzt auch nicht völlig easy.
Das Script müsste auf dem github (oder so) liegen und man bräuchte noch ein Setup Script dafür

Könnte man für sowas eigentlich den MQTT2_CLIENT einfach einbinden? Wieviel FHEM braucht der? Vielleicht ne schräge Idee. Vielleicht egal ob man mqtt oder das Modul installieren muss.
Alles nur laut gedacht.

Ich hatte schon mal ganz rudimentär mit MQTT für Windows Systeme angefangen. Wenn man sich einmal auf das Format für die Json Strings festgelegt hat, geht das Prinzip für ganz unterschiedliche Systeme mit einheitlicher Sammelstelle in FHEM.

Gruß Otto

[xenos1984]

Das Script müsste auf dem github (oder so) liegen und man bräuchte noch ein Setup Script dafür

Das kann ich bei Gelegenheit mal in Angriff nehmen. Bisher sind darin einige Dinge fest eingegeben (MQTT Topic an das die Daten gesendet werden, MQTT Server Host / Port), d.h. das erfordert etwas Arbeit es so umzuschreiben, dass man es "automatisch" installieren oder konfigurieren kann.

Könnte man für sowas eigentlich den MQTT2_CLIENT einfach einbinden? Wieviel FHEM braucht der? Vielleicht ne schräge Idee. Vielleicht egal ob man mqtt oder das Modul installieren muss.

Gute Frage, mit dem habe ich bisher nicht gearbeitet. In FHEM nutze ich nur MQTT2_SERVER und keinen externen Broker (Mosquitto nur als Client), weil in meinem Anwendungsfall MQTT ausschließlich zur Kommunikation mit FHEM genutzt wird. Sollte der MQTT2_CLIENT dann auf der sendenden Seite tätig sein?

[Otto123]

Naja quasi anstatt "Mosquitto nur als Client" (mosquitto_pub) MQTT2_CLIENT.
Rudi hat es ja geschafft MQTT ohne irgendwelche anderen Module zu implementieren. Aber läuft eben sicher nicht ohne FHEM - blöde Idee von mir.