Verwenden abhängiger Elemente in Zabbix 4.0 am Beispiel von HPE MSA 2040/2050

Published on August 04, 2018

Verwenden abhängiger Elemente in Zabbix 4.0 am Beispiel von HPE MSA 2040/2050

Einleitung


Jeder, der das Zabbix-Überwachungssystem verwendet und seine Entwicklung überwacht, weiß, dass wir mit dem Release von Zabbix 3.4 ein großartiges Feature haben - Abhängige Elemente (abhängige Datenelemente), das bereits einen entsprechenden Beitrag im Zabbix-Blog hatte. In der Form, in der es in 3.4 eingeführt wurde, war die Verwendung von "in vollem Umfang" problematisch, da LLD-Makros nicht für die Verwendung in Vorverarbeitungsregeln ( ZBXNEXT-4109 ) und auch als "übergeordnetes" System unterstützt wurden. Datenelement konnten Sie nur das Element auswählen, das von der LLD-Regel selbst erstellt wurde ( ZBXNEXT-4200)). Kurz gesagt, ich musste alles genau wie im Link oben beschrieben tun - mit meinen Händen zu arbeiten, was bei einer großen Anzahl von Metriken sehr unangenehm war. Mit der Veröffentlichung von Zabbix 4.0alpha9 hat sich jedoch alles geändert.

Ein bisschen Geschichte


Für mich war die beschriebene Funktionalität wichtig, da unser Unternehmen mehrere HP-Speichersysteme verwendet, nämlich HP MSA 2040/2050, deren Metriken durch Abfragen ihrer XML-API mithilfe eines Python-Skripts abgerufen werden .



Gleich zu Beginn, als die Aufgabe bestand, die zugewiesenen Geräte zu überwachen und eine Variante mithilfe der API gefunden zu werden, stellte sich heraus, dass im einfachsten Fall, um beispielsweise den Integritätsstatus einer Speicherkomponente zu ermitteln, zwei Abfragen erforderlich waren:

  • Authentifizierungs-Token anfordern (Sitzungsschlüssel);
  • Die Anforderung selbst, die Informationen zur Komponente zurückgibt.

Stellen Sie sich nun vor, dass der Speicher aus 24 Festplatten besteht (und vielleicht mehr), zwei Netzteilen, einem Paar Controller, Lüftern, mehreren Festplattenpools usw. - wir multiplizieren das alles mit 2 und wir erhalten mehr als 50 Datenelemente, was vielen Anfragen entspricht API bei jeder Minute überprüft. Wenn Sie versuchen, diesem Pfad zu folgen, „fällt“ die API schnell und in der Tat geht es nur darum, die „Gesundheit“ von Komponenten anzufragen, wobei andere mögliche und interessante Metriken nicht berücksichtigt werden - Temperatur, Betriebsstunden für Festplatten, Lüftergeschwindigkeit usw.

Die erste Lösung, die ich vor dem Release der Zabbix-Version 3.4 entschloss, bestand darin, einen Cache für das resultierende Token zu erstellen, dessen Wert in die Datei geschrieben und für N-Minuten gespeichert wurde. Dadurch konnte die Anzahl der Aufrufe der API genau zweimal reduziert werden. Die Situation änderte sich jedoch nicht viel - es war problematisch, etwas außer dem Gesundheitszustand zu bekommen. Zu dieser Zeit besuchte ich das von Badoo gehostete Zabbix Moscow Meetup 2017, wo ich über die Funktionalität der oben genannten abhängigen Datenelemente informiert wurde.

Das Skript wurde dahingehend verfeinert, dass es möglich ist, detaillierte JSON-Objekte mit den für uns interessanten Informationen zu den verschiedenen Komponenten des Repositorys anzugeben, und die Ausgabe dieser Elemente wirkte in etwa wie folgt, anstatt einzelne Zeichenfolgen oder numerische Werte:

{"1.1":{"health":"OK","health-num":"0","error":"0","temperature":"24","power-on-hours":"27267"},"1.2":{"health":"OK","health-num":"0","error":"0","temperature":"23","power-on-hours":"27266"},"1.3":{"health":"OK","health-num":"0","error":"0","temperature":"24","power-on-hours":"27336"}, ... }

Dies ist ein Beispiel für das Senden von Daten über alle Speicherplatten. Bei den restlichen Komponenten ist das Bild ähnlich - der Schlüssel ist die Komponenten-ID und der Wert ist das JSON-Objekt, das die gewünschten Metriken enthält.

Alles war gut, aber die Nuancen, die zu Beginn des Artikels beschrieben wurden, kamen schnell zum Vorschein - alle abhängigen Metriken mussten manuell erstellt und aktualisiert werden, was ziemlich schmerzhaft war (etwa 300 Metriken pro Speichersystem plus Trigger und Grafiken). Wir hätten vom LLD gerettet werden können, aber hier konnten wir beim Erstellen des Prototyps nicht als übergeordneten Artikel angeben, was nicht durch die Regel selbst erstellt wurde, sondern einen schmutzigen Hack mit der Erstellung eines fiktiven Elements über LLD und Ersetzen seiner Artikel-ID in der Datenbank durch Löschen Zabbix-Server Die erwähnten Funktionen wurden schnell im Zabbix-Bugtracker angezeigt, was darauf hindeutet, dass diese Funktionalität nicht nur für mich wichtig war.

Weil Alle Vorbereitungen meinerseits waren abgeschlossen, ich entschied mich dafür zu leiden und keine temporären Lösungen wie die Erzeugung dynamischer Vorlagen zu produzieren. Ich wartete nur auf die Schließung der ZBXNEXT, die zu Beginn des Artikels erwähnt wurden, und vor kurzem wurde dies getan.

Wie sieht es jetzt aus?


Um die neuen Funktionen von Zabbix zu demonstrieren, nehmen wir an:

  • Speicher HPE MSA 2040 verfügbar über HTTP / HTTPS;
  • Zabbix 4.0alpha9-Server aus dem offiziellen Repository auf CentOS 7.5.1804 installiert;
  • Ein in Python der dritten Version geschriebenes Skript, das uns die Möglichkeit bietet, Speicherkomponenten (LLD) zu erkennen und Daten im JSON-Format zur Analyse auf Zabbix-Serverseite mithilfe des JSON-Pfads zurückzugeben.

Das übergeordnete Datenelement ist eine "externe Prüfung" (externe Prüfung), die das Skript mit den erforderlichen Argumenten aufruft und die empfangenen Daten als Text speichert.

Vorbereitung


Das Python-Skript wird gemäß der Dokumentation installiert und verfügt über die Bibliothek "Requests" in den Python-Abhängigkeiten. Wenn Sie eine RHEL-basierte Distribution haben, können Sie sie mit dem yum-Paketmanager installieren:

[root@zabbix]# yum install python3-requests

Oder mit pip:

[root@zabbix]# pip install requests

Sie können das Skript von der Shell aus testen, indem Sie beispielsweise LLD-Daten zu den Festplatten anfordern:

[root@zabbix]# ./zbx-hpmsa.py -m MSA_DNS_NAME_OR_IP -d -c disks
{"data":[{"{#DISK.ID}":"1.1","{#DISK.SN}":"KFGY7LVF"},{"{#DISK.ID}":"1.2","{#DISK.SN}":"Z0K02QVG0000C4297CH3"},{"{#DISK.ID}":"1.3","{#DISK.SN}":"KLK7XG0F"}, ... }

Host-Setup


Zuerst müssen Sie übergeordnete Datenelemente erstellen, die alle erforderlichen Metriken enthalten. Als Beispiel erstellen wir ein solches Element für physische Festplatten:



Name - zufällig angegeben;
Typ - externe Prüfung;
Der Schlüssel ist ein Skriptaufruf mit den erforderlichen Parametern (siehe Skriptdokumentation auf GitHub).
Art der Information - Text;
Aktualisierungsintervall : In diesem Beispiel wird das benutzerdefinierte Makro {$ UPDATE} verwendet, das auf den Wert "1m" erweitert wird.
Die Lagerzeit beträgt einen Tag. Ich denke, dass es nicht sinnvoll ist, das übergeordnete Datenelement länger zu behalten.
Überprüfen Sie die neuesten Daten zum erstellten Artikel:



JSON kommt, es bedeutet, dass alles richtig gemacht wird.

Der nächste Schritt besteht darin, Erkennungsregeln einzurichten, die alle zur Überwachung verfügbaren Komponenten finden und abhängige Elemente und Auslöser erstellen. Wenn Sie mit dem Beispiel physischer Datenträger fortfahren, wird es folgendermaßen aussehen:



Nachdem Sie die LLD-Regel erstellt haben, müssen Sie Prototypen von Datenelementen erstellen. Erstellen wir einen solchen Prototyp am Beispiel von Temperaturdaten:



Name - wir geben willkürlich an;
Typabhängig . Wählen Sie als übergeordnetes Datenelement das zuvor erstellte entsprechende Element aus.
Der Schlüssel ist, die Vorstellungskraft zu zeigen, aber es ist notwendig zu berücksichtigen, dass jeder Schlüssel eindeutig sein muss. Daher werden wir das LLD-Makro in ihn aufnehmen.
Art der Informationen - in diesem Fall numerisch;
Aufbewahrungszeitraum der Geschichte- In diesem Beispiel handelt es sich um ein benutzerdefiniertes Makro, das Sie nach Ihrem Ermessen festlegen.
Die Trendspeicherperiode ist wieder ein Benutzermakro;

Ich fügte auch einen Prototyp der "Anwendung" hinzu - Sie können bequem die zugehörigen Metriken für eine Komponente verknüpfen.

Auf der Registerkarte "Vorverarbeitung" erstellen wir einen Schritt "JSON-Pfad" mit einer Regel, in der die Temperaturwerte extrahiert werden:



Der Schrittausdruck sieht folgendermaßen aus: $['{#DISK.ID}']['temperature']

Beachten Sie, dass Sie jetzt LLD-Makros im Ausdruck verwenden können, was unsere Arbeit nicht nur wesentlich erleichtert, sondern auch ermöglicht Die Dinge sind ziemlich einfach (Sie wären vorher an die Zabbix-API geschickt worden).

Analog zur Temperatur erstellen wir die übrigen Prototypen der Datenelemente:



In diesem Stadium können Sie das Ergebnis überprüfen, indem Sie auf dem Host unter "Latest data" (Neueste Daten) suchen. Wenn dort alles zu Ihnen passt, arbeiten wir weiter. Als Ergebnis erhielt ich folgendes Bild:



Wir warten auf die Aktualisierung des Konfigurationscaches oder pushen seine Aktualisierung manuell:

[root@zabbix]# zabbix_server -R config_cache_reload

Danach können Sie eine weitere coole Funktion der Version 4.0 verwenden - die Schaltfläche "Jetzt prüfen", um die erstellten LLD-Regeln zu starten:



Ich habe folgendes Ergebnis erhalten:



Fazit


Mit nur neun Anfragen an die XML-API konnten wir so mehr als dreihundert Metriken von einem Netzwerkknoten abrufen, um ein Minimum an Zeit zu sparen und maximale Flexibilität zu erhalten. LLD gibt uns die Möglichkeit, neue Komponenten automatisch zu erkennen oder alte Komponenten zu aktualisieren.

Vielen Dank, dass Sie die Links zu den verwendeten Materialien gelesen haben. Dort finden Sie auch die aktuelle Vorlage für HPE MSA P2000G3 / 2040/2050.

PS Übrigens, in Version 4.0 wird auch eine neue Art von Prüfungen vorgestellt - ein HTTP-Agent, der gepaart mit Vorverarbeitung und XML-Pfad dazu führen kann, dass externe Skripts nicht mehr verwendet werden können - Sie müssen lediglich das Problem lösen, ein Authentifizierungstoken zu erhalten, das regelmäßig noch aktualisiert werden muss. Eine der Optionen, die ich sehe, ist die Verwendung eines globalen Makros mit diesem Token, das über Zabbix API von cron, t.ch aktualisiert werden kann. Interessierte können diese Idee entwickeln. =)

Script -
Vorlage für Zabbix Teilen
abhängige Datenelemente
JSON Pfad
Zabbix 4.0alpha9