IP-Symcon und PRTG Network Monitor – ein gar nicht so schlechtes Duo

PRTG Beispiel: Geräteübersicht (Ausschnitt)

Ich setze den Paessler PRTG Network Monitor nun seit 2009 bei mir im LAN (als kostenpflichtig lizensierte Version) ein. Die Free-Version (bis zu 30 Sensoren) reicht aber auch ne ganze Weile hin.

Warum mach ich das? Vielleicht weil ich eine Logging-Macke habe. Mich interessiert aber auch, was in meinem LAN so alles passiert. Hier aber weniger, was aktuell passiert (manchmal schon – meistens dann, wenn es brennt => also irgendwas nicht läuft) – viel mehr sind es die Langzeit-Entwicklungen. Hier habe ich schon einige interessante Entwicklungen herausgefunden, die ohne ein Langzeitmonitoring nicht oder nicht ohne Weiteres erkennbar gewesen wären.

PRTG Beispiel: Alarm-Trigger

Ein plastisches Beispiel ist z.B. das Monitoring der Antwortzeiten meiner eigenen Webserver. Hierüber habe ich z.B. Mitte 2012 entdecken können, dass nach einem Update eine Webseite deutlich langsamer wurde. Und zwar dauerhaft. Hätte ich ohne Monitoring wahrscheinlich erst nach Monaten gemerkt. Das Problem hatte ich dann durch Einsatz von Caching-Mechanismen so gut gelöst, dass die Antwortzeiten nach der „Optimierung“ besser waren als vor dem Update. Hat aber auch Nerven gekostet.

PRTG als Watchdog für IP-Symcon Dienst

Sehr gerne nutze ich die Watchdog-Funktion von PRTG für Windows-Services. Man kann hier nicht nur einen Windows-Service monitoren, sondern auch einen Neustart konfigurieren, wenn sich der Service tot stellt. Das funktioniert äusserst zuverlässig und stabil, so dass ich damit den IP-Symcon Dienst überwache und im Zweifel automatisch den Defibrilator starten lasse, sollte dessen Puls gegen Null tendieren.

Ein anderes Beispiel ist die ständige Überwachung der IPS-Settings. Ich lasse hier die Aktualisierungsintervalle monitoren. PRTG soll Alarm schlagen, wenn das Aktualisierungsintervall einen definierten Zeitraum überschritten hat. Weil dann ist Handarbeit angesagt: wird die Settings nicht mehr geschrieben, gehen Konfigurationsänderungen in IP-Symcon verloren.

Die Funktionen sind so vielfältig, dass eine Beleuchtung hier jeglichen Rahmen sprengen würde. Aber was mich immer wieder beeindruckt, ist die Web-Oberfläche: extrem viel und dicht gepackte Funktionen, dennoch sehr übersichtlich und intuitiv.

Aber was soll das mit IP-Symcon zu tun haben?

IP-Symcon ist fast die eierlegende Wollmilchsau und kann ne ganze Menge – zum Beispiel ganze Häuser steuern. Monitoren auch. Grafisch aufbereiten auch. Warum also PRTG?

PRTG ist von Hause aus auf Monitoring von IT-Systemen ausgelegt. Als ich mit PRTG anfing, war das noch sehr netzwerklastig. Über die Jahre haben sich aber immer mehr betriebssystem-Nahe Sensoren und Schnittstellen bei PRTG eingenistet, so dass man zum Beispiel Dienste, Virtuelle Maschinen, Dateien u.v.m nach verschiedensten Kriterien überwachen lassen kann. Was PRTG nicht so gut kann (zumindest aus Sicht eines Home-Automatisierers): auf Events gezielt nach Uservorgaben reagieren. OK, PRTG kann ne Mail nach individuell eingestellten Schwellwerten versanden oder einen Dienst neu starten… es kann aber keine Sensoren/Aktoren im Kontext der Home-Automation ansprechen.

Beispiel: IPS RAM Bedarf Langzeitmonitoring 365 Tage

Insider werden hier sofort einwerfen: das kann doch IP-Symcon viel besser. Stimmt, das kann es. Und zwar sehr gut. Dafür kann es nicht so gut monitoren bzw. hat nicht die ausgereiften Sensoren wie PRTG mit an Bord. Klar, man kann ne Menge mit PHP bauen – ist aber auch hier Einschränkungen unterworfen, die für PRTG nicht gelten müssen. PHP nützt mir zum Beispiel wenig, wenn ein entferntes Device überwacht werden soll, auf dessen System-Eingeweide nicht remote zugegriffen werden kann. Kann ich keine lokale PHP-Instanz auf diesem Device ansprechen, habe ich verloren.

PRTG ist eben ein sehr ausgereiftes, professionelles Monitoring-System, welches innerhalb von IP-Symcon nicht ohne Weiteres nachgebaut werden kann.

Was liegt also näher, als IP-Symcon und PRTG zu koppeln?

Die Gründe dafür können vielfältig sein:

• warum in PRTG erhobene und geloggte Daten in IP-Symcon nochmal erheben und speichern?
• warum nicht PRTG als Watchdog für IP-Symcon nutzen?
• warum nicht PRTG kritische Zustände erkennen lassen und die Reaktion darauf durch IP-Symcon erfolgen lassen?

Ein Beispiel der Kopplung PRTG => IP-Symcon

PRTG-Sensoren (nicht vollständig)

Ok, die Kommunikation läuft nur in eine Richtung: PRTG => IP-Symcon. Dazu gibt es ein recht komfortables Script, welches aus der Feder von Wennäh entstammt, das ich vor kurzem etwas angepasst habe.

Das Problem war nämlich, dass das Script auf die richtige Sensoren-Reihenfolge in den übergebenen Daten angewiesen war. Wenn man aber den Strukturbaum in PRTG ändert, neue Sensoren hinzufügt oder alte löscht – ändert sich sehr wahrscheinlich die Position der gewünschten Daten im Übergabe-Array. Im schlimmsten Fall merkt man es nicht (mir auch schon passiert). Daher habe ich das Script so umgebaut,dass die übergebenen Sensorendaten anhand des Sensoren-Namens erkannt und weiterverarbeitet werden. Solange man dann in PRTG den Sensorennamen nicht ändert, geht hier nichts mehr schief.

 wie funktioniert das Script nun?

…. und wie passt man es an die eigene Umgebung an? Zugegeben: ich hab auch schon komfortablere Scripte zusammen kopiert. Aber: mal verliert man, mal gewinnen die Anderen!

PRTG-Script: die wesentlichen Details

Zur Sache:

Im Kopf des Scripts sind die üblichen User-Parameter anzugeben. Die entscheidenden Änderungen befinden sich weiter unten im Script: 

Im Bild ist rot gerahmt der Code zum auslesen , umrechnen und schreiben eines Wertes. Die farblich hinterlegten Code-Stellen haben folgende Bedeutung:

• gelb: Name des PRTG-Sensors (entspricht 1:1 dem Namen des Sensors in PRTG)
• rosa: Wert, der aus dem Array ausgelesen werden soll.
• dunkelgelb: ggf. Umrechnungsfaktor mit einbauen (z.B. zur Umrechnung der Filegröße von Byte in MByte)
• grün: ID der IPS-Variable, in die der von PRTG gelieferte Wert geschrieben werden soll

Im Script sind 5 Beispiel-Blöcke für das Auslesen undSchreiben der PRTG-Werte vorhanden. Diese muss man natürlich ans eigene System anpassen (ändern, löschen, kopieren).

Einen zyklischen Timer unter dem Script anlegen (meiner löst alle 2 Minuten aus) und los gehts!

Troubleshooting

Ausgabe des PRTG-Datenarrays in der IPS-Konsole (zu Kontrollzwecken)

wer sich im Datendschungel verirrt hat, kann auch das übergebene Datenarray am Bildschirm ausgeben lassen. Das lässt sich leicht durch 

realisieren (die Zeile einfach am Ende des Scripts einfügen und Script manuell starten). Das Ergebnis sieht dann so ähnlich aus wie im Bild rechts. Hier kann man auch schön die Zuordnung zu den oben im Code markierten Parametern erkennen (ich habe diese mal mit den selben Farben wie oben markiert)