Bij het maken van een oplossing voor een klant kwamen er 2 taken naar voren die ik mooi en met reguliere Zabbix functionaliteit wilde oplossen.
1-taak. Het volgen van de huidige firmwareversie op Mikrotik-routers.
De taak is eenvoudig op te lossen: door een agent aan de HTTP-sjabloon toe te voegen. De agent ontvangt de huidige versie van de Mikrotik-website en de trigger vergelijkt de huidige versie met de huidige en geeft een waarschuwing in geval van een discrepantie.
Als je 10 routers hebt, is zo’n algoritme niet kritisch, maar wat te doen met 3000 routers? 3000 verzoeken naar de server sturen? Natuurlijk zal zo'n schema werken, maar het idee van 3000 verzoeken paste niet bij mij, ik wilde een andere oplossing vinden. Daarnaast zat er nog een nadeel aan zo’n algoritme: de andere kant kan zoveel verzoeken van één IP tellen voor een DoS-aanval, dat ze deze simpelweg kunnen verbieden.
2-taak. Een autorisatiesessie gebruiken in verschillende HTTP-agents.
Wanneer een agent informatie van "gesloten" pagina's via HTTP moet ontvangen, is een autorisatiecookie nodig. Om dit te doen, is er meestal een standaard autorisatieformulier met een "login/wachtwoord"-paar en het instellen van de sessie-ID in de cookie.
Maar er is een probleem: het is onmogelijk om toegang te krijgen tot de gegevens van een ander item vanuit een HTTP-agentitem om deze waarde in de header te vervangen.
Er is ook een "webscript", het heeft nog een beperking: u kunt geen inhoud verkrijgen voor analyse en verdere opslag. U kunt alleen controleren op de aanwezigheid van de benodigde variabelen op de pagina's of eerder verkregen variabelen doorgeven tussen webscriptstappen.
Nadat ik een beetje over deze taken had nagedacht, besloot ik macro's te gebruiken die perfect zichtbaar zijn in elk deel van het monitoringsysteem: in sjablonen, hosts, triggers of items. En u kunt macro's bijwerken via de webinterface-API.
Zabbix heeft goede en gedetailleerde API-documentatie. Voor gegevensuitwisseling via API wordt het dataformaat Json gebruikt. Details zijn te vinden in .
De volgorde van acties voor het verkrijgen van de gegevens die we nodig hebben en het vastleggen ervan in een macro wordt weergegeven in het onderstaande diagram.
Stap 1
De allereerste stap kan bestaan uit een enkele actie of meerdere acties. Alle hoofdlogica wordt in de eerste stappen gelegd, en de laatste drie stappen zijn de belangrijkste.
In mijn voorbeeld was de eerste stap het verkrijgen van autorisatiecookies op de PBX voor de eerste taak. Voor de tweede taak kreeg ik het nummer van de huidige versie van de Mikrotik-firmware.
URL van huidige versies van Mikrotik-firmware
- - URL-adres van de huidige stabiele versie
- — URL-adres van de huidige LTS-versie
Deze adressen zijn toegankelijk voor de Mikrotik-apparatuur zelf wanneer de nieuwste beschikbare firmwareversie wordt ontvangen.
De eerste stap is voor elk geval volledig individueel en de logica van het werk kan verschillen. Het hangt allemaal af van uw taak.
Houd bij het werken met webscripting bij welke responsmethode je nodig hebt. Koppen HTTP-antwoord of zelf тело reactie zonder headers?
Als er autorisatiecookies nodig zijn, stel dan de responsmethode in Koppen zoals in het geval van Asterisk.Als u gegevens nodig heeft, zoals in het geval van de mikrotik-serverreactie, zet dan lichaam reactie zonder headers.
Stap 2
Laten we verder gaan met de tweede stap. Een autorisatiesessie verkrijgen:
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 is de versie van het JSON-RPC-protocol dat wordt gebruikt;
Zabbix implementeert JSON-RPC versie 2.0;
- methode - de methode die wordt aangeroepen;
- params - parameters die door de methode worden doorgegeven;
- id is een willekeurige verzoekidentificatie;
- auth - gebruikersverificatiesleutel; Omdat we het nog niet hebben, laten we het op nul zetten.
Om met de API te werken heb ik een apart account aangemaakt met beperkte rechten. Ten eerste hoeft u geen toegang te verlenen tot waar dat niet nodig is. En ten tweede kon vóór versie 5.0 het wachtwoord dat via de macro was ingesteld, worden gelezen. Dienovereenkomstig, als u het Zabbix-beheerderswachtwoord gebruikt, is het beheerdersaccount gemakkelijk te stelen.
Dit zal vooral het geval zijn wanneer u met API werkt via scripts van derden en daarbij inloggegevens opslaat.
Sinds versie 5.0 is er een optie om het wachtwoord dat in de macro is opgeslagen te verbergen.
Wanneer u een apart account aanmaakt voor het bijwerken van gegevens via de API, controleer dan of de gegevens die u nodig heeft via de webinterface beschikbaar zijn en of het mogelijk is deze te updaten. Ik heb het niet gecontroleerd, en lange tijd begreep ik niet waarom de macro die ik nodig had niet zichtbaar was in de API.
Nadat we autorisatie in de API hebben ontvangen, gaan we verder met het verkrijgen van een lijst met macro's.
Stap 3
De API staat niet toe dat u een hostmacro op naam bijwerkt. U moet eerst de macro-ID verkrijgen. Om een lijst met macro's voor een specifieke host te krijgen, moet u bovendien de ID van deze host weten, en dit is een extra verzoek. Gebruik standaardmacro {HOST-ID} in het verzoek is niet toegestaan. Ik besloot de beperking als volgt te omzeilen:
Ik heb een lokale macro gemaakt met de ID van deze host. Het achterhalen van de host-ID is heel eenvoudig via de webinterface.
Een antwoord met een lijst van alle macro's op een bepaalde host kan worden gefilterd op een patroon:
regex:{"hostmacroid":"([0-9]+)"[A-z0-9,":]+"{$MIKROTIK_VERSION}"
Zo krijgen we de ID van de macro die we nodig hebben, waar MIKROTIK_VERSIE is de naam van de macro die we zoeken. In mijn geval wordt de macro doorzocht MIKROTIK_VERSIEDat is toegewezen aan de host.
Het verzoek zelf ziet er als volgt uit:
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
}
Variabel {sid} verkregen in de tweede stap en zal constant worden gebruikt, waarbij u met de API-interface moet werken.
Laatste 4 STAP - bijwerken van de macro
Nu weten we de macro-ID die moet worden bijgewerkt, de autorisatiecookie of de firmwareversie van de router. U kunt de macro zelf bijwerken.
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_versie} is de waarde die in de eerste stap is verkregen. In mijn voorbeeld de versie van de huidige mikrotik-firmware
{hostmacroid} - de waarde is verkregen in de derde stap - de id van de macro die we bijwerken.
Bevindingen
De aanpak om het probleem op te lossen met standaardfunctionaliteit is veel gecompliceerder en langer. Zeker als je verstand hebt van programmeren en snel de nodige logica in het script kunt toevoegen.
Het voor de hand liggende voordeel van deze aanpak is de "draagbaarheid" van de oplossing tussen verschillende servers.
Voor mij persoonlijk is het vreemd dat de HTTP-agent geen toegang heeft tot de gegevens van een ander item en deze kan vervangen in de verzoektekst of headers [ ].
Het voltooide sjabloon kan .
Bron: www.habr.com