Beim Erstellen einer Lösung für den Kunden traten zwei Aufgaben auf, die ich elegant mit den standardmäßigen Funktionen von Zabbix lösen wollte.
Aufgabe 1. Überwachung der aktuellen Firmware-Version auf Mikrotik-Routern.
Diese Aufgabe lässt sich einfach lösen — durch das Hinzufügen zum HTTP-Agenten-Template. Der Agent ruft die aktuelle Version von der Mikrotik-Website ab, und der Trigger vergleicht die aktuelle Version mit der installierten. Bei Abweichungen wird ein Alarm ausgelöst.
Wenn Sie 10 Router haben, ist dieser Algorithmus nicht kritisch, aber was ist mit 3000 Routern? Soll ich 3000 Anfragen an den Server senden? Technisch wäre dieses Schema natürlich umsetzbar, aber die Vorstellung von 3000 Anfragen gefällt mir nicht. Außerdem hätte ein solches Verfahren einen Nachteil: Die Gegenseite könnte eine solche Anzahl an Anfragen von einer IP als DoS-Angriff werten und einfach blockieren.
Aufgabe 2. Verwendung von Authentifizierungssitzungen in verschiedenen HTTP-Agenten.
Wenn über den HTTP-Agenten Informationen von „geschützten“ Seiten abgerufen werden müssen, ist ein Authentifizierungs-Cookie erforderlich. Üblicherweise gibt es dazu ein Standard-Authentifizierungsformular mit einem „Benutzername/Passwort“-Paar und der Festlegung der Sitzungs-ID im Cookie.
Es gibt jedoch ein Problem: Ein HTTP-Agent kann nicht auf die Daten eines anderen Elements zugreifen, um diesen Wert im Header zu ersetzen.
Außerdem gibt es das 'Web-Skript', das eine andere Einschränkung hat: Es erlaubt nicht, Inhalte zur Analyse und späteren Speicherung abzurufen. Man kann nur überprüfen, ob erforderliche Variablen auf den Seiten vorhanden sind oder zuvor erhaltene Variablen zwischen den Schritten des Web-Skripts übertragen.
Nachdem ich etwas über diese Aufgaben nachgedacht habe, habe ich beschlossen, Makros zu verwenden, die in jedem Bereich des Überwachungssystems deutlich sichtbar sind: in Vorlagen, Hosts, Triggern oder Elementen. Die Makros können über die API des Web-Interface aktualisiert werden.
Zabbix verfügt über eine umfassende und detaillierte Dokumentation zur API. Für den Datenaustausch über die API wird das Datenformat JSON verwendet. Weitere Informationen finden Sie in .
Die Reihenfolge der Schritte zur Erfassung der benötigten Daten und deren Speichern in ein Makro wird im folgenden Diagramm dargestellt.
Schritt 1
Der erste Schritt kann aus einer einzelnen Aktion oder aus mehreren Aktionen bestehen. In den ersten Schritten wird die gesamte grundlegende Logik verankert, während die letzten 3 Schritte die wichtigsten sind.
In meinem Beispiel wurde im ersten Schritt das Authentifizierungscookie von der Telefonanlage für die erste Aufgabe abgerufen. Für die zweite Aufgabe habe ich die aktuelle Firmware-Version von Mikrotik erhalten.
URLs aktueller Mikrotik-Firmware-Versionen
- — URL der aktuellen stabilen Version
- — URL der aktuellen LTS-Version
Diese Adressen werden von Mikrotik-Geräten verwendet, um die neueste verfügbare Firmware-Version zu erhalten.
Der erste Schritt ist vollständig individuell und die Logik seiner Funktionsweise kann unterschiedlich sein. Es hängt alles von Ihrer Aufgabe ab.
Achten Sie bei der Arbeit mit Web-Szenarien darauf, welche Methode zur Antwortabholung Sie benötigen. Header HTTP-Antwort oder der Body der Antwort ohne Header?
Wenn Authentifizierungscookies benötigt werden, setzen Sie die Antwortmethode Header wie im Fall von Asterisk.Wenn Daten benötigt werden, wie im Fall der Mikrotik-Serverantwort, setzen Sie den Body der Antwort ohne Header.
Schritt 2
Wir kommen nun zum zweiten Schritt. Abrufen der Authentifizierungssitzung:
POST http://company.com/zabbix/api_jsonrpc.php HTTP/1.1
Content-Type: application/json-rpc
{
"jsonrpc": "2.0",
"method": "user.login",
"params": {
"user": "Admin",
"password": "zabbix"
},
"id": 1,
"auth": null
}jsonrpc — die übertragene Version des JSON-RPC-Protokolls;
Zabbix implementiert JSON-RPC Version 2.0;
- method — die Methode, die aufgerufen wird;
- params — die Parameter, die durch die Methode übergeben werden;
- id — eine beliebige Anforderungs-ID;
- auth — der Schlüssel zur Benutzerauthentifizierung; da wir diesen noch nicht haben, setzen wir ihn auf null.
Für die Arbeit mit der API habe ich ein separates Konto mit eingeschränkten Rechten erstellt. Erstens sollte man keinen Zugriff gewähren, wo es nicht nötig ist. Zweitens konnte das über ein Makro festgelegte Passwort vor Version 5.0 ausgelesen werden. Dementsprechend ist es einfach, das Admin-Konto zu kompromittieren, wenn man das Passwort des Zabbix-Administrators verwendet.
Das ist besonders wichtig, wenn Sie mit der API über externe Skripte arbeiten und Benutzerinformationen auf der Client-Seite speichern.
Mit Version 5.0 wurde die Option eingeführt, das im Makro gespeicherte Passwort zu verbergen.
Wenn Sie ein separates Konto für die Datenaktualisierung über die API erstellen, überprüfen Sie unbedingt, ob die benötigten Daten über die Webschnittstelle zugänglich sind und ob eine Aktualisierung möglich ist. Ich habe das nicht geprüft und konnte lange nicht verstehen, warum das benötigte Makro nicht über die API sichtbar war.
Nachdem wir die Autorisierung in der API erhalten haben, gehen wir zur Abfrage der Liste der Makros über.
Schritt 3
Die API-Schnittstelle erlaubt es nicht, den Host-Makro nach Name zu aktualisieren; dafür muss zuerst die ID des Makros ermittelt werden. Zudem ist es notwendig, die ID des bestimmten Hosts zu kennen, um eine Liste der Makros für diesen Host zu erhalten, was eine zusätzliche Anfrage erfordert. Der Standard-Makro {HOST.ID} kann nicht verwendet werden. {HOST.ID} Ich habe diese Einschränkung umgangen, indem ich:
Ich habe einen lokalen Makro mit der ID dieses Hosts erstellt. Die ID des Hosts lässt sich ganz einfach über die Weboberfläche herausfinden.
Die Antwort mit der Liste aller Makros dieses Hosts kann nach folgendem Muster gefiltert werden:
regex:{"hostmacroid":"([0-9]+)"[A-z0-9,":]+"{$MIKROTIK_VERSION}" 
Auf diese Weise erhalten wir die ID des gesuchten Makros, wobei MIKROTIK_VERSION der Name des Makros ist, das wir suchen. In meinem Fall wird nach dem Makro gesucht, MIKROTIK_VERSION, das dem Host zugewiesen wurde.
Die Anfrage sieht folgendermaßen aus:
POST http://company.com/zabbix/api_jsonrpc.php HTTP/1.1
Content-Type: application/json-rpc
{
"jsonrpc":"2.0",
"method":"usermacro.get",
"params":{
"output":"extend",
"hostids":"{$HOST_ID}"
},
"auth":"{sid}",
"id":1
}
Die Variable {sid} wird in Schritt zwei erhalten und wird ständig verwendet, wo es nötig ist, mit der API-Schnittstelle zu arbeiten.
Der letzte Schritt – das Aktualisieren des Makros
Jetzt kennen wir die ID des Makros, das aktualisiert werden muss, sowie das Authentifizierungscookie oder die Firmware-Version des Routers. Wir können nun das Makro selbst aktualisieren.
POST http://company.com/zabbix/api_jsonrpc.php HTTP/1.1
Content-Type: application/json-rpc
{
"jsonrpc":"2.0",
"method":"usermacro.update",
"params":{
"hostmacroid":"{hostmacroid}",
"value":"{mikrotik_version}"
},
"auth":"{sid}",
"id":1
}
{mikrotik_version} — ein Wert, der im ersten Schritt erhalten wurde. In meinem Beispiel — die aktuelle Version der Mikrotik-Firmware.
{hostmacroid} — der Wert, den wir im dritten Schritt erhalten haben — die ID des Makros, das wir aktualisieren.
Fazit
Der Ansatz zur Lösung des Problems mit den standardmäßigen Funktionalitäten ist deutlich komplizierter und zeitaufwendiger. Besonders, wenn man Programmierung kennt und schnell die benötigte Logik in einem Skript entwerfen kann.
Ein offensichtlicher Vorteil dieses Ansatzes ist die „Portabilität“ der Lösung zwischen verschiedenen Servern.
Für mich persönlich ist es merkwürdig, dass es nicht möglich ist, in HTTP-Agenten auf Daten eines anderen Items zuzugreifen und diese in den Body oder die Header des Antrags einzufügen [ ].
Das fertige Template kann .
Quelle: habr.com
