PRTG Weitere Proben

Mein PRTG-Server überwacht mithilfe der "Local Probe" sich selbst, Netzwerkgeräte, andere Server und Dienste. Diese Seite beschreibt, welche Optionen sich durch den Einsatz einer RemoteProbe bieten und wo noch andere Alternativen sinnvoll sind.

Ausgangssituation

Normalerweise installieren Sie auf dem ersten System sowohl den PRTG-Server als auch die PRTG-Probe. Der Server ist für die Speicherung der Ergebnisse, die grafische Aufbereitung und die Konfiguration zuständig. Die Probe hingegen nutzt die hinterlegte Konfiguration und führt die verschiedenen Aktionen aus.

Für eine Basisfunktion reicht also genau eine Probe schon aus. Sie kann sowohl den Server selbst überwachen aber per SNMP, WMI, SSH etc. auch entfernte Server mit überwachen. Zudem kann diese Probe natürlich auch die unterschiedlichen aktiven Netzwerktests (PING, HTTP-Connect etc.) gegen entfernte Systeme ausführen. Dennoch gibt es Gründe weitere Probes zu installieren.

An der Lizenz kann es nicht liegen, denn PRTG lizenziert sich nach der Anzahl der Sensoren aber nicht der Probes. Sie können also sehr viele Probes ohne weitere Kosten für PRTG installieren. Allerdings ist eine Probe natürlich ein "PC", der andere Kosten verursacht. Wir müssen also verstehen, was eine Probe ist und wo sie sinnvoll eingesetzt werden kann.

Was ist eine Probe genau?

Technisch gesehen ist eine Probe nichts anderes als ein kleiner Windows Computer, auf dem Sie als lokaler Administrator die PRTG-Probe-Software installieren. Durch die Installation landet auf dem System ein Windows Dienst, welcher sich mit dem zentralen PRTG-Server über einen konfigurierbaren Port (Default 23560) verbindet um von dort die Konfiguration zu beziehen. Die Probe führt dann die vorgegebenen Prüfungen aus und meldet die Daten über den Kanal an den PRTG-Server. Für die Probe gilt:

  • Auf der Probe liegen normalerweise keine Datenbanken
    d.h. die Probe braucht nicht viel Platz
  • Die Probe kann alle Tests ausführen, die auch die Probe "unter" dem PRTG-Server ausführen kann
    Bedenken Sie dabei allerdings, dass sie Custom-EXE-Skripte manuell auf die Probe kopieren müssen
  • Die Probe kann puffern und eigenständig prüfen
    Wenn die Verbindung zwischen Probe und PRTG-Server unterbrochen ist, dann führt die Probe weiterhin die konfigurierten Prüfungen aus und speichert die gesammelten Ergebnisse solange zwischen, bis der PRTG-Server wieder erreichbar ist

Damit wird schon klar, in welchen Fällen zusätzliche PRTG-Probes ratsam sind. Dabei sind die Anforderungen an eine Probe sehr viel geringer als die Anforderungen an den PRTG-Server, der neben der Probe ja die komplette PRTG-Verwaltungsinstanz samt Datenbanken betreibt. Für eine Probe kommen Sie mit einem handelsüblichen PC und aktuellem Windows. Selbst mit 2 GB RAM eben sich die meisten Probes mit den PRTG-Standard-Sensoren zufrieden.

Das System muss auch nicht Windows Enterprise sein. Allerdings sollten Sie die Probe zumindest mit Windows Updates versehen und vieles ist einfacher, wenn das System Mitglied in ihrer Domäne ist.

Remote Probes zur Skalierung

Sie können schnelle Server als PRTG-System einsetzen aber die ein oder anderen Sensoren sind schon CPU- und Ressourcenintensiv. Dazu zählen insbesondere Skripte, die jedes mal eine PowerShell, VBScript o.ä. starten und auch WMI-Abfragen auf entfernte Server (Eventlog, Performance Counter) skalieren nicht sehr gut. Anstatt nun den einen PRTG-Server also immer leistungsfähiger zu machen, können Sie die Last auf mehrere Probes verteilen. Quasi als "Scale out"-Ansatz können mehrere Server parallel eigenen Checks übernehmen und nur die Ergebnisse an den PRTG-Server senden. Das kann soweit gehen, dass die "Local Probe" nur noch den PRTG-Server selbst überwacht und alle aktiven Tests durch Probes erfolgen.

Probe auf einem Server

Ich würde nun aber nicht soweit gehen, dass ich auf jedem Server auch eine Probe installieren würde. Bei einem Updates des PRTG-Servers werden auch die Probes aktualisiert und sehr viele weitere Instanzen sind auch nur in besonderen Fällen interessant. Allerdings kann es natürlich schon hilfreich sein, auf einem sehr aktiven Server mit sehr vielen Sensoren eine eigene lokale Probe zu spendieren.

Das ist speziell interessant, wenn Sie viele Performance Counter oder WMI-Quellen anzapfen oder mit eigenen Skripten längere Auswertungen fahren. Ich habe selbst einige Skripte auf Exchange Auswertung und Prüfungen veröffentlich, die man durchaus auf dem Exchange Server starten kann. Report-Skripte laufen nicht jede Minute sondern vielleicht nur einmal am Tag. Wenn es z.B. Abhängigkeiten zu Management-Modulen wie die Exchange PowerShell gibt, dann ist es oft einfacher die Auswertung direkt auf dem Server mit den lokalen Commandlets zu machen als auf dem PRTG-Server auch noch die verschiedenen Commandlets für alle Produkte anderer Server zu installieren.

Ein weiterer Aspekt ist vielleicht die Sicherheit. Die lokale Probe kann als "Local System" auf dem Server selbst schon ziemlich viel machen aber wenig auf anderen Servern. Eine Probe auf einem anderen Server muss immer mit entsprechenden Credentials ausgeführt werden.

Zuletzt nutzt ich PRTG manchmal auch als "Taskplaner", d.h. ein Custom-EXE Sensor wertet nicht nur Werte aus, sondern ist auch selbst aktiv. So hab eich einen "LogFileDeleter"-Sensor, bei dem ich über eine CSV-Datei die Pfade, Dateinamensmuster, Mindest- und Maximalalter und Ordnergröße vorgebe und das Skript nicht nur ältere Dateien löscht sondern an PRTG auch meldet, wenn Ordner zu schnell zu groß werden etc. So lassen sich IIS-Logfiles nicht nur bereinigen sondern auch überwachen.

Solche Auswertungen, die größere Datenmengen betreffen, muss man nicht aus der Ferne von einem anderen Probe-System aus machen.

Probe in einem anderen Standort

Wenn ihre Netzwerk sich über mehrere Standorte mit WAN-Verbindungen erstreckt, dann ist es sicher eine gute Idee auch in anderen Standorten dezentral solche Probe-Systeme aufzubauen. Gerade wenn der Standort nicht nur aus einem Router und Switch besteht, dann ist es sinnvoller die Checks vor Ort gegen die lokalen Ressourcen zu machen und nur die Ergebnisse zum zentralen PRTG-Server zu melden.

Die Probe bezieht von der zentralen Instanz die Konfiguration und meldet dort auch ihre Ergebnisse zurück. Wenn die Verbindung zwischen Probe und Server unterbrochen ist, führt die Probe dennoch weiter ihre Checks aus und sammelt die Daten, so dass Sie später gesendet werden. So können Sie nach der Wiederherstellung der Verbindung auch die Ergebnisse von Checks einsehen, die während des WAN-Ausfalls aufgelaufen sind. Würde ihr PRTG-Server selbst über das WAN die entfernten Dienste "prüfen", dann hätten Sie mangels Erreichbarkeit keine Daten und Fehlalarme.

 Ein weiterer Fall ist die Möglichkeit zwischen zwei Probes auch QoS-Tests zu fahren. Sie können also die Probe in der Zentrale anweisen, bestimmte Pakete an die anderen Probe zu senden und zu messen. Das geht als "Roundtrip-test" auch bidirektional. Im Hinblick auf Office 365 könnten sie aus dem Remote Standort über HTTP-Checks etc. auch die Erreichbarkeit von anderen Diensten und deren Performance überwachen.

Probe im Internet oder Azure

Ein Sonderfall ist die Verteilung von Proben im Internet. PRTG enthält selbst schon Sensoren, die "von draußen" messen können. Sie können z.B. die externe Erreichbarkeit einer Webseite durch eine Art Probe in der Cloud prüfen lassen. Paessler betreibt dazu solche "Helfer", die sie direkt von ihrer lokalen PRTG-Installation ansteuern können. Ihre lokale Probe bittet quasi den PRTG Cloud-Service um einen Test

Das funktioniert natürlich nur mit den vordefinierten Sensoren. Es hindert sie aber niemand daran einfach eine eigene PRTG-RemoteProbe einzubauen. Sie brauchen einfach nur eine Windows-Instanz, auf der sie eigene Software installieren können. Das kann eine Azure-VM sein oder auch ein kleiner PC, der irgendwo in einem Home-Office-Netzwerk steht. Es könnte sogar eine Probe auf einem Arbeitsrechner eines Mitarbeiters zuhause oder unterwegs sein, wobei der eher nicht 24h aktiv und "connected" ist und die Auswertung der Counter indirekt auch Rückschlüsse auf das Arbeitsverhalten zulassen könnte. Hier muss man vorsichtig sein.

Eine VM in Azure oder einem anderen Cloud-Anbieter ist aber eine gute Möglichkeit selbst eigene und umfangreiche Tests von diesem Standort gegen die eigene Umgebung oder andere Dienstleister zu fahren. Das gilt umso mehr, wenn Sie viele Server z.B. in Azure hosten und diese "vor Ort" überwachen wollen.

Sie benötigen für den Betrieb einfach nur eine TCP-Verbindung auf von der Probe auf den PRTG-Server (Default 23560/TCP, änderbar). Die Verbindung ist wohl verschlüsselt und über einen "Key" erfolgt die Authentifizierung am PRTG-Server.

Miniprobe (Linux/Android)

Es muss aber nicht immer ein Windows System sein, auf dem eine PRTG-Probe läuft. Paessler hat auch ein Python-Script entwickelt, mit der eine Art "Probe" auf Linux-Systemen gestartet werden kann. Paessler weißt aber selbst darauf hin, dass diese Probe im Funktionsumfang eingeschränkt ist und viele Informationen von Linux auch remote per SNMP oder SSH ermittelt werden können.

HTTP-Push-Probe

Ein HTTP-Push-Sensor ist eigentlich eine Probe, die Paessler bereitstellt, sondern eine API, mit der man Daten von beliebigen Programmen per HTTP an einen PRTG-Server einliefern kann. Als Betreiber muss man also selbst den Code zur Ermittlung der Daten und dem Versand zu PRTG schreiben und auch noch in den gewünschten Intervallen aufrufen (Taskplaner, AT-Job, cron-Job).

PRTG nimmt einfach nur die Daten entgegen, was kaum Ressourcen kostet (-> Skalierbarkeit). Welche System die Daten allerdings sendet, ist für PRTG damit auch irrelevant. Dies eröffnet Wege diese Daten von quasi jedem System zu senden, welche HTTP spricht. Dazu zählen auch Kleinstrechner wie der ESP8266, die Arduino Plattform oder RaspberryPi und Co. Sie sind auch nicht auf bestimmte Geräte und Dienste beschränkt, Wenn Sie selbst eine Software schreiben, können Sie selbst auch interne Zahlen per PRTG bereitstellen

PRTG Server als Probe

Nun wissen sie sicher auch, dass es PRTG als "Kostenfreie" Version gibt, die bis zu 100 Sensoren betreiben kann. Zudem gibt es eine HTTP-API, mit der man die Werte und Ergebnisse eines Sensors mit einem Programm abfragen kann. Es ist also technisch durchaus möglich, Daten von einem anderen PRTG-Server (nicht Probe) abzurufen und die Daten in die eigene Umgebung zu übernehmen.

Dieses Verfahren kann durchaus interessant sein, wenn Sie als Dienstleister eine lokale PRTG-Instanz betreiben und bei Kunden eigene PRTG-Server laufen. Ich kann als Dienstleiter mir damit ausgewählte Sensoren in meine Umgebung quasi "kopieren". Meine "große" PRTG-Instanz kommt natürlich nicht mehr mit den 100 Sensoren der "Freeware" aus und so ist der Sensor lizenziert, selbst wenn der Kunde nur eine kleine PRTG-Installation mit weniger als 100 Sensoren betreibt. Allerdings habe ich die Erfahrung gemacht, dass die meisten Installationen von PRTG über kurz oder lang nicht mehr mit den 100 Sensoren auskommen und dann auch lizenziert werden.

Zwischenstand

PRTG ist eine leistungsfähige Plattform zur Überwachung, deren zentraler Server samt Probe durch weitere Messstellen im gleichen LAN, auf weiteren Servern, in anderen Standorten oder der Cloud , eigenen Skripten und nahezu jedem programmierbaren Gerät mit HTTP-Zugriff erweitert werden kann. Es gibt nicht die eine passende Variante. Für jede Situation gibt es sicher mehrere Lösungswege.

Weitere Links