Kliendile lahendust tehes tekkis 2 ülesannet, mida soovisin ilusti ja tavalise Zabbixi funktsionaalsusega lahendada.
1 väljakutse. Mikrotiku ruuterite praeguse püsivara versiooni jälgimine.
Ülesanne lahendatakse lihtsalt – HTTP mallile agendi lisamisega. Agent saab Mikrotiku veebisaidilt kehtiva versiooni ning päästik võrdleb praegust versiooni praegusega ja annab lahknevuse korral hoiatuse.
Kui teil on 10 ruuterit, pole selline algoritm kriitiline, kuid mida teha 3000 ruuteriga? Kas saata serverisse 3000 päringut? Muidugi, selline skeem töötab, kuid 3000 taotluse idee mulle ei sobinud, tahtsin leida mõne muu lahenduse. Lisaks oli sellisel algoritmil veel puudus: teine pool võib DoS-i rünnakuks kokku lugeda nii palju päringuid ühelt IP-lt, võib selle lihtsalt ära keelata.
2 väljakutse. Autoriseerimisseansi kasutamine erinevates HTTP-agentides.
Kui agent peab saama HTTP kaudu teavet "suletud" lehtedelt, on vaja autoriseerimisküpsist. Selleks on tavaliselt olemas standardne autoriseerimisvorm, millel on paar "sisselogimine / parool" ja seansi ID määramine küpsises.
Kuid on probleem, ühe HTTP-agendi üksuse kaudu on võimatu pääseda juurde teise üksuse andmetele, et seda väärtust päises asendada.
Samuti on olemas "Web script", sellel on veel üks piirang, see ei võimalda analüüsiks ja edasiseks salvestamiseks sisu hankida. Saate kontrollida ainult vajalike muutujate olemasolu lehtedel või edastada varem saadud muutujaid veebiskripti etappide vahel.
Olles nende ülesannete üle veidi mõelnud, otsustasin kasutada makrosid, mis on suurepäraselt nähtavad seiresüsteemi mis tahes osas: mallides, hostides, trigerites või üksustes. Ja makrosid saate värskendada veebiliidese API kaudu.
Zabbixil on hea ja üksikasjalik API dokumentatsioon. Andmevahetuseks API kaudu kasutatakse Jsoni andmevormingut. Üksikasjad leiate aadressilt .
Toimingute jada meile vajalike andmete saamiseks ja nende makrosse salvestamiseks on näidatud alloleval diagrammil.
Samm 1
Kõige esimene samm võib koosneda ühest toimingust või mitmest toimingust. Kogu põhiloogika pannakse paika esimestes sammudes ja viimased 3 sammu on peamised.
Minu näites oli esimene samm esimese ülesande jaoks PBX-i autoriseerimisküpsiste hankimine. Teise ülesande jaoks sain Mikrotiku püsivara praeguse versiooni numbri.
Mikrotiku püsivara praeguste versioonide URL
- - praeguse stabiilse versiooni URL-aadress
- — praeguse LTS-i versiooni URL-aadress
Mikrotiku seade ise pääseb neile aadressidele juurde, kui on vastu võetud uusim saadaolev püsivara versioon.
Esimene samm on iga juhtumi puhul täiesti individuaalne ja selle töö loogika võib olla erinev. Kõik sõltub teie ülesandest.
Veebiskriptimisega töötades jälgige, millist vastamismeetodit vajate. Pealkirjad HTTP vastus või ise тело vastus ilma päisteta?
Kui on vaja autoriseerimisküpsiseid, määrake vastamisviis Pealkirjad nagu Asteriski puhul.Kui vajate andmeid, nagu mikrotik serveri vastuse puhul, pange keha vastus ilma päisteta.
Samm 2
Liigume edasi teise sammu juurde. Autoriseerimisseansi saamine:
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 on JSON-RPC protokolli versioon, mida kasutatakse;
Zabbix rakendab JSON-RPC versiooni 2.0;
- meetod – meetod, mida kutsutakse;
- params - parameetrid, mis meetodi kaudu edastatakse;
- id on suvaline päringu identifikaator;
- auth – kasutaja autentimisvõti; kuna meil seda veel pole, siis määrame selle nulliks.
API-ga töötamiseks lõin eraldi konto piiratud õigustega. Esiteks ei pea te andma juurdepääsu sinna, kus te seda ei vaja. Ja teiseks sai enne versiooni 5.0 makro kaudu määratud parooli lugeda. Seega, kui kasutate Zabbixi administraatori parooli, on administraatori kontot lihtne varastada.
See kehtib eriti siis, kui töötate API-ga kolmanda osapoole skriptide kaudu ja salvestate mandaadid küljel.
Alates versioonist 5.0 on olemas võimalus peita makrosse salvestatud parool.
Andmete uuendamiseks API kaudu eraldi konto loomisel kontrolli kindlasti, kas vajalikud andmed on veebiliidese kaudu kättesaadavad ja kas neid on võimalik uuendada. Ma ei kontrollinud ja siis ei saanud ma pikka aega aru, miks minu vajalikku makrot API-s näha ei olnud.
Pärast API-s volituse saamist jätkame makrode loendi hankimisega.
Samm 3
API ei luba hostimakrot nime järgi värskendada, esmalt tuleb hankida makro ID. Veelgi enam, konkreetse hosti makrode loendi saamiseks peate teadma selle hosti ID-d ja see on lisataotlus. Kasuta vaikemakrot {HOST ID} taotluses ei ole lubatud. Otsustasin piirangust mööda minna järgmiselt:
Lõin selle hosti ID-ga kohaliku makro. Hosti ID väljaselgitamine on veebiliidese kaudu väga lihtne.
Vastust koos kõigi antud hosti makrode loendiga saab filtreerida mustri järgi:
regex:{"hostmacroid":"([0-9]+)"[A-z0-9,":]+"{$MIKROTIK_VERSION}"
Seega saame vajaliku makro ID, kus MIKROTIK_VERSION on otsitava makro nimi. Minu puhul otsitakse makrot MIKROTIK_VERSIONSee, mis määrati hostile.
Taotlus ise näeb välja selline:
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
}
Muutuv {sid} saadud teises etapis ja seda kasutatakse pidevalt, kus peate töötama API liidesega.
Viimane 4 SAMM – makro värskendamine
Nüüd teame värskendamist vajavat makro ID-d, autoriseerimisküpsist või ruuteri püsivara versiooni. Saate makrot ennast värskendada.
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} on esimeses etapis saadud väärtus. Minu näites praeguse mikrotik püsivara versioon
{hostmacroid} - väärtus saadi kolmandas etapis - värskendatava makro ID.
Järeldused
Standardfunktsionaalsusega probleemi lahendamise lähenemisviis on palju keerulisem ja pikem. Eriti kui oskad programmeerimist ja oskad kiiresti skripti vajalikku loogikat lisada.
Selle lähenemise ilmselgeks eeliseks on lahenduse "portatiivsus" erinevate serverite vahel.
Minu jaoks isiklikult on kummaline, et HTTP-agent ei pääse juurde mõne teise üksuse andmetele ja ei saa neid päringu kehas või päistes asendada [ ].
Valmis mall saab .
Allikas: www.habr.com