PRTG Value Lookup

Die meisten Sensoren liefern numerische Werte, die auch gut in Grafiken anzuschauen sind. Es gibt aber auch Ergebnisse, die als Statustext nur eine konkrete Anzahl von Werten annehmen können. Wenn Sie aber "Texte" an PRTG übergeben, wird immer nur ein Wert 0 angezeigt. Sie können aber auch einen Status als "Wert" übergeben und über eine Lookup-Tabelle in PRTG dann den Status anzeigen. Das beschreibt diese Seite.

Warum ein String als Sensorwert?

Als ein gutes Beispiel habe ich mir meinen autonomen Rasenmäher her genommen, welcher über einen Custom Sensor abgefragt wird. Auf der Seite Landroid M800 WG757E Rasenschaf habe ich eine Überwachung per PRTG - Custom Sensor beschrieben. Ich habe mit dem Sensor auch den Status des Rasenmähers (Mäht, Wartet, Regenpause, gefangen, Laden u.a.) als numerischen Status übergeben. Im Bild sieht das dann so aus:

Das Feld "statnum" ist ein numerischer Status. Im Bild gerade nicht sichtbar gibt es auch noch das Feld "MessageNum", welches die Meldungen auf dem Display numerisch wiedergibt. Nur wer kann sich die Nummern merken.

Weitere Beispiele für einen Status wäre z.B. ein Drucker, der im Display auch Werte wie "Online", "Offline", "Printing", "Out Of Paper", "Sleeping" etc. anzeigt. Auch eine DSL-Leitung kennt z.B. ein "Online", "Offline", "Synchronizing" u.a. Es gibt also einige Sensoren, bei denen eine Textausgabe zu einem als "Nummer" gelieferten Status interessant für die Anzeige ist.

Text zu Nummern

Bei meinem Rasenmäher ist es nun so, dass der Sensor von der Quelle einen Text bekommt. Den kann ich aber leider so 1:1 nicht an PRTG senden. Es wäre zu schön, wenn PRTG intern selbst aus den Texten eine Tabelle bauen würde um daraus dann einen Status anzuzeigen. Allerdings wäre das auch wieder fehleranfällig und es dürfte auch historische Gründe haben. Viele Computer denken in "Zahlen".

Also habe ich mir im Sensor einen Code gebaut, der den Text auf einen numerischen Wert umsetzt. So habe ich auch die Freiheit die Reihenfolge zu bestimmen. weniger kritische Messages habe ich mit niedrigeren Nummern bedacht. "Warnungen" sind im Mittelfeld und Fehler eben oben. So kann ich die in PRTG eingebaute Alarmierung bei Überschreitung von Werten gleich mit benutzen. Im Code finden Sie folgende Daten:

und

Diese Nummern werden an PRTG übergeben und erfasst.

Nummern zu Text

Das Ziel ist nun aber in der PRTG GUI natürlich wieder den Text zu sehen. Das ist mit der Funktion "Value Lookup" möglich. Es gibt jede Menge Links zu dem Thema:

So ein Lookup-File ist einfach nur eine XML-Datei und hat in etwa den folgenden Aufbau:

<?xml version="1.0" encoding="UTF-8"?>
<ValueLookup id="msxfaq.sample" 
      id="msxfaq.sample.state" 
      desiredValue="100" 
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
      xsi:noNamespaceSchemaLocation="PaeValueLookup.xsd">
  <Lookups>
    <SingleInt state="None" value="0">Ok</SingleInt>
    <SingleInt state="Ok" value="1">Ok</SingleInt>
    <SingleInt state="Warning" value="2">Warnung</SingleInt>
    <SingleInt state="Error" value="3">Fehler</SingleInt>
   </Lookups>
</ValueLookup>

Das Property "ID" bestimmt, wie die Lookup-Definition später in der Auswahlliste angezeigt wird. Der Dateiname ist nicht relevant. Achten Sie darauf, dass dieser String eindeutig ist.

Sie können mit dem Token "Range" auch Bereiche definieren. Allerdings können Sie in einer XML-Datei "SingleInt" nicht mit "Range" mischen.

    <Range state="Warning" from="6" to="15">Low</Range>
    <Range state="Error" from="0" to="5">Critical</Range>
    <Range state="None" from="-2" to="-1">Unknown</Range>
    <Range state="Ok" from="-3" to="-3">Not Empty</Range>

"Boolean" und "BitField" sind weitere mögliche Optionen

Das ist einfach und überschaubar. Also habe ich mich dran gemacht und meine SELECT-Statements aus dem Custom-Sensor in so eine XML-Datei zu schreiben und am richtigen Platz abzulegen. Der ist auf:

C:\Programme (x86)\PRTG Network Monitor\lookups

Der Ordner ist mit über 150 Lookup-Dateien gut gefüllt.

Hier lege ich dann meine beiden Dateien ab:

msxfaq.landroid.state.ovl
msxfaq.landroid.message.ovl

Es ist immer gut die XML-Dateien zu verifizieren. Es reicht schon ein "[xml](gc dateiname)" um die Datei zu lesen und durch den XML-Parser zu senden. Es sollte kein Fehler kommen.

PRTG lädt die neuen Definitionen nicht sofort wieder ein. Sie können ein Reload über die Weboberfläche antriggern. Unter "Setup - Systemadministration - Administrative Tools" gibt es den Button zum "Load Lookups and File Lists"

Damit starten Sie einen Reload der Definitionen.

CustomUnit erforderlich

Damit sie nicht über das gleiche Problem stoßen, wie ich. Die Möglichkeit einen Wert mit einer Lookup-Tabelle zu verbinden ist nur möglich, wenn der Kanal als "Custom" definiert ist. Wer also eine XML-Datei mit seinem Selbstbausensor generiert, sollte zwei Zeilen zu den Kanälen addieren.

<prtg>
  <result>
    <xxxxx>
    <unit>Custom</unit>
    <CustomUnit>State</CustomUnit>
  </result>
</prtg>

Die Bezeichnung der CustomUnit können Sie natürlich passend zu ihrer Umgebung wählen. 

Lookup mit Channel verbinden

Damit diese genutzt werden muss ich diese nun natürlich am Kanal des Sensors noch mit eintragen. Hier am Beispiel meines "State" des Rasenmähers:

Als Folge zeigt PRTG dann diesen Sensor als Segment an:

Bei so vielen verschiedenen Status-Möglichkeiten ist die Anzeige natürlich eingeschränkt. Aber es gibt ja auch Kanäle, die nur drei Statuszustände kennen die auch alle Drei dann noch nach Grün, Gelb, Rot unterschieden werden können.

Wer übrigens einen Custom-Sensor selbst schreibt, kann die Lookup-Tabelle beim Kanal durch den zusätzlichen XML-Parameter "valueLookup" gleich mitgeben.

<ValueLookup>msxfaq.sample.state</ValueLookup>

Die Definition wird aber nur beim ersten Mal mit dem Anlegen des Channels übernommen. Danach dürfen Sie dann doch wieder von Hand ran

Bewertung

Leider habe ich diese Funktion von PRTG erst sehr spät entdeckt und so gibt es einige Custom Sensoren, bei denen ich zwar einen Status als numerischen Wert an PRTG übergebe aber dann als Unit nicht "Custom" genommen habe. So habe ich nun einige Sensoren mit Daten über mehrere Monate und leider kann ich eine Kanal-Definition nachträglich nicht mehr ändern. Ich müsste den kompletten Sensor neu anlegen. Damit gehen aber auch alle Daten zu diesem Sensor verloren.

Schade eigentlich, dass PRTG nicht auch die Übergabe von "TEXT" zulässt. Aber die Umsetzung von Lookups ist doch sehr einfach und ich werde bei zukünftigen Sensoren sicher darauf achten, dass solche Kanäle als "Custom" gekennzeichnet sind.

Wer mit eigenen Sensoren arbeitet, wird die Möglichkeit des Lookups aber noch aus anderer Sicht mögen. Wen ich mit einem Sensor mehrere Werte erfasse, dann konnte ich über den Status am Ende nur zwischen Ok, Warnung und Error unterscheiden. Nun kann ich einen zusätzlichen Kanal im Sensor selbst "errechnen", der z.B. den Status des Gesamtsystems besser beschreibt und die drei generischen Schweregrade (Ok, Warnung, Error) noch weiter unterteilen.

Wenn der Status-Kanal dann auch der primäre Kanal ist, wird der Status auch in der Übersicht angezeigt. Das macht es doch einfacher, eine "Warnung" oder "Fehler" auf den ersten Blick mit Details zu unterfüttern.

Weitere Links