Heute habe ich einen coolen neuen Trick gelernt, in dem ich das Item Preprocessing benutzen kann das Zabbix seit der Version 3.4 anbietet. Dies ist kein Zabbix-Blog, aber ich betrachte das als so nützlich — und nicht gerade intuitiv — dass ich das mal eben aufschreiben möchte.
Für alle die es nicht kennen: Zabbix ist ein quelloffenes Monitoring System, der Hersteller nennt es nicht ganz zu unrecht „Enterprise Class“. Ich nutze das nicht nur bei der Arbeit sondern auch zu Hause — nicht nur um das Fleisch in meinem Smoker zu monitoren. 
Meiner Meinung nach ist Zabbix wirklich stark bei allem was in Zahlen ausgedrückt werden kann. Es kann auch mit textuellen Informationen umgehen, aber nachdem ich damit ein paar kleinere Schwierigkeiten hatte versuche ich das nach Möglichkeit zu vermeiden. Zustände können in Zabbix auch numerisch dargestellt und als Ganzzahl gespeichert werden, mit dem Value Mapping kann man trotzdem gut lesbare Ausgaben erzeugen.
Heute bin ich an ein Problem gekommen das ich mit meinen üblichen Methoden erst nicht umsetzen konnte. Ein Webservice gibt mir den Status einer Applikation, die ist entweder RUNNING, STOPPING oder STOPPED. Es ist nicht schwer das in einem String-Item zu speichern, und einen Trigger anzulegen der reagiert wenn die Applikation STOPPED ist. In diesem speziellen Fall sollte ich aber einen Trigger bauen der meldet wenn der Dienst länger als eine gewisse Zeit im Status STOPPING ist, daran ist zu erkennen dass es ein Problem beim regulären Anhalten der Applikation gibt. Das war nicht trivial, da die Triggerfunktion str("STOPPING",15m) auch schon zuschlägt wenn mindestens einer der Werte in den letzten 15 Minuten „STOPPING“ war.
Item Preprocessing to the rescue!
Drei Schritte
Mit Version 3.4 hat ein Feature namens
Item Preprocessing in Zabbix Einzug gehalten. Damit kann ein gemessener Wert auf verschiedene Arten weiterbehandelt werden bevor er gesichert wird. Eine der Methoden ist, durch reguläre Ausdrücke eine Art „Suchen und Ersetzen“ vorzunehmen.
Wie sich rausstellt brauchte ich dazu einen halbwegs komplexen regulären Ausdruck, aber am Ende konnte ich die Zustände des Webservices in einfache Ganzzahlen umwandeln. Bei einer Websuche habe ich etwas über „conditional replacement“ gefunden, und mit diesem großartigen Tester für reguläre Ausdrücke konnte ich diese Schönheit bauen:
|
|
(STOPPED|STOPPING|RUNNING)(?=.*:\1=(\d)) |
Damit kann ich den String den ich mittels JSON Path aus der Ausgabe des Webservices ziehe in zwei weiteren Schritten umwandeln:
- Erst hänge ich eine Art „Wörterbuch“ an meinen Wert: ich ersetze den kompletten Wert
(.*) durch sich selbst, gefolgt von den Ersetzungswerten: \1:STOPPED=0:STOPPING=1:RUNNING=2.
- Dann ersetze ich den regulären Ausdruck
(STOPPED|STOPPING|RUNNING)(?=.*:\1=(\d)) durch den Wert der zweiten Capturing Group \2.
Auf die Weise kann ich mein Item als vorzeichenlose Ganzzahl konfigurieren, da hier nur noch die Zahlen 0, 1 oder 2 abgelegt werden müssen. Und ich kann die übliche Trigger-Funktions-Magie anwenden um zu melden wenn der Wert länger als eine gewisse Zeit bei 1 verbleibt. Ein weiterer Bonus: ich kann im Graphen des Items sehen wann der Webservice nicht im Zustand RUNNING gewesen ist, und wie lange das angehalten hat.
Vorschläge?
Ich bin ziemlich angetan davon, Werte auf diese Weise für die Weiterverarbeitung vorzubereiten. Aber ich bin auch an Meinungen interessiert: gibt es bessere Wege mit diesem Problem umzugehen? Irgendwas offensichtliches das ich übersehen habe?
English preferred? 
