Kur bëra një zgjidhje për një klient, lindën 2 detyra që doja t'i zgjidhja bukur dhe me funksionalitet të rregullt Zabbix.
Detyra 1. Ndjekja e versionit aktual të firmuerit në ruterat Mikrotik.
Detyra zgjidhet lehtësisht - duke shtuar një agjent në shabllonin HTTP. Agjenti merr versionin aktual nga faqja e internetit e Mikrotik dhe aktivizuesi krahason versionin aktual me atë aktual dhe lëshon një alarm në rast mospërputhjeje.
Kur keni 10 rutera, një algoritëm i tillë nuk është kritik, por çfarë të bëni me 3000 ruterë? Të dërgohen 3000 kërkesa në server? Sigurisht që një skemë e tillë do të funksionojë, por vetë ideja e 3000 kërkesave nuk më përshtatej, doja të gjeja një zgjidhje tjetër. Për më tepër, kishte ende një pengesë në një algoritëm të tillë: pala tjetër mund të numërojë një numër të tillë kërkesash nga një IP për një sulm DoS, ata thjesht mund ta ndalojnë atë.
Detyra 2. Përdorimi i një sesioni autorizimi në agjentë të ndryshëm HTTP.
Kur një agjent duhet të marrë informacion nga faqet "të mbyllura" nëpërmjet HTTP, nevojitet një skedar autorizimi. Për ta bërë këtë, zakonisht ekziston një formular standard autorizimi me një çift "hyrje / fjalëkalim" dhe vendosjen e ID-së së sesionit në cookie.
Por ka një problem, është e pamundur të aksesosh të dhënat e një artikulli tjetër nga një artikull agjent HTTP për të zëvendësuar këtë vlerë në Header.
Ekziston edhe një "Web script", ai ka një kufizim tjetër, nuk ju lejon të merrni përmbajtje për analiza dhe ruajtje të mëtejshme. Mund të kontrolloni vetëm praninë e variablave të nevojshëm në faqe ose të kaloni variablat e marra më parë midis hapave të skriptit të uebit.
Pasi mendova pak për këto detyra, vendosa të përdor makro që janë krejtësisht të dukshme në çdo pjesë të sistemit të monitorimit: në shabllone, hoste, aktivizues ose artikuj. Dhe ju mund të përditësoni makro përmes API-së së ndërfaqes së uebit.
Zabbix ka dokumentacion të mirë dhe të detajuar API. Për shkëmbimin e të dhënave përmes api, përdoret formati i të dhënave Json. Detajet mund të gjenden në .
Sekuenca e veprimeve për marrjen e të dhënave që na nevojiten dhe regjistrimin e tyre në një makro tregohet në diagramin më poshtë.
Hapi 1
Hapi i parë mund të përbëhet nga një veprim i vetëm ose veprime të shumta. E gjithë logjika kryesore është hedhur në hapat e parë, dhe 3 hapat e fundit janë ato kryesore.
Në shembullin tim, hapi i parë ishte marrja e skedarëve të autorizimit në PBX për detyrën e parë. Për detyrën e dytë, mora numrin e versionit aktual të firmuerit Mikrotik.
URL-ja e versioneve aktuale të firmuerit Mikrotik
- - Adresa URL e versionit aktual Stabil
- — Adresa URL e versionit aktual LTS
Këto adresa aksesohen nga vetë pajisja Mikrotik kur merret versioni më i fundit i disponueshëm i firmuerit.
Hapi i parë është krejtësisht individual për çdo rast dhe logjika e punës së tij mund të jetë e ndryshme. E gjitha varet nga detyra juaj.
Kur punoni me skriptimin në ueb, mbani gjurmët se cila metodë përgjigjeje ju nevojitet. Titujt Përgjigja HTTP ose vetë trupin përgjigje pa kokë?
Nëse nevojiten skedarë të autorizimit, atëherë vendosni metodën e përgjigjes Titujt si në rastin e Asterisk.Nëse keni nevojë për të dhëna, si në rastin e përgjigjes së serverit mikrotik, vendosni Trupi përgjigje pa kokë.
Hapi 2
Le të kalojmë në hapin e dytë. Marrja e një seance autorizimi:
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 është versioni i protokollit JSON-RPC që po përdoret;
Zabbix zbaton JSON-RPC versionin 2.0;
- metoda - metoda që quhet;
- paramet - parametrat që kalohen nga metoda;
- id është një identifikues arbitrar i kërkesës;
- auth - çelësi i vërtetimit të përdoruesit; meqenëse nuk e kemi ende, le ta vendosim në null.
Për të punuar me API, kam krijuar një llogari të veçantë me të drejta të kufizuara. Së pari, nuk keni nevojë të jepni akses atje ku nuk keni nevojë. Dhe së dyti, para versionit 5.0, fjalëkalimi i vendosur përmes makro mund të lexohej. Prandaj, nëse përdorni fjalëkalimin e administratorit Zabbix, llogaria e administratorit është e lehtë për t'u vjedhur.
Kjo do të jetë veçanërisht e vërtetë kur punoni me API përmes skripteve të palëve të treta dhe ruani kredencialet në anën.
Që nga versioni 5.0 ekziston një mundësi për të fshehur fjalëkalimin e ruajtur në makro.
Kur krijoni një llogari të veçantë për përditësimin e të dhënave nëpërmjet API-së, sigurohuni që të kontrolloni nëse të dhënat që ju nevojiten janë të disponueshme përmes ndërfaqes së internetit dhe nëse është e mundur t'i përditësoni ato. Nuk kontrollova, dhe më pas për një kohë të gjatë nuk mund ta kuptoja pse makroja që më duhej nuk ishte e dukshme në API.
Pasi të kemi marrë autorizimin në API, ne vazhdojmë të marrim një listë të makrove.
Hapi 3
API nuk ju lejon të përditësoni një makro host me emër, së pari duhet të merrni ID-në e makro. Për më tepër, për të marrë një listë makrosh për një host specifik, duhet të dini ID-në e këtij hosti dhe kjo është një kërkesë shtesë. Përdorni makro të paracaktuar {ID HOST} në kërkesë nuk lejohet. Vendosa të anashkaloj kufizimin si ky:
Krijova një makro lokale me ID-në e këtij hosti. Gjetja e ID-së së hostit është shumë e lehtë nga ndërfaqja në internet.
Një përgjigje me një listë të të gjitha makrove në një host të caktuar mund të filtrohet nga një model:
regex:{"hostmacroid":"([0-9]+)"[A-z0-9,":]+"{$MIKROTIK_VERSION}"
Kështu, marrim ID-në e makros që na nevojitet, ku MIKROTIK_VERSION është emri i makros që po kërkojmë. Në rastin tim, makro është kërkuar MIKROTIK_VERSIONAjo që iu caktua nikoqirit.
Vetë kërkesa duket si kjo:
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
}
Ndryshore {sid} marrë në hapin e dytë dhe do të përdoret vazhdimisht, ku duhet të punoni me ndërfaqen API.
Hapi i fundit 4 - përditësimi i makro
Tani ne e dimë ID-në e makro që duhet përditësuar, cookie-n e autorizimit ose versionin e firmuerit të ruterit. Ju mund të përditësoni vetë makro.
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} është vlera e fituar në hapin e parë. Në shembullin tim, versioni i firmware-it aktual mikrotik
{hostmakroid} - vlera është marrë në hapin e tretë - ID-ja e makros që po përditësojmë.
Gjetjet
Qasja për zgjidhjen e problemit me funksionalitetin standard është shumë më e ndërlikuar dhe më e gjatë. Sidomos nëse dini programim dhe mund të shtoni shpejt logjikën e nevojshme në skenar.
Avantazhi i dukshëm i kësaj qasjeje është "transportueshmëria" e zgjidhjes midis serverëve të ndryshëm.
Për mua personalisht, është e çuditshme që agjenti HTTP nuk mund të hyjë në të dhënat e një artikulli tjetër dhe t'i zëvendësojë ato në trupin ose titujt e kërkesës [ ].
Shablloni i përfunduar mund .
Burimi: www.habr.com