När jag gjorde en lösning för en kund uppstod 2 uppgifter som jag ville lösa snyggt och med vanlig Zabbix-funktionalitet.
Uppgift 1 Spårar den aktuella firmwareversionen på Mikrotik-routrar.
Uppgiften löses enkelt - genom att lägga till en agent i HTTP-mallen. Agenten får den aktuella versionen från Mikrotik-webbplatsen, och utlösaren jämför den aktuella versionen med den nuvarande och utfärdar en varning vid avvikelse.
När man har 10 routrar är en sådan algoritm inte kritisk, men vad ska man göra med 3000 routrar? Skicka 3000 förfrågningar till servern? Naturligtvis kommer ett sådant system att fungera, men själva idén med 3000 förfrågningar passade inte mig, jag ville hitta en annan lösning. Dessutom fanns det fortfarande en nackdel med en sådan algoritm: den andra sidan kan räkna ett sådant antal förfrågningar från en IP för en DoS-attack, de kan helt enkelt förbjuda det.
Uppgift 2 Använda en auktoriseringssession i olika HTTP-agenter.
När en agent behöver ta emot information från "stängda" sidor via HTTP, behövs en auktoriseringscookie. För att göra detta finns det vanligtvis en standard auktoriseringsblankett med ett "login / lösenord"-par och inställning av sessions-ID i cookien.
Men det finns ett problem, det är omöjligt att komma åt data från ett annat objekt från ett HTTP-agentobjekt för att ersätta detta värde i Headern.
Det finns också ett "Web script", det har en annan begränsning, det tillåter dig inte att få innehåll för analys och ytterligare besparing. Du kan bara kontrollera förekomsten av nödvändiga variabler på sidorna eller skicka tidigare mottagna variabler mellan webbskriptstegen.
Efter att ha funderat lite över dessa uppgifter bestämde jag mig för att använda makron som är perfekt synliga i vilken del av övervakningssystemet som helst: i mallar, värdar, triggers eller objekt. Och du kan uppdatera makron via webbgränssnittets API.
Zabbix har bra och detaljerad API-dokumentation. För datautbyte via api används dataformatet Json. Detaljer finns i .
Sekvensen av åtgärder för att erhålla de data vi behöver och registrera dem i ett makro visas i diagrammet nedan.
Steg 1
Det allra första steget kan bestå av en enda handling eller flera åtgärder. All huvudlogik läggs i de första stegen, och de sista 3 stegen är de viktigaste.
I mitt exempel var det första steget att få auktoriseringscookies på växeln för den första uppgiften. För den andra uppgiften fick jag numret på den aktuella versionen av Mikrotik-firmware.
URL till aktuella versioner av Mikrotik firmware
- - URL-adress för den aktuella stabila versionen
- — URL-adress för den aktuella LTS-versionen
Dessa adresser nås av Mikrotik-utrustningen själv när den senaste tillgängliga firmwareversionen tas emot.
Det första steget är helt individuellt för varje fall och logiken i dess arbete kan vara annorlunda. Allt beror på din uppgift.
När du arbetar med webbskript, håll koll på vilken svarsmetod du behöver. Titlar HTTP-svar eller själv тело svar utan rubriker?
Om auktoriseringscookies behövs ställer du in svarsmetoden Titlar som i fallet med Asterisk.Om du behöver data, som i fallet med mikrotik-serverns svar, sätt kropp svar utan rubriker.
Steg 2
Låt oss gå vidare till det andra steget. Få en auktoriseringssession:
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 är versionen av JSON-RPC-protokollet som används;
Zabbix implementerar JSON-RPC version 2.0;
- metod - metoden som kallas;
- params - parametrar som skickas av metoden;
- id är en godtycklig begärandeidentifierare;
- auth - användarautentiseringsnyckel; eftersom vi inte har det ännu, låt oss ställa in det på null.
För att arbeta med API:t skapade jag ett separat konto med begränsade rättigheter. För det första behöver du inte ge tillgång till där du inte behöver. Och för det andra, innan version 5.0, kunde lösenordet som satts genom makrot läsas. Följaktligen, om du använder Zabbix administratörslösenord, är administratörskontot lätt att stjäla.
Detta kommer att vara särskilt sant när man arbetar med API genom tredjepartsskript och lagrar referenser vid sidan av.
Sedan version 5.0 finns det ett alternativ att dölja lösenordet som sparats i makrot.
När du skapar ett separat konto för att uppdatera data via API:t, se till att kontrollera om den data du behöver är tillgänglig via webbgränssnittet och om det är möjligt att uppdatera den. Jag kollade inte, och sedan kunde jag länge inte förstå varför makrot jag behövde inte var synligt i API:et.
Efter att vi har fått auktorisering i API:t fortsätter vi för att få en lista med makron.
Steg 3
API:et tillåter inte att du uppdaterar ett värdmakro efter namn, du måste först skaffa makro-ID. Dessutom, för att få en lista över makron för en specifik värd, måste du känna till ID:t för denna värd, och detta är en extra begäran. Använd standardmakro {VÄRD-ID} i begäran är inte tillåtet. Jag bestämde mig för att kringgå begränsningen så här:
Jag skapade ett lokalt makro med denna värds ID. Att ta reda på värd-ID:t är mycket enkelt från webbgränssnittet.
Ett svar med en lista över alla makron på en given värd kan filtreras med ett mönster:
regex:{"hostmacroid":"([0-9]+)"[A-z0-9,":]+"{$MIKROTIK_VERSION}"
Således får vi ID för makrot vi behöver, var MIKROTIK_VERSION är namnet på makrot vi letar efter. I mitt fall söks makrot MIKROTIK_VERSIONDen som tilldelades värden.
Själva begäran ser ut så här:
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} erhålls i det andra steget och kommer att användas ständigt, där du behöver arbeta med API-gränssnittet.
Sista 4 STEG - uppdatering av makrot
Nu vet vi vilket makro-ID som behöver uppdateras, auktoriseringscookien eller firmwareversionen av routern. Du kan uppdatera själva makrot.
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} är det värde som erhölls i det första steget. I mitt exempel, versionen av den aktuella mikrotik-firmwaren
{hostmacroid} - värdet erhölls i det tredje steget - ID för makrot som vi uppdaterar.
Resultat
Tillvägagångssättet för att lösa problemet med standardfunktionalitet är mycket mer komplicerat och längre. Speciellt om du kan programmering och snabbt kan lägga till nödvändig logik i skriptet.
Den uppenbara fördelen med detta tillvägagångssätt är lösningens "portabilitet" mellan olika servrar.
För mig personligen är det märkligt att HTTP-agenten inte kan komma åt data från ett annat objekt och ersätta dem i förfrågningstexten eller rubrikerna [ ].
Den färdiga mallen kan .
Källa: will.com