PRTG Cascade

Die klassische PRTG Installation besteht aus einem Server samt lokaler Probe und optional weiterer Probes. Hier beschreibe ich, wie ich mit einer PRTG-Serverinstallation eine andere eigenständige PRTG-Serverinstallation überwachen kann, z.B. wenn ein Kunde selbst PRTG einsetzt und ich als Dienstleister eine Teilmenge der Daten bei mir haben möchte oder eine zweite PRTG-Installation als "Langzeitarchiv" dienen soll.

Mit PRTG Desktop gibt es eine Client-Applikation, mit der sie mehrere Server einbinden können. Seit Mai 2020 gibt es auch ein ITOps Board, um mehrere PRTG-Server Instanzen zu überwachen. https://www.de.paessler.com/prtg-enterprise-monitor/itops-board. Damit wird dieses Skript zum Teil obsolet

Überlegungen

Die normale Installation eines PRTG-Systems besteht aus einem Management Server oder Management Cluster, auch CORE genannt, der eine oder mehrere Probe-Geräte verwaltet, die ihrerseits dann die aktiven Tests ausführen. Die kleinste PRTG Installation besteht aus einem Single Server, auf dem der PRTG-Management Dienst und eine Probe installiert ist. Die größte Umgebung ist ein Cluster aus zwei Management Systemen, die viele Proben verwalten. Eine weitere Hierarchie ist aber nicht möglich. Mich stört dabei aber:

  • Kein Master / Slave für Managed Services
    Schade ist, dass eine Probe nicht mehrere Managementsysteme bedienen kann oder man die Managementsysteme nicht kaskadieren kann. Ich installiere z.B. gerne einen PRTG-Server beim Kunden für die lokale Überwachung. Natürlich kann ich, sofern der Server über Internet oder Fernwartung erreichbar ist, diese Instanz auch in meine PRTG-Enterprise Console addieren oder per Browser ansprechen. Aber ich muss aktiv werden. Ich hätte aber auch gerne diese Instanz als "Unterinstanz" in meiner zentralen Plattform.
  • Keine Langzeitdaten
    Zudem ist die Haltedauer von Daten für alle Sensoren einer PRTG-Installation gleich lange und per Default auf 365 Tage eingestellt. Langzeittrends über mehrere Jahre sind leider so auch nicht möglich. Das ist nicht für alle Sensoren wichtig aber für einige Sensoren wären längere aber auch kürzere Vorhaltezeiten schon interessant. Speziell längere Speicherzeiten vermisse ich schon z.B. beim Postfachwachstum etc.

Das geht aktuell (Version 18) wohl nicht. PRTG hat aber eine offene API PRTG API und so kann man das doch machen.

Es gibt sogar eine "passende" Lizenz für die Anforderung. Wer eine "PRTG Corporate Country"-Lizenz kauft, darf "unlimited sensors and multiple Core Server installations within one corporation in one country" durchführen. Da wäre es doch interessant wen eine Hauptinstallation die einzelnen Core-Installationen überwacht.

Dieser Sensor ist aber keine Aufforderung nun viele 100 Sensor "Freeware"- Installationen in ihrer Firma zu verteilen und mit einer Hauptinstanz nur den Status der Unterinstanzen zu sammeln. So teuer ist PRTG nun auch nicht und sie verschenken sehr viel Potential.

Natürlich könnte ich einfach eine weitere Probe auf einem Server des Kunden installieren, die mit meiner zentralen PRTG-Instanz verbunden ist. So könnte ich dann einfach ein paralleles Monitoring aufbauen. Das ist aber doppelte Arbeit und ich sehe nie, was der Kunde sieht.

Die folgenden Beispiele nutzen gültige URLs eine PRTG Demo-Installation von Paessler. Sie sollten diese Beispiele also einfach selbst nachvollziehen können.

Wenn Sie in ihrem produktiven System so eine Abfrage umsetzen, dann sollten sie auf jeden Fall auf HTTPS achten, da Anmeldedaten ansonsten unverschlüsselt als Teil des Datenstroms übertragen werden. Zudem sollten Sie einen gensonderten Benutzer anlegen, der nur ReadOnly-Rechte hat.

Wenn Sie mit lokalen PRTG-Konten arbeiten, dann können Sie die API-Aufrufe auch mit dem PassHash nutzen und so das Kennwort besser absichern. Leider haben AD-Konten keinen alternativen Passhash

Sensoren einer PRTG-Installation auslesen

Daher finde ich den Ansatz interessanter, per HTTP-API die Daten dynamisch zu ermitteln. Natürlich wäre die Wunschvorstellung, dass die "Unterinstanz" als Gruppe in der Hauptinstanz erscheint und darunter alle Daten der Unterinstanz-Probes, Gruppen und Sensoren erscheinen. Technisch geht das sicher aber die perfekte Lösung überlasse ich besser dem Hersteller. Vielleicht gibt es da schon Überlegungen zu einer Kaskadierung von PRTG-Management-Systemen. Allerdings möchte ich schon mehrere PRTG-Instanzen in einer Überinstanz zusammenfassen. Die HTTP-API ist recht ausführlich dokumentiert und relativ einfach anzusprechen:

Alle Daten sind als Parameter in der GET-URL hinterlegt. Daher sollte der Abruf über Internet natürlich nur über HTTPS erfolgen. Hier ein paar Beispiele eines Demoservers von Paessler.

Interessant ist auch ein Blick auf das Programmverzeichnis C:\Program Files (x86)\PRTG Network Monitor\website\api um andere URLs zu finden

Werte eines Sensor auslesen

Ich will natürlich nicht alle Sensoren einer PRTG Instanz kopieren sondern nur ausgewählte Daten oder Channels. Die Sensorübersicht wäre erst einmal nur hilfreich um die Sensoren auszuwählen. Einen Sensor kann ich wie folgt abrufen.

https://prtg.paessler.com/api/getsensordetails.xml?Username=demo&password=demodemo&id=2598

Invoke-WebRequest "https://prtg.paessler.com/api/getsensordetails.xml?Username=demo&password=demodemo&id=2598"


StatusCode        : 200
StatusDescription : OK
Content           : <?xml version="1.0" encoding="UTF-8"?>
                    <sensordata>
                        <prtg-version>18.2.40.1658</prtg-version>
                        <name>
                                <![CDATA[Shop]]>
                        </name>
                        <sensortype>
                                <![CDATA[httpadvanced]]>
                        </sensortype>
                        <in...
RawContent        : HTTP/1.1 200 OK
                    Connection: close
                    X-Content-Type-Options: nosniff
                    X-XSS-Protection: 1; mode=block
                    Content-Disposition: attachment; filename=getsensordetails.xml
                    Pragma: public
                    Content-Length: 13...
Forms             : {}
Headers           : {[Connection, close], [X-Content-Type-Options, nosniff],
                    [X-XSS-Protection, 1; mode=block], [Content-Disposition,
                    attachment; filename=getsensordetails.xml]...}
Images            : {}
InputFields       : {}
Links             : {}
ParsedHtml        : mshtml.HTMLDocumentClass
RawContentLength  : 1364

Die zurück übergebene XML-Struktur sieht wie folgt aus:

Wenn Sie mit "Invoke-RestMethod" arbeiten, dann ist die XML-Struktur auch direkt geparsed und Sie können auf einzelne Werte zugreifen.

(Invoke-Restmethod "https://prtg.paessler.com/api/getsensordetails.xml?Username=demo&password=demodemo&id=2598").sensordata.lastvalue

#cdata-section
--------------
846 msec

Die ID (hier 2598) ist die eindeutige SensorID. Zurück kommt eine XML mit den Stammdaten dieses Sensors, Der letzte Wert steht z.B. in <lastvalue>. Auch der komplette Pfad ist enthalten, z.B. Sensortyp, Probename, Parentgroupname, parentDevicename. Aber die einzelnen Werte der Channels bekommt man so nicht. Primär also nur der "Status".

(invoke-restmethod "https://prtg.paessler.com/api/table.xml?content=channels&Username=demo&password=demodemo&columns=name,lastvalue_&id=2598").channels.item

name               lastvalue   lastvalue_raw
----               ---------   -------------
Bytes received     15,087 Byte 15087.0000
Download Bandwidth 151 Kbit/s  151.0000
Downtime
Loading time       801 msec    801.0000
Time to first Byte 33 msec     33.0000

Die XML-Struktur eines anderen Sensors zeigt es auch entsprechend an

 

Ein Custom-Sensor muss also neben gültigen Zugangsdaten nur die Sensor-ID wissen, um einen Sensor komplett in eine andere PRTG-Instanz kopieren zu können. Über den Inhalt des Felds "LastValue" kann man sogar die Beschreibung des Channel erhalten.

Auf dem Dateisystem des PRTG Core gibt es noch weitere Dateien wie percentile.xml, historicdata_totals.xml, historicdata.xml, gettreenodestats.xml und search.xml, die ich aber nicht weiter analysiert habe.

Systemstatus

Neben all den einzelnen Sensoren und Channels interessiert mich natürlich der allgemeine Systemstatur. Über die Statusabfrage kann man schnell ermitteln, wie viele Messages und Alarme die PRTG Instanz hat, welche Version vorliegt und ob es ein Update gibt. Auch das geht per PowerShell über die API sehr einfach.

(Invoke-RestMethod "https://prtg.paessler.com/api/getstatus.xml?Username=demo&password=demodemo").status

NewMessages              : 0
NewAlarms                : 0
Alarms                   :
AckAlarms                :
NewToDos                 :
Clock                    : 4/28/2018 12:38:56 PM
ActivationStatusMessage  : (Tag activationstatusalert unknown)
BackgroundTasks          : 0
CorrelationTasks         : 0
AutoDiscoTasks           : 0
Version                  : 18.2.40.1658
PRTGUpdateAvailable      : no
IsAdminUser              : false
IsCluster                :
ReadOnlyUser             : true
ReadOnlyAllowAcknowledge :
ReadOnlyPwChange         :  display:none!important;

In der XML steht auch nicht mehr drin. Dieses Wissen kann auch in einem eigenen Custom Sensor ermittelt werden.

Interessant: Die "Version" der PRTG Demo-Instanz ist fast immer etwas neuer als meine lokale Instanz. Anscheinend aktualisiert Paessler die Demo-Umgebung sehr zeitnah und noch ehe die neue Version als Download bereitgestellt wird.

Cascade Sensor Status

Über die API kann ich von einer anderen PRTG-Instanz eigentlich alle Werte auslesen und über die gleiche API gegen meinen eigenen PRTG-Server kann ich auch Sensoren anlegen. Da wäre es doch genial, wenn eine Software mit GUI dem Admin die Möglichkeiten gibt, Sensoren einer Quellinstallation auszuwählen und im Ziel mit einem passenden Sensor die Verbindung herzustellen. Über die PRTG-API wäre all das möglich.

Dann würde man vielleicht auch überlegen, ob man den Scope auf einzelne "Channels" setzt und diese auf eigene interne Sensoren per HTTP-Push mappt. Nicht immer ist ja eine 1:1 Umsetzung aller Channels eines Kunden auf eine eigene Umgebung erforderlich.

Ich habe mir aber erst einmal überlegt, den einfachen Weg zu gehen und zwei PowerShell-Skripte als CustomXML-Sensor zu bauen.

  • Status Sensor
    Dieser Sensor liest einfach den globalen Status einer PRTG-Installation aus und meldet ihn an die aufrufende PRTG-Instanz. So können Sie als Dienstleister schnell erkennen, ob es auf einer PRTG-Installation bei einem Kunden Probleme gibt und dann ja dort hin springen und nachschauen. Der Sensor prüft auch, ob ein Update erforderlich ist. Zudem konvertiere ich die PRTG-Version in einen Integer und meldet diesen als "Delta"-Wert samt Notification. Sie können sich also Benachrichten lassen, wenn sich die Version ändert. Der Version wird aber per Default nicht in der Grafik angezeigt.
  • Sensor-Sensor
    Dieses Skript nimmt eine Sensor-ID der abzufragenden PRTG-Installation um die Daten zu erhalten und lokal im Sensor zu hinterlegen. Es ist dann eine 1:1 Kopie des Kundensensors ohne aber die aktiven Tests erneut ausführen zu müssen.

Diese Sensoren sind auch sehr einfach zu schreiben, da es ja nicht viel mehr ist als die Parameter auf der Kommandozeile (PRTG-URL, Username, Kennwort und ggfls. Sensornummer) anzunehmen, den Invoke-RestMethod zu machen und die Antwort in ein PRTG-XML-taugliches Format zurück zu liefern

Bei sehr vielen Sensoren sollten Sie überlegen die Anmeldedaten könnten Sie diese als Defaults im Code anpassen, was natürlich nicht so sicher ist. Es sollte aber sowieso nur ein "ReadOnly"-Konto auf der Gegenseite sein. Wer mehrere PRTG-Installationen abrufen will, kann ja den Dateinamen pro Ziel anpassen. Hier erst mal die beiden Skripte

prtg-cascadestatus.ps1
Holt den Status der entfernten PRTG-Instanz, den Sie sonst oben rechts sehen

Die Auswertung und Anzeige des Status ist ein relativ einfacher und robuster Sensor

 

Cascade Sensor

Der zweite Sensor bei meiner Kaskade nutzt die Möglichkeit den letzten Wert eines PRTG-Sensors per HTTP-API abzurufen und wieder in PRTG einzufüllen. Ich möchte damit natürlich nicht den "Factory  Sensor" von PRTG ersetzen, der mehrere Werte unterschiedlicher Sensoren in einem Bild vereint

Dieser CustomXML-Sensor kann Daten eines Sensors einer PRTG-Instanz in eine andere PRTG-Instanz kopieren. Er liest dazu den letzten Wert des entfernten PRTG-Sensors als XML-Datei und übernimmt alle Channels samt Beschreibung. Bei meinen Tests hat das erstaunlich gut geklappt und mir so ermöglicht die Daten von anderen PRTG-Installationen, z.B. von Kunden, in meine PRTG-Installation zuüberführen.

prtg-cascade.ps1
Holt die Werte des mit "sensorid" übergebenen Sensors aus der entfernten Installation

Ich kann aber nicht 100% sicherstellen, dass alle Sonderfälle berücksichtigt sind. Zudem liest er eben immer nur den "letzten" Wert ein. leider liefert die URL unter "table.xml" auch nur die Werte und die Einheit aber keine weiteren Daten. Ich prüfe z.B. ob ein "."-Trennzeichen einen Hinweis auf einen Float liefert. Zur Perfektion müsste ich schon zur jedem Channel auch die Definition einlesen und diese genau so im Ziel einbringen. Für historische Betrachtungen wäre es natürlich besser, wenn er die Werte aus dem 365-Graph lesen und übergeben würde.

Cascade Sensor Version 2 (Planung)

So ganz habe ich den Plan aber noch nicht aufgegeben, die Konfiguration z.B. in einer einer Datei zu hinterlegen und über einen einzelnen Sensor die Daten "en block" auszulesen und dann per HTTP-Push an die PRTG-Installation einzuspeisen. Das wäre dann ein PowerShell-Skript und mit einer kleinen GUI könnte man sogar die Konfiguration erleichtern. Schade, dass PRTG unbekannte HTTP-Push-Einlieferungen nicht meldet und mit anbietet einen passenden Sensor direkt anzulegen. Bei neuen Probes ist das ja schon möglich.

In der Konfiguration würde ich dann als XML oder CSV-Datei einfach die URLs, SensorID und Channels zum abrufen eintragen und in welchen Zielsensor diese Daten per HTTP-Push übertragen werden. So müsste dann nicht PRTG ganz viele prtg-cascade-Instanzen starten sondern ein PowerShell-Aufruf sorg dafür, dass zuerst alle Daten eingesammelt und dann in die Ziele geschrieben werden.

Vielleicht wird das ganze aber auch ein Projekt für einen Ferienjobber, Praktikanten o.ä. Ich denke ich komme erst mal so schnell hier nicht dazu und belasse es bei den "Version 1"-Skripts.

Weitere Links