Bei der Erstellung einer Lösung fĂŒr den Kunden traten zwei Aufgaben auf, die ich elegant mit der StandardfunktionalitĂ€t von Zabbix lösen wollte.
Aufgabe 1. Ăberwachung der aktuellen Firmwareversion auf Mikrotik-Routern.
Die Aufgabe wird einfach gelöst â durch HinzufĂŒgen zum HTTP-Agenten-Template. Der Agent erhĂ€lt die aktuelle Version von der Mikrotik-Website, und der Trigger vergleicht die aktuelle Version mit der bestehenden und gibt bei einer Abweichung einen Alert aus.
Wenn Sie 10 Router haben, ist dieser Algorithmus nicht kritisch, aber was ist mit 3000 Routern? 3000 Anfragen an den Server senden? Das wird zwar funktionieren, aber allein die Idee von 3000 Anfragen gefiel mir nicht, ich wollte eine andere Lösung finden. DarĂŒber hinaus gab es einen Nachteil bei diesem Algorithmus: Die andere Seite könnte eine solche Anzahl von Anfragen von einer IP-Adresse als DoS-Angriff werten und einfach blockieren.
Aufgabe 2. Verwendung der Autorisierungssitzung in verschiedenen HTTP-Agenten.
Wenn ĂŒber einen HTTP-Agenten Informationen von "geschĂŒtzten" Seiten abgerufen werden mĂŒssen, ist ein Authentifizierungscookie erforderlich. DafĂŒr gibt es normalerweise ein Standardformular zur Authentifizierung mit einem Paar "Benutzername/Passwort" und der Festlegung der Sitzungs-ID im Cookie.
Es gibt jedoch ein Problem: Aus einem HTTP-Agenten-Item kann nicht auf die Daten eines anderen Items zugegriffen werden, um diesen Wert im Header zu ersetzen.
Es gibt auch ein "Web-Szenario", das eine andere EinschrĂ€nkung hat: Es erlaubt nicht, Inhalte zur Analyse und weiteren Speicherung zu erhalten. Man kann nur das Vorhandensein erforderlicher Variablen auf den Seiten ĂŒberprĂŒfen oder zuvor erhaltene Variablen zwischen den Schritten des Web-Szenarios ĂŒbertragen.
Nachdem ich ĂŒber diese Aufgaben nachgedacht hatte, beschloss ich, Makros zu verwenden, die in jedem Teil des Ăberwachungssystems gut sichtbar sind: in Templates, Hosts, Triggern oder Items. Und Makros können ĂŒber die API des Web-Interfaces aktualisiert werden.
Zabbix hat eine gute und ausfĂŒhrliche Dokumentation zur API. FĂŒr den Datenaustausch ĂŒber die API wird das JSON-Datenformat verwendet. Detaillierte Informationen sind zu finden in .
Die Abfolge der Schritte zum Abrufen der benötigten Daten und deren Speicherung in einem Makro ist im folgenden Schema dargestellt.

Schritt 1
Der erste Schritt kann aus einer einzigen Handlung oder vielen Aktionen bestehen. In den ersten Schritten wird die gesamte grundlegende Logik festgelegt, wobei die letzten drei 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 erhielt ich die Nummer der aktuellen Firmwareversion von Mikrotik.
URL der aktuellen Mikrotik-Firmware-Versionen
- â URL der aktuellen Stable-Version
- â URL der aktuellen LTS-Version
Diese Adressen werden vom Mikrotik-GerĂ€t verwendet, um die zuletzt verfĂŒgbare Firmware-Version abzurufen.
Der erste Schritt ist fĂŒr jeden Fall völlig individuell und die Logik seiner Funktionsweise kann unterschiedlich sein. Alles hĂ€ngt von Ihrer Aufgabe ab.
Bei der Arbeit mit Web-Skripten achten Sie darauf, welche Methode zum Empfang der Antwort benötigt wird. Header HTTP-Antwort oder der Inhalt der Antwort ohne Header? Wenn Authentifizierungscookies benötigt werden, setzen Sie die Antwortmethode
wie im Fall von Asterisk. Header Wenn Daten wie im Fall der Antwort des Mikrotik-Servers benötigt werden, setzen Sieden Inhalt der Antwort ohne Header. Kommen wir zum zweiten Schritt. Erhalt der Authentifizierungssitzung:
Schritt 2
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 verwendete Version des JSON-RPC-Protokolls;Zabbix implementiert JSON-RPC Version 2.0;
method â die aufzurufende Methode;
- params â die Parameter, die durch die Methode ĂŒbergeben werden;
- id â eine willkĂŒrliche Identifikationsnummer der Anfrage;
- auth â der AuthentifizierungsschlĂŒssel des Benutzers; 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. Einerseits ist es nicht notwendig, Zugang zu gewĂ€hren, wo es nicht erforderlich ist. Andererseits konnte bis zur Version 5.0 das ĂŒber Makros angegebene Passwort gelesen werden. Daher kann das Konto des Zabbix-Administrators leicht gestohlen werden.
Dies wird besonders relevant, wenn Sie ĂŒber Drittanbieter-Skripte mit der API arbeiten und die Anmeldeinformationen auf der Serverseite 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 Aktualisierung von Daten ĂŒber die API erstellen, stellen Sie sicher, dass die benötigten Daten ĂŒber die WeboberflĂ€che verfĂŒgbar sind und ob sie aktualisiert werden können. Ich habe das nicht ĂŒberprĂŒft und konnte lange nicht verstehen, warum der benötigte Makro ĂŒber die API nicht sichtbar war.

Nachdem Sie die Authentifizierung in der API erhalten haben, gehen wir zum Abrufen der Liste der Makros ĂŒber.

Nachdem die Autorisierung im API erhalten wurde, wechseln wir zur Abfrage der Liste der Makros.
Schritt 3
Die API-Schnittstelle erlaubt es nicht, die Makro des Hosts nach Name zu aktualisieren; dazu muss zuerst die ID des Makros erhalten werden. DarĂŒber hinaus muss, um eine Liste der Makros eines bestimmten Hosts zu erhalten, die ID dieses Hosts bekannt sein, was eine zusĂ€tzliche Anfrage erfordert. Verwenden Sie das Standardmakro {HOST.ID} , die Anfrage darf nicht sein. Ich habe beschlossen, die EinschrĂ€nkung so zu umgehen:

Ich habe ein lokales 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 einem Muster gefiltert werden:
regex:{"hostmacroid":"([0-9]+)"[A-z0-9,":]+"{$MIKROTIK_VERSION}" 
Auf diese Weise erhalten wir die ID des benötigten Makros, wobei MIKROTIK_VERSION â der Name des Makros, das wir suchen. In meinem Fall wird nach dem Makro gesucht MIKROTIK_VERSION, das dem Host zugewiesen wurde.
Die Anfrage 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} wurde im zweiten Schritt erhalten und wird stÀndig verwendet, wo mit der API-Schnittstelle gearbeitet werden muss.
Der finale 4. Schritt â Aktualisierung des Makros
Jetzt wissen wir die ID des Makros, das aktualisiert werden muss, das Authentifizierungscookie oder die Firmware-Version des Routers. Das Makro kann aktualisiert werden.
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} â der Wert, der im ersten Schritt erhalten wurde. In meinem Beispiel â die Version der aktuellen Mikrotik-Firmware
{hostmacroid} â der Wert, der im dritten Schritt erhalten wurde â die ID des Makros, das wir aktualisieren.
Das DBMS Tarantool ist ein attraktives, zukunftstrÀchtiges Produkt zur Erstellung von hochbelasteten Anwendungen.
Der Ansatz zur Lösung der Aufgabe mit den Standardfunktionen ist viel komplizierter und zeitaufwÀndiger. Besonders wenn man Programmierung weià und die benötigte Logik schnell in ein Skript schreiben kann.
Ein offensichtlicher Vorteil dieses Ansatzes ist die "PortabilitÀt" der Lösung zwischen verschiedenen Servern.
Ich finde es persönlich seltsam, dass es keine Möglichkeit gibt, im HTTP-Agenten auf die Daten eines anderen Items zuzugreifen und sie in den Anfrageinhalt oder die Header einzufĂŒgen [ ].
Das fertige Template kann .
Quelle: habr.com
