PRTG -Missing Features

Vorneweg: Ich finde PRTG einfach genial, also sowohl "einfach" zu installieren und zu nutzen also auch genial, weil viele Sensoren meine alltäglichen Probleme lösen und ich fehlende Funktionen einfach über einen Custom Sensor nachrüsten oder die API programmieren kann. Insofern ist diese Liste hier eher eine Merkliste für mich, was ich mir wünschen würde. Ich weiß nicht, ob und wann Paessler hier einspringt. Ein paar meiner Wünsche wurden im Laufe der Jahre aber schon erfüllt. Insofern bin ich gespannt, wann wieder mal Bescherung ist.

Wunsch Status

Probe Skripte Replikation

Die Entwicklung von eigenen Skripte ist sehr einfach. Aber da nicht der Core sondern die Probe das Skript ausführt, muss das Script auf die Probe. Im LAN geht das ja noch einfach aber wenn Sie mal eine Probe in der Cloud oder in einem entfernten Netzwerk installiert haben, ist das kniffliger. Die Probe kommuniziert ja mit dem Core über genau einen Port. In Gegenrichtung muss gar keine Kommunikation offen sein.
Ich würde mir hier wünschen, dass die Probe über die Schnittstelle, über die sie heute schon ihre Konfiguration bezieht und sich sogar selbst Updaten kann, auch das EXE und EXEXML-Verzeichnis abgleicht.
Temporär habe ich mir einen eigenen "Update-Mechanismus" gebaut, bei dem ein geplanter Task auf jeden Probe-Server einfach einen XCOPY oder einen HTTP-Download eines Repository macht und so die Skripte lokal aktualisiert.


Wunsch

UDP-Probe

Vor vielen Jahren hat Paessler eine "QoS Sensor" entwickelt, die Pakete zu einer anderen Probe sendet und die Qualität misst. Später kam dann ein QoS mit UDPEcho-Sensor dazu, die an einen Host einfach ein UDP-Paket sendet und erwartet, dass es zurück gesendet wird. Damit konnte man nun auch "nicht Windows Systeme" als Gegenstelle nutzen, z.B. Router, Switches etc. Aus mir nicht verständlichen Gründen kann diese Probe nur Ziel-Port >1024 ansprechen, wo doch 7/UDP ein bekannter UDP-Echo-Port ist. Zudem nutzt die Probe den Port auch als Absenderport, wofür es aus meiner Sicht gar keinen Grund gibt. Wenn ich also mehrere dieser Sensoren einrichte, muss ich auch noch aufpassen, dass der Source-Port nicht belegt ist. Dynamische Source-Ports und die Nutzung von 7/UDP als Ziel stehen auf meiner Wunschliste.


Offen

"Virtuelle Devices" oder Sensoren unter Gruppen ohne Device

Aktuell kann man einen Sensor nur unter einem Device anlegen. Wenn ich nun einen "Sammelsensor" z.B. für CAS-User, ActiveSync Statistiken, Exchange Datenbanken o.ä. habe, dann passen die nicht unter ein echtes "Device". Natürlich kann ich ein "Dummy-Device" anlegen und verwende darunter dann einfach keine Sensoren, die auf die IP-Adresse dieses Device abzielen. Schicker fände ich aber schon, wenn man einen Sensor auch unter einer Gruppe anlegen darf. Man könnte ja Device-abhängige Sensoren ausblenden


Wunsch

Maintenance Mode

Wenn man einen Server oder Funktion geplant "pflegen" will, kann man nur das Device oder die Sensoren auf "Pause" stellen. Aber dann misst PRTG gar nichts mehr; hilft mir also auch nicht bei der Kontrolle der Funktion nach Abschluss der Pflege. Das "Maintenance Window" hingegen ist statisch gepflegt. Ich würde mir ein "Set to Maintenance"-Mode wünschen, bei dem PRTG weiterhin die Checks ausführt und das Ergebnis auch anzeigt aber eben keine Alarme generiert. Vieleicht wäre ein eigener Counter für solche Felder von Systemen in Maintenance sinnvoll.


Wunsch

PRTG-Server-Tool

Ich würde mir wünschen, dass ich auf den Servern, die z.B. Remote von einer Probe überwacht werden, eine einfache Möglichkeit hätte den Status dieses Server zu sehen und Pause und Maintenance an und abschalten. Bei Windows Servern könnte es eine kleine Applikation sein, die vom PRTG-Server einfach nur den Status und die Werte von "sich selbst" anzeigt. So könnte ein lokaler Admin auch ohne PRTG-Zugriff schon sehen, was das Monitoring zu dem Server sagt.

Interessant wäre auch eine Option z.B. eine Meldung an den PRTG-Server zu senden. Krönung wäre natürlich, wenn das Tool als Dienst den Status z.B. als Hintergrundfarbe ausgibt oder sogar die "Service-LED" einschaltet, die viele Server im Rack mittlerweile haben.

Interessant könnte es auch sein, wenn ein Admin auf dem Server über das Tool einfach einen "Acknowledge" eines Alarms absenden könnte oder sogar direkt die "Wartung" des Servers beauftragt.


Wunsch

PRTG Master/Slave-Kaskade

Aktuell besteht jede PRTG-Installation aus einem Core-Server mit 1-n Probes. Eine weitere "Überinstanz" gibt es aber nicht. Genau das wäre aber interessant, z.B. wenn mehrere Kunden PRTG nutzen und ich zu jeder Instanz einen "Webzugang" habe. Ich würde gerne in meine PRTG-Installation den Status der Kunden-Instanzen einbinden. Nur mit der Windows Enterprise Console kann man mehrere PRTG-Core-Systeme zusammenfassen. Die muss dazu aber laufen und zeigt nu die Momentaufnahme an. Ich habe auf PRTG Kaskade schon mal einen Workaround geschaffen.


Wunsch

Custom Sensor Enhancements

PRTG liest die Ausgaben des Custom Sensor von STDOUT ab. Erwartet wird eine XML-Datei. Allerdings startet PRTG erst nach dem ersten Auftreten von "<". Das ist gut, da ich so bei Skripten vorher Debug-Ausgaben generieren kann, die dann auch im Log zur Fehlersuche landen. Ich muss die PRTG-Ausgabe mit den Daten dann einfach am "Ende" des Skripts gesammelt ausgehen. Dumm nur, wenn in den Debug-Ausgaben auch ein "<" erscheint. Zudem darf nach dem abschließenden "</prtg>" auch nichts mehr stehen, da sonst PRTG die komplette Rückgabe verwirft. Da PRTG anscheinend einen eigenen XML-Parser nutzt und nicht stumpf die Ausgaben von STDOUT einliest, könnte PRTG doch erst ab einem vollständigen "<prtg>" beginnen und alles nach "</prtg>" ignorieren.
Wenn man schon dabei ist, dann könnte man die Trennung zwischen "EXE" und "EXEXML" aufheben. PRTG könnte einfach die Antwort nach "<prtg>" parsen und dann eine XML-Ausgabe annehmen.


Wunsch

Export, Import und historische Daten

Wenn Sie heute einen Sensor ändern wollen, dann sehen Sie, dass viele Dinge nach der Einrichtung statisch sind. Klar kann ich den Sensor löschen und geändert neu anlegen. Dabei verliere ich aber alle historische Daten. Man kann über die API zwar schon Daten exportieren aber es ist meines Wissens nicht möglich, Daten zu importieren. Das macht es natürlich schwer, von anderen Produkten umzusteigen oder Datenreihen anderer Quellen einzuspielen und PRTG nur zur Visualisierung zu nutzen.

Ich könnte ja z.B. in Exchange ein "Get-Messagetrackinglog" machen und so die Mails der letzten 30 Tage sekundengenau erhalten. für mich wäre es sehr einfach z.B. in 5Min Abständen die Anzahl und Größe nach Richtung zu ermitteln. Ich kann Sie nur nicht rückwirkend einspeisen. Schade.
Ein konkretes Beispiel hätte ich da: Mein Kostal Wechselrichter kann ich mit PRTG Kostal Realtime ablesen. Der Wechselrichter hat aber selbst einen Datenlogger, mit dem ich bis zu 100/400 Zurück die Daten erhalten kann. Schade, dass ich diese nicht in eine neue PRTG-Installation importieren kann.

Mittlerweile gibt es ja den HTTP Push Sensor. Der müsste nur noch einen Zeitstempel akzeptieren. Den Importer dazu würde ich mir schon selbst schreiben.


Wunsch

"Touch Aktion"

Mittlerweile ist der Preis für ein Windows Tablet mit 7 Zoll oder 8 Zoll unter 100€ gefallen. Das ist billiger als ein Raspberry + LCD oder andere Selbstbauten. Da kann man schon mal dran denken, so einen PC im Eigenheim an die Wand zur Visualisierung der Haustechnik zu schrauben. Der Nächste Schritt ist natürlich die Steuerung. "Custom Comands".

Es gibt heute schon auf jedem Device die "Device Tools", die aber nur eine Webseite, Traceroute etc. machen. Interessant wäre hier aber eine Aktion pro Sensor und nicht auf dem Gerät. Wenn ich per PRTG z. B. die Raumtemperatur aufzeichne, dann wäre ein direkter Link für Aktionen (wärmer, kälter) interessant.


Wunsch

PRTG PushService/WebService/REST-API

Aktuell basiert PRTG darauf, dass die Probe aktiv die Checks durchführt. Was ist auch gut, wenn das zu überprüfende System "online" und erreichbar ist. Was aber mit Systemen, die aufgrund von Funk oder NAT nicht von der Probe erreichbar sind aber umgekehrt immer mal wieder "aktiv" werden kann. Ich denke da an einen Datalogger (z.B. Arduino), der einmal in der Stunde einen Messwert erfasst und dann per HTTP-Post an eine zentrale Stellen melden könnte. (Stromzähler, Wasserzähler, Solaranlage etc.) oder auch ein Durchgangsmelder. Aktuell gibt es in PRTG zwar eine HTTP-Post API aber nur zum Verwalten von PRTG. Es wäre nett, wenn ein Client über eine dokumentierte API einfach Werte zum PRTG-Server (oder der Probe) senden kann, die diese dann als Werte übernimmt. Idealerweise auch mit der Angabe eines Zeitstempels
UPDATE: Diesen Sensor gibt es als PRTG - HTTPPush-Sensoren mittlerweile. Beschreibung ist in Arbeit.


Beta

QoS-Sensor mit generischen Gegenstellen

Der QoS-Sensor kann nur mit anderen PRTG-Probes Daten austauschen. Es gibt aber auch Router und Switches, die von sich aus auf UDP-Pakete antworten können. Damit könnte man zumindest einen "Roundtrip-Ping" per UDP senden und auswerten.


Vorhanden
QoS mit UDPEcho

Überlagerung von Messwerten / 3D-Grafik

Viele Messwerte haben ein 24h Intervall, z.B. Solarstromerzeugung etc. PRTG protokolliert alles schon mit uns zeigt 24,/2Tage/30Tage Bilder an. Ich habe noch keinen Weg gefunden, wie man mehrere 24h-Intervall "übereinander legen kann und so Min/Max/Mittelwerte sieht. Es gibt Fälle, wo das sicher weitere Infos liefern könnte. Aktuell kann ich die Daten als Report XML/CSV exportieren und per Skript zusammenfassen und dann in Excel anzeigen.


Anregung

Serverside managed Sensoren

PRTG kann heute schon einen neuen Computer "scannen" und entsprechende Sensoren automatisch anlegen. Dazu muss das PRTG ProbeSystem aber den Server erreichen, was hinter Firewalls und NAT nicht immer geht. Ich würde mir einen Weg wünschen, über den Ein Skript auf dem Server selbst über die bekannten PRTG:HTTPPush-Sensoren nicht nur Daten senden sondern auch passende Sensoren anlegen kann.

Natürlich muss das halbwegs "Sicher" erfolgen, z.B. indem es auch für den Server einen "Key" gibt und die neuen Sensoren könnten ja per Default auf "Pause" stehen, damit sie nicht als Lizenz zählen.

Aber so könnte ein ServerAdmin quasi selbst die Überwachungen und Einstellungen in PRTG vornehmen ohne selbst in PRTG aktiv zu sein. Der PRTG-Admin könnte einfach schnell mal den Server als Objekt anlegen und dem Serveradmin den Zugang gewähren.


Anregung

Ich beobachte die weiteren Entwicklungen bei PRTG und mit gespannt, welche Punkte ich bei Gelegenheit wieder entfernen kann. Da ich aber nicht immer alles zeitnah entdecke, können Sie mir gerne einen Tipp geben, wenn Paessler oder ein 3rd-Party AddOn Punkte der Wunschliste werfen kann.