Zabbix - zgjeron kufijtë e makrave

Duke një zgjidhje për klientin, ndodhi që u shfaqën 2 detyra që do doja t'i zgjidhja bukur dhe me funksionalitetin standard të Zabbix.

Detyra 1. Monitorimi i versionit aktual të firmware-it në routerat Mikrotik.

Problemi zgjidhet lehtësisht duke shtuar në šablonin e agjentit HTTP. Agjenti merr versionin aktual nga faqja e Mikrotik, dhe një trigger krahason versionin aktual me atë të tanishëm dhe në rast të mospërputhjes jep një alarme.

Kur keni 10 routera, një algoritëm i tillë nuk është kritik, por çfarë të bëni me 3000 routera? Të dërgoni 3000 kërkesa në server? Sigurisht, ky skemë do të funksiononte, por ideja e 3000 kërkesave nuk më pëlqente, doja të gjeja një zgjidhje tjetër. Për më tepër, një disavantazh në një algoritëm të tillë ishte se pala tjetër mund ta konsiderojë këtë numër kërkesash nga një IP si një sulm DoS, dhe mund të bllokonte thjesht.

Detyra 2. Përdorimi i sesioneve të autentifikimit në agjentë të ndryshëm HTTP.

Kur përmes agjentit HTTP duhet të merrni informacion nga faqet "e mbyllura", ne na nevojitet një cookie autentifikimi. Për këtë zakonisht ekziston një formular standard autentifikimi me një palë «emër përdoruesi/faqe» dhe vendosja e ID-së së sesionit në cookie.

Por ekziston një problem, nuk mund të aksesoni të dhënat e një objekti të agjentit HTTP nga një objekt tjetër për të futur këtë vlerë në Header.

Ekziston gjithashtu "Skenari Web", i cili ka një kufizim tjetër, nuk lejon të merrni përmbajtjen për analizë dhe ruajtje të mëtejshme. Mund të kontrolloni vetëm praninë e variablave të nevojshëm në faqet ose të kaloni variablat e marra më parë ndërmjet hapjeve të skenarit web.

Pak duke menduar për këto detyra, vendosa të përdor makro që janë shumë të dukshme në çdo pjesë të sistemit të monitorimit: në šablone, hoste, trigger-e ose objekte. Dhe makrot mund të përditësohen përmes API të ndërfaqes web.

Zabbix ka një dokumentacion të mirë dhe të detajuar për API. Për shkëmbimin e të dhënave përmes API përdoret formati i të dhënave JSON. Mund të lexoni më shumë në dokumentacionin zyrtar.

Rrjedha e veprimeve për të marrë të dhënat që na duhen dhe regjistrimi i tyre në makro paraqiten në diagramin më poshtë.

Hapi 1

Hapi i parë mund të përbëhet nga një veprim ose shumë veprime. Në hapat e parë vendoset e gjithë logjika kryesore, dhe të fundit janë hapet kryesore.

Në shembullin tim, në hapat e parë u mor cookie i autentifikimit në ATS për detyrën e parë. Për detyrën e dytë, mora numrin e versionit aktual të firmware-it Mikrotik.

URL i versioneve më të fundit të firmware-it Mikrotik

• upgrade.mikrotik.com/routeros/LATEST.6 — URL adresa e versionit të stabilizuar aktual
• upgrade.mikrotik.com/routeros/LATEST.6fix — URL adresa e versionit LTS aktual

Këto adresat përdoren nga vetë pajisjet Mikrotik për të marrë versionin më të fundit të disponueshëm të firmware-it.

Hapi i parë është plotësisht individual për çdo rast dhe logjika e funksionit të tij mund të jetë e ndryshme. Gjithçka varet nga detyra juaj.

Kur punoni me skenarët web, ndihmoni se cilin metodë për marrjen e përgjigjes keni nevojë. Kryefjalet Përgjigjja HTTP ose vetë trupi i përgjigjes pa tituj?
Nëse ju nevojiten cookies të autorizimit, atëherë vendosni metodën e përgjigjes Kryefjalet si në rastin e Asterisk.

Nëse ju duhen të dhënat, si në rastin e përgjigjes nga serveri mikrotik, vendosni Trupi përgjigje pa tituj.

Hapi 2

Tani kalojmë në hapin e dytë. Marrja e sesionit të autorizimit:

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 — versioni i protokollit JSON-RPC që përdoret;
Zabbix implementon JSON-RPC versionin 2.0;

• method — metoda që thirret;
• params — parametrat që kalohen me metodën;
• id — një identifikues arbitrar i kërkesës;
• auth — çelësi i autorizimit të përdoruesit; pasi që ne nuk e kemi ende, do ta vendosim të barabartë me null.

Për të punuar me API kam krijuar një llogari të veçantë me të drejta të kufizuara. Në radhë të parë nuk duhet t'i jepni qasje atje ku s'ka nevojë. Dhe në të dytë, para versionit 5.0, çelësi i caktuar përmes makros mund të lexohej. Për pasoje, nëse përdorni fjalëkalimin e administratorit të Zabbix, llogarinë e administratorit është e lehtë ta vjedhësh.

Kjo do të jetë veçanërisht e rëndësishme kur punoni me API përmes skripteve të treta dhe ruani kredencialet në anën tjetër.

Me versionin 5.0 u shfaq një opsion 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 përmes API, sigurohuni se të dhënat që ju nevojiten janë të aksesueshme përmes ndërfaqes web dhe se përditësimi është i mundur. Unë nuk e verifikova, dhe më pas nuk mund të kuptoja për një kohë të gjatë pse makroja që më duhej nuk ishte e dukshme përmes API.

Pasi të keni marrë autorizimin në API, kalojmë në marrëveshjen e listës së makrove.

Hapi 3

API interfesi nuk lejon përditësimin e makros së hostit sipas emrit, për këtë nevojitet fillimisht të marrim ID-në e makros. Më tepër, për të marrë listën e makrosave të një hosti të caktuar, duhet të dimë ID-në e këtij hosti, e cila është një kërkesë shtesë. Përdorni makron standarde {HOST.ID} në kërkesë nuk mund të jetë. Kufizimin e kam zgjidhur kështu:

Unë krijova një makro lokale me ID-në e këtij hosti. Të mësosh ID-në e hostit është shumë e lehtë nga ndërfaqja web.

Përgjigjja me listën e të gjitha makrosave të këtij hosti mund të filtrohet sipas modelit:

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, po kërkohet makro MIKROTIK_VERSION, e cila ishte caktuar për hostin.

Kërkesa e vetme duket kështu:

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
}

Variabli {sid} e marrë në hapin e dytë dhe do të përdoret vazhdimisht, kudo që nevojitet të punojmë me interfesën API.

HAPI përfundimtar 4 — përditësimi i makros

Tani e dimë ID-në e makros që duhet të përditësojmë, kukun e autorizimit ose versionin e firmuerit të routerit. Mund të përditësojmë vetë makron.

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 marrë në hapin e parë. Në shembullin tim — versioni i aktualizuar i firmuerit mikrotik
{hostmacroid} është vlera e marrë në hapin e tretë — ID e makros, që po përditësojmë.

Përfundimet

Qasja në zgjidhjen e problemit me funksionalitetin standart është shumë më e komplikuar dhe e gjatë. Sidomos nëse e di programimin dhe mund të shkruash shpejt logjikën e nevojshme në skript.

Një përfitim i dukshëm i këtij qasjeje është "portabiliteti" i zgjidhjes mes serverëve të ndryshëm.

Për mua është e çuditshme mos të ketë mundësi të kesh qasje në të dhënat e një elementi tjetër në agjentin HTTP dhe t'i vendosësh ato në trupin e kërkesës ose në tituj [ ZBXNEXT-5993].

Shtesa e gatshme mund të shkarkohet në GitHub.

Burimi: habr.com