Als ich eine Lösung für einen Kunden erarbeitete, ergaben sich zwei Aufgaben, die ich schön und mit der regulären Zabbix-Funktionalität lösen wollte.
Aufgabe 1. Verfolgen der aktuellen Firmware-Version auf Mikrotik-Routern.
Die Aufgabe lässt sich einfach lösen – durch Hinzufügen eines Agenten zur HTTP-Vorlage. Der Agent erhält die aktuelle Version von der Mikrotik-Website, und der Trigger vergleicht die aktuelle Version mit der aktuellen und gibt im Falle einer Diskrepanz eine Warnung aus.
Wenn Sie 10 Router haben, ist ein solcher Algorithmus nicht kritisch, aber was tun mit 3000 Routern? 3000 Anfragen an den Server senden? Natürlich wird ein solches Schema funktionieren, aber die bloße Idee von 3000 Anfragen gefiel mir nicht, ich wollte eine andere Lösung finden. Darüber hinaus gab es bei einem solchen Algorithmus noch einen Nachteil: Die Gegenseite kann so viele Anfragen von einer IP für einen DoS-Angriff zählen, dass sie ihn einfach verbieten kann.
Aufgabe 2. Verwendung einer Autorisierungssitzung in verschiedenen HTTP-Agenten.
Wenn ein Agent Informationen von „geschlossenen“ Seiten über HTTP empfangen muss, ist ein Autorisierungscookie erforderlich. Dazu gibt es in der Regel ein Standard-Autorisierungsformular mit einem „Login/Passwort“-Paar und dem Setzen der Session-ID im Cookie.
Es gibt jedoch ein Problem: Es ist nicht möglich, von einem HTTP-Agent-Element aus auf die Daten eines anderen Elements zuzugreifen, um diesen Wert im Header zu ersetzen.
Es gibt auch ein „Webskript“, das eine weitere Einschränkung aufweist: Es ermöglicht Ihnen nicht, Inhalte zur Analyse und weiteren Speicherung abzurufen. Sie können nur das Vorhandensein der erforderlichen Variablen auf den Seiten prüfen oder zuvor empfangene Variablen zwischen Webskriptschritten übergeben.
Nachdem ich ein wenig über diese Aufgaben nachgedacht hatte, entschied ich mich für die Verwendung von Makros, die in jedem Teil des Überwachungssystems perfekt sichtbar sind: in Vorlagen, Hosts, Triggern oder Elementen. Und Sie können Makros über die Webschnittstellen-API aktualisieren.
Zabbix verfügt über eine gute und detaillierte API-Dokumentation. Für den Datenaustausch per API wird das Json-Datenformat verwendet. Einzelheiten finden Sie in .
Die Abfolge der Aktionen zum Erhalten der benötigten Daten und deren Aufzeichnung in einem Makro ist im folgenden Diagramm dargestellt.
Schritt 1
Der allererste Schritt kann aus einer einzelnen Aktion oder mehreren Aktionen bestehen. Die gesamte Hauptlogik ist in den ersten Schritten festgelegt, und die letzten drei Schritte sind die wichtigsten.
In meinem Beispiel bestand der erste Schritt darin, für die erste Aufgabe Autorisierungscookies auf der PBX abzurufen. Für die zweite Aufgabe habe ich die Nummer der aktuellen Version der Mikrotik-Firmware ermittelt.
URL aktueller Versionen der Mikrotik-Firmware
- - URL-Adresse der aktuellen stabilen Version
- — URL-Adresse der aktuellen LTS-Version
Auf diese Adressen greift das Mikrotik-Gerät selbst zu, wenn die neueste verfügbare Firmware-Version empfangen wird.
Der erste Schritt ist für jeden Fall völlig individuell und die Logik seiner Arbeit kann unterschiedlich sein. Es hängt alles von Ihrer Aufgabe ab.
Behalten Sie beim Arbeiten mit Web-Scripting im Auge, welche Antwortmethode Sie benötigen. Schlagzeilen HTTP-Antwort oder self тело Antwort ohne Header?
Wenn Autorisierungscookies erforderlich sind, legen Sie die Antwortmethode fest Schlagzeilen wie im Fall von Asterisk.Wenn Sie Daten benötigen, wie im Fall der Antwort des Mikrotik-Servers, geben Sie Folgendes ein Körper Antwort ohne Header.
Schritt 2
Kommen wir zum zweiten Schritt. So erhalten Sie eine Autorisierungssitzung:
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 ist die verwendete Version des JSON-RPC-Protokolls;
Zabbix implementiert JSON-RPC Version 2.0;
- Methode – die Methode, die aufgerufen wird;
- params – Parameter, die von der Methode übergeben werden;
- id ist eine beliebige Anforderungskennung;
- auth – Benutzerauthentifizierungsschlüssel; Da wir es noch nicht haben, setzen wir es auf null.
Um mit der API arbeiten zu können, habe ich ein separates Konto mit eingeschränkten Rechten erstellt. Erstens müssen Sie keinen Zugriff gewähren, wenn Sie dies nicht benötigen. Und zweitens konnte vor Version 5.0 das über das Makro festgelegte Passwort gelesen werden. Wenn Sie das Zabbix-Administratorkennwort verwenden, ist es dementsprechend leicht, das Administratorkonto zu stehlen.
Dies gilt insbesondere dann, wenn Sie mit der API über Skripts von Drittanbietern arbeiten und nebenbei Anmeldeinformationen speichern.
Seit Version 5.0 gibt es die Möglichkeit, das im Makro gespeicherte Passwort auszublenden.
Wenn Sie ein separates Konto für die Datenaktualisierung über die API erstellen, prüfen Sie unbedingt, ob die von Ihnen benötigten Daten über die Weboberfläche verfügbar sind und ob eine Aktualisierung möglich ist. Ich habe es nicht überprüft und konnte dann lange Zeit nicht verstehen, warum das von mir benötigte Makro in der API nicht sichtbar war.
Nachdem wir die Autorisierung in der API erhalten haben, holen wir uns eine Liste der Makros.
Schritt 3
Die API erlaubt es Ihnen nicht, ein Host-Makro nach Namen zu aktualisieren. Sie müssen zuerst die Makro-ID abrufen. Um eine Liste der Makros für einen bestimmten Host zu erhalten, müssen Sie außerdem die ID dieses Hosts kennen. Dies ist eine zusätzliche Anfrage. Standardmakro verwenden {HOST-ID} in der Anfrage ist nicht zulässig. Ich habe beschlossen, die Einschränkung wie folgt zu umgehen:
Ich habe ein lokales Makro mit der ID dieses Hosts erstellt. Die Host-ID lässt sich ganz einfach über die Weboberfläche herausfinden.
Eine Antwort mit einer Liste aller Makros auf einem bestimmten Host kann nach einem Muster gefiltert werden:
regex:{"hostmacroid":"([0-9]+)"[A-z0-9,":]+"{$MIKROTIK_VERSION}"
Somit erhalten wir die ID des Makros, das wir benötigen, wo MIKROTIK_VERSION ist der Name des Makros, nach dem wir suchen. In meinem Fall wird das Makro durchsucht MIKROTIK_VERSIONDas wurde dem Host zugewiesen.
Die Anfrage selbst sieht so 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
}
Variable {sid} erhalten Sie im zweiten Schritt und werden ständig dort eingesetzt, wo Sie mit der API-Schnittstelle arbeiten müssen.
Letzter 4 SCHRITT – Aktualisieren des Makros
Jetzt kennen wir die Makro-ID, die aktualisiert werden muss, das Autorisierungs-Cookie oder die Firmware-Version des Routers. Sie können 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} ist der im ersten Schritt erhaltene Wert. In meinem Beispiel die Version der aktuellen Mikrotik-Firmware
{hostmacroid} - Der Wert wurde im dritten Schritt erhalten – die ID des Makros, das wir aktualisieren.
Befund
Der Ansatz zur Lösung des Problems mit Standardfunktionalität ist viel komplizierter und länger. Vor allem, wenn Sie sich mit Programmieren auskennen und schnell die nötige Logik in das Skript einbauen können.
Der offensichtliche Vorteil dieses Ansatzes ist die „Portabilität“ der Lösung zwischen verschiedenen Servern.
Für mich persönlich ist es seltsam, dass der HTTP-Agent nicht auf die Daten eines anderen Elements zugreifen und diese im Anforderungstext oder in den Headern ersetzen kann [ ].
Die fertige Vorlage kann .
Source: habr.com