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
