Kliendi lahenduse loomisel tekkis kaks ülesannet, mida sooviti lahendada kaunilt ja Zabbixi standardfunktsionaalsusega.
Ülesanne 1. Mikrotiki ruuteri tarkvara versiooni jälgimine.
Ülesanne lahendatakse lihtsalt — lisades HTTP-agendi mallile. Agent hangib versiooni Mikrotiki veebisaidilt ja triggereid võrreldakse ajakohastatud versiooni praegusega; erinevuse korral saadetakse häire.
Kui teil on 10 ruuterit, ei ole selline algoritm kriitiline, kuid mida teha 3000 ruuteriga? Saata 3000 päringut serverisse? Töötab, muidugi, selline skeem, kuid 3000 päringu idee ei rahuldanud mind; soovisin leida teistsuguse lahenduse. Lisaks oli sellise algoritmi puhul siiski puudus: teine pool võib sellise päringute hulga ühelt IP-lt DoS-rünnakuks lugeda ja lihtsalt blokida.
Ülesanne 2. Autentimisseansi kasutamine erinevates HTTP-agentides.
Kui HTTP-agendi kaudu on vaja teavet "suletud" lehtedelt saada, on vajalik autentimisküpsis. Selleks on tavaliselt olemas standardne autentimisvorm koos „kasutajanime/parooliga” ja seansi ID-seadmisega küpsisesse.
Kuid on probleem, et ühe HTTP-agendi elemendist ei saa pöörduda teise elemendi andmete poole, et asendada see väärtus päises.
On veel "Veebistseen", millel on erinev piirang, see ei luba saada sisu analüüsimiseks ja edasiseks salvestamiseks. Saame vaid kontrollida, kas vajalikud muutujad on lehtedel olemas või edastada eelnevalt saadud muutujaid veebistseeni vahel.
Pärast nende ülesannete üle järele mõtlemist otsustasin kasutada makrosid, mis on hästi nähtavad süsteemi seire igas osas: mallides, hostides, käivitajates või elementides. Makrosid saab uuendada ka veebiliidese API kaudu.
Zabbixil on hea ja põhjalik dokumentatsioon API kohta. Andmevahetuseks API kaudu kasutatakse JSON-formaati. Üksikasjalikult saab lugeda .
Õigetelt andmete saamise ja nende salvestamise järjestus makrosse on esitatud alloleval skeemil.
Samm 1
Esimene samm võib koosneda ühest tegevusest või paljusid tegevusi. Esimestesse sammudesse on sisse kirjutatud kogu põhiloogika, kõige olulisemad on viimased 3 sammu.
Minu näites sai esimeses etapis saadud autoriseerimise küpsised Asteriskis esimese ülesande jaoks. Teise ülesande jaoks sain Mikrotik'i praeguse tarkvaraversiooni numbri.
Mikrotik'i tarkvaraversioonide URL
- — Stabiilse versiooni URL
- — LTS versiooni URL
Need aadressid saavad kasutada ise Mikrotik'i seadmed, et saada viimast saadaval tarkvaraversiooni.
Esimene samm on täielikult individuaalne ja selle toimimisloogika võib olla erinev. Kõik sõltub teie ülesandest.
Veebiskripte töötades jälgige, millist vastuse saamise meetodit vajate. Pealkirjad HTTP vastusest või keha vastusest ilma pealkirjadeta?
Kui vajate autoriseerimise küpsiseid, seadke vastuse meetod sarnaselt Asteriskiga. Pealkirjad Kui vajate andmeid, nagu Mikrotik'i serveri vastuse korral, seadkeVastuse keha ilma pealkirjadeta. Liigume teise sammu juurde. Autoriseerimise sessiooni saamine:
Samm 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 — kasutatav JSON-RPC protokolli versioon;jsonrpc — версия протокола JSON-RPC, которая используется;
Zabbix rakendab JSON-RPC versiooni 2.0;
- method — meetod, mida kutsutakse välja;
- params — parameetrid, mis edastatakse meetodile;
- id — juhuslik identifikaator päringu jaoks;
- auth — kasutaja autentimise võti; kuna meil ei ole seda veel, määrame selle nulliks.
API kasutamiseks olen loonud eraldi konto piiratud õigustega. Esiteks ei ole mõtet anda ligipääsu sinna, kuhu ei ole vaja. Teiseks, enne versiooni 5.0 sai makro kaudu määratud parooli lugeda. Seega, kui kasutada administraatori Zabbixi parooli, on administraatori konto kergesti varastatav.
See on eriti oluline, kui töötate API-ga läbi kolmandate osapoolte skriptide ja hoiate sisselogimisandmeid küljes.
Alates versioonist 5.0 on lisatud võimalus peita makrosse salvestatud parool.
Kui loote eraldi konto andmete värskendamiseks API kaudu, kontrollige kindlasti, kas veebiliidese kaudu on teie vajalikele andmetele ligipääs ja kas nende värskendamine on võimalik. Ma ei kontrollinud seda ja hiljem ei saanud aru, miks pole API-s nähtavat vajalikku makrot.
Pärast API-s autoriseerimise saamist läheme makrode loendi saamiseks.
Samm 3
API liides ei võimalda hosti makro nime järgi uuendada, selleks tuleb kõigepealt saada makro ID. Lisaks, et saada konkreetse hosti makrode loend, tuleb teada hosti ID-d, mis tähendab lisapära. Kasutage tavalist makrot. {HOST.ID} päringus ei saa. Piirangu ületamiseks tegin nii:
Loonud kohandatud makro, millel on selle hosti ID. Host'i ID-d on veebiliidesest väga lihtne saada.
Vastus kõigi selle hosti makrode loendiga saab filtreerida mustri järgi:
regex:{"hostmacroid":"([0-9]+)"[A-z0-9,":]+"{$MIKROTIK_VERSION}" 
Nii saame vajalikku makro ID-d, kus MIKROTIK_VERSION on makro nimi, mida me otsime. Minu puhul otsitakse makrot MIKROTIK_VERSION, mis oli määratud hostile.
Kogu päring näeb välja nii:
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
}
Muutuja {sid} saab teisel sammul ja seda kasutatakse pidevalt, kus tuleb API liidesega töötada.
Lõplik 4. SAMM — makro uuendamine
Nüüd teame makro ID-d, mida tuleb uuendada, volitus küpsist või ruuteri firmware'i versioon. Saame makrot uuendada.
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} — väärtus, mis saadi esimeses etapis. Minu näites — Mikrotiki käivitusversioon
{hostmacroid} — väärtus, mis saadi kolmandas etapis — makro ID, mida uuendame.
Järeldused
Probleemi lahendamine tavapärase funktsionaalsusega on märgatavalt keerulisem ja aeganõudvam. Eriti kui tunned programmeerimist ja saad kiiresti vajaliku loogika skriptis üles ehitada.
Selle lähenemise ilmne eelis on lahenduse „portatiivsuse“ võimalus erinevate serverite vahel.
Isiklikult on mulle imelik, et HTTP-agent võimaldab teise esemega seotud andmetele juurde pääseda ja sisestada need päringu või päiste kehasse [ ].
Valmis mall on võimalik .
Allikas: habr.com
