PRTG und MQTT

Das Protokoll MQTT ist im Umfeld der Server, Systeme und Applikationen eher selten im Gebrauch. Es hat seine Stärke in der Mess- und Regeltechnik und hier insbesondere im IoT-Bereich. "Publisher" ermitteln Daten und senden Sie an einen MQTT-Broker. Entsprechende Subscriber können diese Daten dann auslesen. Aber da kommt dann doch PRTG wieder mit ins Boot, wenn er die MQTT-Server überwachen, dort vorhandene Daten übernehmen oder eigene Daten senden will.

Aktueller Stand

Als die erste Version dieser Seite öffentlich wurde, hatte PRTG noch keine MQTT-Unterstützung. Irgendwann tauchte aber auf der Roadmap der Begriff MQTT erstmalig auf:


https://www.paessler.com/prtg/roadmap

Seit August 2020 konnte dann erstmals ein MQTT-Subscriber als Sensor ausgewählt werden.

Sehr schnell kamen dann noch zwei weitere Sensoren dazu:

Eigentlich sollte man damit die meisten Fälle abdecken können.

MQTT Round Trip Sensor

Mit dem Round Trip Sensor kann generell der MQTT-Broker überwacht werden. PRTG schreibt einfach regelmäßig einen langen Wert in ein Topic und liest dies wieder aus. Auf meinem Mosquitto kann ich mit MQTT Explorer folgendes sehen:

Der Wert wird in den Standardeinstellungen alle 60 Sekunden. Über die Laufzeit sehen Sie dann gut, wann der MQTT-Server nicht erreichbar war.

Natürlich könnten sie den MQTT-Server auch weiterhin per PING oder TCP-Port-1883-Checks überwachen. Aber erst mit dem MQTT Round-Trip Sensor wissen sie, dass hinter Port 1883 auch ein MQTT-Server antwortet.

MQTT Statistics Sensor

Dieser Sensor erfasst nicht die Werte eines Topics sondern erfasst die Anzahl der Änderungen eines Topic. Wenn Sie z.B. erwarten dass ein Topic sich immer wieder regelmäßig ändert, dann können Sie hier die Änderungsrate erfassen lassen.

Sie können ein explizit benanntes Topic nutzen oder auch mit "+" oder "#" mehrere Topics zusammenfassen. Wer also "#" als Topic einträgt, bekommt die Anzahl aller Änderungen in einer bestimmten Zeit mit.

PRTG Tutorial: MQTT Statistics Sensor - YouTube
https://www.youtube.com/watch?v=ZqVGTScHEFg

MQTT Subscribe Custom

Der sicher interessanteste Sensor ist der "MQTT Subscribe Custom"-Sensor, mit dem Sie sich auf ein Topic registrieren können und die JSON-Payload parsen können. Der kniffligere Aspekt ist hier sicher das Erstellen einer passenden Abfrage, da es wohl keinen "Assistenten" gibt, dem man ein Topic vorwerfen könnte. Daher schaue ich mir das Topic vorab mit MQTT Explorer an. Hier habe ich einen ESP8266 mit Tasmota-Firmware zum Auslesen eines BME280-Sensors gebaut.

Entsprechend kann ich dann in PRTG einen Sensor mit mehreren Kanälen anlegen. Der Erste Kanal ist die Temperatur, dann Feuchtigkeit und Druck:

In meinem Fall hatte ich den ESP8266 auch als Vampir im IKEA Vindriktning verbaut. Daher konnte ich auch noch den Partikelsensor als weitere Kanäle mit mit folgenden JSON-Pfaden addieren

$.VINDRIKTNING.PM1
$.VINDRIKTNING.PM2.5
$.VINDRIKTNING.PM10

Ein "Sofort Abfragen" hilft in PRTG natürlich nicht. Der neue Sensor muss erst bei der Probe ankommen aber dann muss diese einen "Subscribe" gegen den MQTT-Server machen. Wenn der Publisher die Werte nicht mit dem Flag "Retained" (Beibehalten) gesetzt hat, dann muss erst eine neue Meldung ankommen. Aus dem Grund schalte ich zumindest am Anfang auch immer das Debugging mit ein:

Mein Sensor hatte die Nummer 2232 und entsprechend landete das Log in "C:\ProgramData\Paessler\PRTG Network Monitor\Logs\sensors\Result of Sensor 2232.log"

Datei wurde umgebrochen, um die Fensterbreite nicht zu überschreiten.

2021-10-05 16:08:42.002264 DEBG TId   37996 Result of Sensor 2232> #################### Enter sensor scan ####################
2021-10-05 16:08:42.002264 DEBG TId   37996 Result of Sensor 2232> Working with message: {"Time":"1970-01-01T01:15:14",
                                "BME280":{"Temperature":23.6,"Humidity":40.1,"DewPoint":9.3,"Pressure":992.9},
                                "VINDRIKTNING":{"PM1":848,"PM2.5":6,"PM10":6},"Global":{"Temperature":23.6,"Humidity":40.1,"DewPoint":9.3,
                                      "Pressure":992.9,"SeaPressure":993.3},"PressureUnit":"hPa","TempUnit":"C"}
2021-10-05 16:08:42.002264 DEBG TId   37996 Result of Sensor 2232> Processing channel 1 with json path: $.BME280.Temperature
2021-10-05 16:08:42.002264 DEBG TId   37996 Result of Sensor 2232> Found value: 23.600000
2021-10-05 16:08:42.002264 DEBG TId   37996 Result of Sensor 2232> Processing channel 2 with json path: $.BME280.Humidity
2021-10-05 16:08:42.002264 DEBG TId   37996 Result of Sensor 2232> Found value: 40.100000
2021-10-05 16:08:42.002264 DEBG TId   37996 Result of Sensor 2232> Processing channel 3 with json path: $.BME280.Pressure
2021-10-05 16:08:42.003265 DEBG TId   37996 Result of Sensor 2232> Found value: 992.900000
2021-10-05 16:08:42.003265 DEBG TId   37996 Result of Sensor 2232> Processing channel 4 with json path: $.VINDRIKTNING.PM1
2021-10-05 16:08:42.003265 DEBG TId   37996 Result of Sensor 2232> Found value: 848.000000
2021-10-05 16:08:42.003265 DEBG TId   37996 Result of Sensor 2232> Processing channel 5 with json path: $.VINDRIKTNING.PM2.5
2021-10-05 16:08:42.003265 DEBG TId   37996 Result of Sensor 2232> Error while processing channel #5 with json path: $.VINDRIKTNING.PM2.5: 
                                                                                       The queried field is empty: $.VINDRIKTNING.PM2.5
2021-10-05 16:08:42.003265 DEBG TId   37996 Result of Sensor 2232> Processing channel 6 with json path: $.VINDRIKTNING.PM10
2021-10-05 16:08:42.003265 DEBG TId   37996 Result of Sensor 2232> Found value: 6.000000
2021-10-05 16:08:42.003265 DEBG TId   37996 Result of Sensor 2232> #################### Exit sensor scan  ####################

Hier ist gut zu sehen, dass der JSON-Pfad "$.VINDRIKTNING.PM2.5" leider einen "." (Punkt" im Variablennamen enthält. Ich habe das Feld dann einfach mit doppelten Anführungsstrichen versehen.

Die Syntax scheint sich nicht an JSONPath zu halten. Aber ich finde sie so aktuell noch einfacher. Die Zukunft wird zeigen, wie flexibel sie zukünftig ist.

Die Daten sind dann wieder in der Übersicht sichtbar

Über die Zeit werden sich dann rechts die Grafiken weiter füllen. Der MQTT-Sensor läuft in meinem Beispiel alle 60 Sekunden. Gerade batteriebetriebene Geräte melden Daten aber seltener. Wenn das MQTT-Topic aber in größeren Abständen aktualisiert wird, dann kann PRTG natürlich keine neuen Daten erhalten und zeigt das auch an.

Das kann verwirrend sein aber ist hier erwartet. Es gibt ja keine Daten. Sie sollten daher das Intervall nicht kürzer als die Zeit setzen, in der die Daten auch eintreffen. Das sieht dann in den Diagrammen nicht sehr nett aus

Dieses Verhalten lässt Rückschlüsse auf die interne Verarbeitung zu.

PRTG Tutorial MQTT Subscribe Custom Sensor - YouTube
https://www.youtube.com/watch?v=86FfXC7MUmA

MQTT Subscribe Custom ohne JSON

In der Beschreibung zum MQTT steht, dass die Daten in einem gültigen JSON-Format sein müssen:


Quelle: https://www.paessler.com/manuals/prtg/mqtt_subscribe_custom_sensor

Nun gibt es aber auch Geräte, die einfach nur einen Wert in einem Topic veröffentlichen: Hier ein Beispiel eines Shelly IoT-Device in MQTT Explorer.

Aber auch diese Daten konnte ich mit PRTG einlesen. Ich habe einfach "$" in den Kanal eingegeben:

Die Daten wurden sauber erfasst und dargestellt. Da die Shelly-Systeme die Daten alle 30 Sekunden senden, gibt es auch keine Lücke mit einem Sensor, der alle 60 Sekunden die Daten abfragt.

MQTT-Publish

PRTG kann nicht nur als "Subscriber" Werte eines MQTT Brokers abrufen sondern auch selbst Meldungen versenden. PRTG kann Meldungen per MQTT an einen Broker senden. Wenn Sie z.B. eine per IoT gesteuerte farbige LED an der Wand haben, die ein MQTT-Topic folgt, dann kann PRTG dieses Topic schreiben.

PRTG Tutorial MQTT Notifications - YouTube
https://www.youtube.com/watch?v=6jVaqHhOj6k

Details zur Funktion

Natürlich habe ich mit Bordmitteln hinterfragt, wie PRTG die MQTT-Umsetzung realisiert hat. Schon im Performance Monitor ist zu sehen, dass die "PRTG Probe.exe" eine ausgehende Verbindung zum MQTT-Server auf. und abbaut.

Im Installationsverzeichnis, bei mir "C:\Program Files (x86)\PRTG Network Monitor" findet sich eine "MqttNotification.dll", in der vermutlich die Funktionen ausgelagert sind.

Paessler scheint das MQTT-Plug-in überwiegend selbst entwickelt zu haben. Bei meinem Einsatz habe ich folgende Dinge feststellen können:

  • Neuere Meldungen überschreiben ältere Meldungen
    Wenn ein MQTT-Topic häufiger aktualisiert wird, als der PRTG-Sensor die Daten abfragt, dann wird anscheinend nur die letzte Meldung ausgewertet. Das habe ich bei der Einbindung von MI Sensor mit BTLE Gateway festgestellt, bei der das Gerät mehrere JSON-Meldungen nacheinander unter dem gleichen Topic postet. Hier wertet PRTG wohl immer nur die aktuellste Meldung aus.
  • Sammeln und Polling statt Push
    Ich habe auf zwei Sensoren das "Ergebnis behalten" aktiviert. Das Protokoll listet aber alle Topics, die auf dieser Probe "Subscribed" sind. Wenn ich einen Sensor komplett lösche, dann landet der Event auch in allen Logs.
2021-10-05 16:41:33.005293 DEBG TId 40232 Result of Sensor 2232> MQTT Client - PRTG_HHREY: Unsubscribe from '#'
2021-10-05 16:41:33.005293 DEBG TId 40232 Result of Sensor 2232> MQTT Client - PRTG_HHREY: Deleted subscription for '#'
2021-10-05 16:41:33.006295 DEBG TId 40232 Result of Sensor 2232> MQTT Client - PRTG_HHREY: Return code = 0 in method in synchronize_call()
2021-10-05 16:41:33.006295 DEBG TId 40232 Result of Sensor 2232> MQTT Client - PRTG_HHREY: Unsubscribed topic '#'

Sie sollten daher die "Ergebnisse speichern" nur aktivieren, bis Sie den Fehler gefunden haben und die Werte korrekt eingelesen werden.
Die Log-Datei wird beim Erreichen von 1 MB umbenannt Result of Sensor 2216.log -> Result of Sensor 2216.log.1

Anhand dieser Beobachtungen vermute ich, dass die Probe die Topics aller auf ihre gehosteten Sensoren per "Subscribe" abonniert und in einem internen Datenspeicher hält. Der Sensor wiederum fragt dann diesen Speicher nach der letzten aktuellen Meldung ab.

Diese Verhalten führt natürlich zu Lücken in Grafiken oder überlesene Werte bei zu hohen Aktualisierungsraten. Auf der anderen Seite hat PRTG schon lange PRTG - HTTP Push-Sensoren. Ich frage mich schon, warum der MQTT-Funktion nicht einfach jeden gemeldeten Wert direkt per "Push" an PRTG sendet.

Auf der Suche nach weiteren Hinweisen zur Funktion bin ich auf eine zweite Protokolldatei gestoßen.

C:\ProgramData\Paessler\PRTG Network Monitor\Logs\debug\paessler_mqtt.log

Hier scheint der MQTT-Services in der Probe die Verbindungen zum MQTT-Server zu protokollieren.

2021-09-30 19:36:18.938910 NOTI TId   41676 paessler_mqtt> MQTT Client - PRTG_2219SCzP: Connected to: tcp://192.168.178.10:1883 - MQTT Version: 4
2021-09-30 19:36:19.951623 NOTI TId   41676 paessler_mqtt> MQTT Client - PRTG_2219PCzP: Connected to: tcp://192.168.178.10:1883 - MQTT Version: 4
2021-09-30 19:36:21.182747 NOTI TId   19992 paessler_mqtt> MQTT Client - PRTG_2219PCzP: Cleaning up.
2021-09-30 19:36:21.184713 WARN TId   19992 paessler_mqtt> MQTT Client - PRTG_2219SCzP: Found unreferenced weak_ptr during unsubscribe_all for topic: PRTG/roundtrip/2219_CzP
2021-09-30 19:36:21.185708 NOTI TId   19992 paessler_mqtt> MQTT Client - PRTG_2219SCzP: Cleaning up.
2021-09-30 19:37:24.964521 NOTI TId   41676 paessler_mqtt> MQTT Client - PRTG_2219SxhM: Connected to: tcp://192.168.178.10:1883 - MQTT Version: 4
2021-09-30 19:37:25.974523 NOTI TId   41676 paessler_mqtt> MQTT Client - PRTG_2219PxhM: Connected to: tcp://192.168.178.10:1883 - MQTT Version: 4
2021-09-30 19:37:27.195077 NOTI TId   20184 paessler_mqtt> MQTT Client - PRTG_2219PxhM: Cleaning up.
2021-09-30 19:37:27.195077 WARN TId   20184 paessler_mqtt> MQTT Client - PRTG_2219SxhM: Found unreferenced weak_ptr during unsubscribe_all for topic: PRTG/roundtrip/2219_xhM

So können Sie z.B. Blockaden durch eine Firewall oder falsche Anmeldedaten erkennen.

Node-RED und MQTT

Sie können die in PRTG eingebaute Funktion zur Abfrage von MQTT-Daten nutzen. Allerdings ist die aktuelle Implementierung (2021) aus meiner Sicht noch nicht optional. Ich würde es schon vorziehen, dass jede eingehende Meldung umgehend geprüft und an den Sensor gesendet wird. Das Intervall beim Sensor kann dann ja vergleichbar zu den PRTG - HTTP Push-Sensoren dazu nutzen, ausbleibende Daten zu erkennen.

Ehe es die Bordmitteln gab, hat Paessler selbst beschrieben, wie z.B. mit einer Node-RED-Installation Werte aus einem MQTT-Broker ausgelesen und per HTTPPush an PRTG gesendet werden können.

Frühere Überlegungen

Alle, was ab hier geschrieben steht, wird nicht mehr aktualisiert. Es gab ja eine Zeit, als MQTT und PRTG nicht zu verbinden waren. Damals habe ich mir schon Gedanken gemacht und sogar ein PowerShell-Skript geschrieben, welches MQTT mit PRTG verbunden hat. Diese Funktionen und Überlegungen sind hier nur noch aus historischen Gründen.

Das Problem mit MQTT und PRTG

Bei Einsatz von MQTT und PRTG gibt es besondere Herausforderungen, warum auch meine Lösung die ein oder andere Einschränkungen hat:

  • MQTT ist Realtime
    d.h. ein MQTT-Client sendet Daten an den MQTT-Broker, welcher diese in der Regel sofort an einen "Subscriber" weiterleitet. Es gibt normal keinen Status oder Puffer. Wenn ein Subscriber nicht da ist, dann übersieht er etwas. Ja, man kann Werte als Client auch so senden, dass diese beim Broker vorgehalten werden und dann ein Subscriber auch nachträglich den letzten Werte bekommt. Das muss aber der Client beim Absendern schon vorgeben und der Broker muss den Speicher vorhalten.
  • MQTT sind Einzelmeldungen
    Solange ein MQTT Wert auch genau zu einem PRTG-Sensor passt, könnte man das einfach machen. Aber wenn der PRTG-Sensor mehrere Kanäle hat, dann wäre ein Check oder ein Push für jeden einzelnen Kanal kontraproduktiv. Hier müsste man also etwas Daten "sammeln", damit PRTG dann einen kompletten Datensatz bekommt. Das kann natürlich auch ein Problem für PRTG selbst werden, da ein Sensor die Daten nicht immer vom MQT Broker als Gruppe "Abfragen" kann.
  • Es kann nur einen MQTT-Broker geben
    Natürlich können Sie mehrere MQTT-Broker in ihrem Netzwerk installieren aber die meisten Sensoren und Aktoren können nur einen Broker ansteuern. Daher ist es unwahrscheinlich, dass Sie PRTG als Broker aufsetzen. PRTG oder ein Helper muss also als Subscriber arbeiten. Meist hat ein System aus Broker und Service auch aktive Funktionen, z.B. auf bestimmte Eingabedaten wieder Aktionen zu triggern. Da will ich gar nicht eingreifen.

Mit diesen Vorüberlegungen haben ich mir dann verschiedene Ansätze überlegt und einen davon implementiert.

Im unteren Teil gibt es zwei PowerShell-Skripte, die als MQTT-Subscriber Daten von einem MQTT Broker lesen und per HTTP Push-Sensoren an PRTG senden.

MQTT Ecosystem

MQTT besteht aus Komponenten, die Daten erfassen und senden und mindestens einer zentralen Stelle, die diese Meldungen annimmt und verarbeitet. Zudem gibt es Teile, die solche Daten wieder auslesen und z.B. anzeigen oder anders reagieren.

Lesen Sie dazu auch die Seite MQTT und Powershell und MQTT

Bei MQTT haben sich folgende Begriffe dafür etabliert.

  • Publisher
    Ein klassischer Publisher erfasst Temperatur, Wind, Energie, Licht, Präsenz, Durchfluss u.a. Werte, die es an einen zentrale Stelle sendet
  • Broker
    Der Broker sammelt all diese Daten ein und kann basierend darauf auch Aktionen auslösen. Der Broker kann auch "befragt" werden
  • Subscriber
    Dieser Prozess liest Daten aus, um diese z. B. anzuzeigen

Natürlich kann ein Publisher auch zugleich Subscriber sein, d.h. er kann Daten senden (z.B. Temperatur, Stromverbrauch, Präsenz), aber auch zugleich Befehle (Schalten, Dimmen) annehmen.

PRTG macht etwas MQTT

Natürlich könnte PRTG selbst ein Broker sein und per MQTT direkt Meldungen annehmen und in seine Datenbank übernehmen. Das klingt erst mal nicht schlecht und würde zusätzliche Dienste ersparen Aber wer es sich genau überlegt wird diesen Weg gar nicht gehen wollen, da der Broker ja durchaus auch andere Dinge übernehmen kann und vielleicht auch soll. Es gibt viele gute Broker und es wäre vermessen von Paessler zu erwarten, dass Sie einen MQTT-Broker in ihr Produkt einbauen. Da viele MQTT-Clients auch nur genau einen Broker unterstützen, wäre auch eine Integration in andere Dienste unmöglich. Insofern bin ich Paessler nicht böse, dass Sie kein MQTT Broker sind.

Aber erste Spuren eines MQTT -Support verraten sich schon in den ein oder anderen Log-Files

2020-08-28 11:49:30.445222 INFO TId 3756 Core> Momo Node Saved paessler.mqtt
2020-08-28 11:49:30.460850 INFO TId 3756 Core> Momo Saved paessler.mqtt.3
2020-08-28 11:49:30.460850 INFO TId 3756 Core> Momo Saved paessler.mqtt.6

Mittlerweile gibt es sogar Sensoren, um die Funktion eines Brokers zu überprüfen und einzelne Werte abzufragen.

Aber da mein MQTT-Server durchaus "Messwerte" verarbeitet, die ich nicht nur mit Node-RED und anderen Tools aufzeichnen möchte, wünsche ich mir einen MQTT-Subscriber. Also mache ich ihn mir selbst.

PRTG als Subscriber

PRTG als Monitoring-Lösung ist bislang keine aktive Komponente in einem Prozess sondern steht quasi "daneben" und schaut zu. Für MQTT bedeutet das, dass PRTG einfach einen bestehenden Broker nutzt und die Daten anzapft.

Ich sehe PRTG hier eher in der Rolle des Subscribers, um sich Werte, die von einem Publisher im Broker hinterlegt werden, wieder auszulesen. Das klassische MQTT-Modell nutzt eigentlich kein "Polling", sondern der Subscriber hält die Verbindung offen, so dass der Broker auch eine Meldung zurück senden kann. Aber da Smartphones u.a. Geräte natürlich auch immer mal wieder "Strom sparen" ist es möglich, auch Daten immer wieder abzufragen. Ein passender Sensor in PRTG könnte die Daten also auch abfragen. Würde die MQTT-Funktion aber in der permanent aktiven Probe implementiert sein, dann könnte diese auch neue Werte direkt bekommen und in die PRTG-Datenbank einbauen. Quasi so, wie HTTP Push-Sensoren dies tun. Wenn es nur um die Erfassung von Daten gibt, könnte PRTG natürlich irgendwann auch selbst auf Port 1883/TCP oder 8883/TLS lauschen und einfach die "Publish"-Befehle annehmen und weiter leiten.

Da es beide Funktionen noch nicht gibt, wäre also wieder ein selbst entwickelter Sensor als Skript zu überlegen. Damit die PRTG-Probe nun nicht so viel durch den dauernden Aufruf von PowerShell-Skripten belastet wird, und ein Debugging in einer Konsole deutlich einfacher ist, bin ich erst mal den Weg über ein "Dauerskript" gegangen, welches die Werte selbst holt und per HTTPPush an PRTG meldet. Dieses Verfahren skaliert auch besser für viele MQTT Sensoren.

Allerdings müssen Sie beachten, dass MQTT-Broker die Daten nur dann speichern, wenn der Publisher dies auch wünscht. Auch das Wegbrechen eines Publishers wird vom Broker nur dann an die Subscriber gemeldet, wenn der Publisher einen "LastWill" hinterlegt hat.

Für meinen eigene Überlegungen bedeutet das gleich mehrere Besonderheiten.

  • Nach dem Start kann ich keine Daten abfragen.
    Wenn der Publisher keine "Retained Message" verwendet, dann muss ich auf neue Meldungen warten
  • Kein Zeitstempel
    Selbst wenn der Publisher eine "Retained Message" verwendet, so gibt es keinen Zeitstempel. Ich hätte dann zwar einen Messwert aber keine Information, wie akkurat er ist. Dann lasse ich lieber den Wert direkt zu PRTG senden und vertraue PRTG drauf, dass er ausbleibende Meldungen als Fehler meldet.
  • Nur ein Messwerte pro Push
    PRTG-Sensoren können mehrere Kanäle haben. Eine MQTT-Message liefert in der Regel erst mal nur ein Wert, auch wenn natürlich die Payload alles mögliche sein kann. Die meisten Publisher nutzen bei mehreren Werten aber lieber mehrere Chanels. In der ersten Version würde ich eine 1:1 Zuordnung annehmen. Später könnte ich ja mehrere Werte des gleichen Baums" in einem Sensor zusammen fassen. Man müsste dann nur Werte sammeln und nach einiger Zeit oder der Ankunft des letzten Werts senden. Das würde natürlich etwas Sensoren sparen.
  • LastWill würde ich vernachlässigen
    Wenn ein Publisher "offline" geht und einen LastWill hinterlegt hat, dann bekommen dies die Subscriber mit wie eine normale Message mit. Wenn Sie verarbeitet werden kann, dann wird sie wie eine normale Message behandelt und ausbleibende Werte werden von PRTG dann festgestellt und ggfls. alarmiert.
  • Content Conversion
    Nicht jeder wert, der von MQTT-Server kommt, kann von PRTG so 1:1 übernommen werden. Eine gewisse "Konvertierungsfunktion müsste in dem Skript enthalten sein.

Die Anforderungen sind also schon nicht gerade in einem PowerShell-Einzeiler zu schaffen.

PRTG als Publisher

Aber auch umgekehrt ist eine Anbindung denkbar. Wie wäre es, wenn PRTG seinen globalen Status oder den ausgewählter Sensoren per MQTT an einen Broker meldet? Es sind ja "auch nur Werte". So könnte ein Verbindung von unterschiedlichen Systemen auch in die Gegenrichtung erfolgen. Es gibt ja durchaus Informationen in PRTG wie z.B. der Status von Geräten, die sich ändern. So eine Änderung könne ja direkt an einen MQTT-Broker gesendet werden, so dass andere Subscriber diese Daten auswerten können.

Auch diese Anbindung ist natürlich auch ohne direkte Unterstützung on PRTG auch heute schon möglich. Über die PRTG-API kann ein regelmäßig gestartetes Skript die gewünschten Daten aus PRTG auslesen und überall hin senden. Dieses Skript könnte selbst als "PRTG-Sensor" laufen, welcher als Rückgabe eben nur einen Status meldet. So können Sie die Funktion dieses Exports direkt in PRTG selbst überwachen und PRTG quasi als "Scheduler" nutzen.

MQTT2PRTG-Simple

Was es nicht gibt, kann man auch selbst machen. Da ich auf der Seite Powershell und MQTT schon ein paar Vorarbeiten für die Nutzung von MQTT per PowerShell gemacht habe, ist es auch nicht sonderlich schwer, einen passenden Sensor oder ein passendes Skript zu erstellen. Ich habe dort aber auch beschrieben, dass man Werte von einem Broker nur erhält, wenn der Publisher diese dann gerade sendet oder die vorige Meldung als "Retained Message" gekennzeichnet hat.

Hinweis: Mit einem regelmäßig gestarteten Skript als Sensor können Sie nur MQTT-Daten abrufen, die vom Publisher als "Retained Message" gesendet wurden. Ansonsten müsste das Skript auf neue Daten "warten". Wir brauchen also einen dauernd laufenden Prozess um die Werte per MQTT zu sammeln. Das PowerShell-Script sollten Sie also als ""geplanten Task" einfach starten.

Diese Script ist sehr einfach aufgebaut und benötigt nur den PRTG-Server und MQTT-Server als Parameter. Es macht dann einen "SUBSCRIBE" auf alle Kanäle des MQTT-Servers  ("#") und leitet jede Meldung 1:1 unverändert an PRTG weiter.

Das bedeutet

  • Der MQTT-Kanalname ist zugleich die PRTG Push GUID
  • Der MQTT Value ist zugleich der Wert für PRTG
    d.h. es gibt keinen Sensor mit mehreren Kanälen und es gibt keine Wert-Konvertierung oder Umrechnung
  • Skaliert nur bedingt
    Sie sollten dieses Script nur in Verbindung mit einem "mäßig belasteten MQTT-Broker" einsetzen, da wirklich jede Meldung zu PRTG geht. PRTG verwirft diese natürlich aber mehrere unwichtige Messages pro Sekunde müssen nicht wirklich sein.

Dafür ist natürlich der Einsatz und die Konfiguration trivial.

Das Skript nutzt die Library "M2Mqtt.Net.dll", die ist per PowerShell und NUGET einfach installieren können
Install-Package M2Mqtt
Siehe dazu auch Powershell und MQTT

Achtung: Das Skript macht einen Subscribe "#" auf alle Kanäle und sendet diese auch alle an PRTG. Es ist also eher ein Proof of Concept für eine kleine Umgebung mit wenigen MQTT-Topics und bei dem jeder Topic auch ein Sensor in PRTG ist.

Sie müssen das Skript nur über einen Taskplaner automatisch aufrufen.

mqtt2prtg-simple.20181003.ps1

Da alle MQTT-Kanäle umgesetzt werden, müssen Sie keine Konfiguration anpassen, wenn der MQTT-Broker weitere Werte liefert, z.B. weil Sie ihr IoT-Projekt erweitert haben. Wenn Sie aber etwas mehr filtern und Zusammenfassen wollen, dann ist das nächste Skript vielleicht den Aufwand wert.

Ich nehme hier schon mal vorweg, dass mir die "Simple" Anbindung natürlich nicht gefällt und ich an einer erweiterten Funktion arbeite.

Weitere Links