A kliens számára készített megoldás során két feladat merült fel, amelyeket szépen és a Zabbix beépített funkcióival szerettem volna megoldani.
1. feladat. A Mikrotik routerek firmware-jének aktuális verziójának nyomon követése.
A feladat könnyen megoldható - a HTTP ügynök sablonjához való hozzáadással. Az ügynök megszerzi az aktuális verziót a Mikrotik webhelyéről, a trigger pedig összehasonlítja az aktuális verziót a jelenlegivel, és eltérés esetén riasztást ad.
Amikor 10 routerrel rendelkezik, ez az algoritmus nem kritikus, de mi a helyzet 3000 routerrel? 3000 kérdést küldeni a szerverre? Persze, így működni fog, de az a gondolat, hogy 3000 kérdést küldjek, nem tetszett, valami más megoldást szerettem volna találni. Ráadásul ennek az algoritmusnak volt egy másik hátránya: a másik fél ilyen mennyiségű kérést egy IP-ről DoS támadásnak tekintheti, és egyszerűen letilthatja.
2. feladat. Az engedélyezési session használata különböző HTTP ügynökökben.
Amikor HTTP ügynökön keresztül információt kell szerezni 'zárt' oldalakról, szükség van egy engedélyezési sütire. Ehhez általában létezik egy szabványos bejelentkezési forma 'login/jelszó' párra, és a session ID-t a sütibe kell beállítani.
De van egy probléma, nem lehet egy HTTP ügynök item-ből elérni egy másik item adatait ennek az értéknek a Header-be való behelyettesítésére.
Van egy másik típus, a 'Web szkript', amelynek más korlátozása van, nem ad lehetőséget a tartalom megszerzésére elemzés és későbbi tárolás céljából. Csak a szükséges változók jelenlétét lehet ellenőrizni az oldalakon, vagy korábban már megszerzett változókat átadni a web szkript lépései között.
Ezeknek a feladatoknak a kicsit való átgondolása után úgy döntöttem, hogy makrókat használok, amelyek jól láthatóak a monitorozó rendszer bármely részén: sablonokban, hosztokban, triggerekben vagy itemekben. A makrókat pedig az API webes felületén keresztül lehet frissíteni.
A Zabbix jól részletes API dokumentációval rendelkezik. Az API-n való adatcseréhez JSON adatformátumot használnak. Részletesen olvasható itt: .
Az általunk szükséges adatok megszerzésének és makróba való rögzítésének lépései az alábbi ábrán láthatóak.
1. lépés
Az első lépés egyetlen műveletből vagy számos műveletből állhat. Az első lépésekben dől el az összes alapvető logika, a legfontosabbak az utolsó 3 lépés.
A példámban az első lépésként az engedélyezési süti beszerzése történt meg a PBX-hez az első feladat miatt. A második feladathoz pedig megszereztem a Mikrotik aktuális firmware verziójának számát.
A Mikrotik firmware legfrissebb verzióinak URL címe
- — A legfrissebb Stable verzió URL címe
- — A legfrissebb LTS verzió URL címe
Ezekre a címekre a Mikrotik berendezés maga hivatkozik, amikor lekéri a legutolsó elérhető firmware verziót.
Az első lépés teljesen egyedi minden esetben, és a működés logikája eltérő lehet. Minden a feladatától függ.
A webes szkriptek használatakor figyelje, hogy milyen válaszmegszerzési módszerre van szüksége. Fejlécek HTTP válasz vagy maga a válasz fejlécek nélkül?
Ha szükség van az autoriáló sütikre, akkor a válasz módszerét állítsa be Fejlécek mint az Asterisk esetében.Ha adatokra van szükség, mint a mikrotik szerver válasza esetében, állítsa be Test a válasz fejlécek nélkül.
2. lépés
Lépjünk a második lépéshez. Az authentikációs session megszerzése:
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 — a használt JSON-RPC protokoll verziója;
A Zabbix a JSON-RPC 2.0 verzióval valósítja meg;
- method — a hívott módszer;
- params — a módszeren keresztül továbbított paraméterek;
- id — a kérés tetszőleges azonosítója;
- auth — a felhasználó autentikálási kulcsa; mivel még nincs, állítsuk null-ra.
Az API használatához létrehoztam egy külön fiókot, korlátozott jogokkal. Egyrészt nem kell hozzáférést adni oda, ahová nem szükséges. Másrészt az 5.0 verzió előtt a makróban megadott jelszót el lehetett olvasni. Ennek megfelelően, ha a Zabbix adminisztrátor jelszavát használja, az admin fiókot könnyen ellophatják.
Ez különösen fontos, amikor harmadik fél szkripteken keresztül dolgozik az API-val, és az hitelesítő adatokat a szerveren tárolja.
Az 5.0 verzió óta megjelent a lehetőség a makróban tárolt jelszó elrejtésére.
Amikor külön fiókot hoz létre az API-n keresztüli adatok frissítésére, feltétlenül ellenőrizze, hogy az igényelt adatok elérhetők-e a webes felületen, és hogy azok frissítése lehetséges-e. Én nem ellenőriztem, és később sokáig nem értettem, miért nem látható a szükséges makró az API-n.
Miután megszereztük az autentikációt az API-n, lépjünk tovább a makrók listájának megszerzésére.
3. lépés
Az API felület nem teszi lehetővé a gazda makró frissítését név alapján, ehhez először meg kell szerezni a makró ID-jét. Ráadásul a konkrét gazda makróinak listájának megszerzéséhez ismerni kell a gazda ID-jét, ami további kérést jelent. Használja a beépített makrót. {HOST.ID} a kérésben nem lehetséges. A korlátozást úgy kerüljük meg:
Helyi makrót hoztam létre ennek a gazdának az ID-jével. A gazda ID-jét nagyon könnyen megtudhatja a webes felületen.
A válasz a kérdéses gazda összes makrójának listájáról mintázat alapján szűrhető:
regex:{"hostmacroid":"([0-9]+)"[A-z0-9,":]+"{$MIKROTIK_VERSION}" 
Így megkapjuk a szükséges makró ID-ját, ahol MIKROTIK_VERSION — a keresett makró neve. Az én esetemben a makró keresése történik MIKROTIK_VERSION, amely a gazdához lett rendelve.
A kérés így néz ki:
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
}
Változó {sid} a második lépésben lett megszerezve és folyamatosan használni fogják az API interfésszel való munkához.
A végső 4. LÉPÉS — a makró frissítése
Most már tudjuk a makró ID-jét, amelyet frissíteni kell, a hitelesítési süti vagy a router firmware verziója. A makró frissítése most már lehetséges.
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} — az első lépésben megszerzett érték. Az én példámban — a mikrotik aktuális firmware verziója
{hostmacroid} — az érték, amit a harmadik lépésben kaptunk — a frissítendő makró ID-ja.
Következtetések
A feladat megoldási megközelítése a beépített funkcionálisan sokkal bonyolultabb és hosszabb. Főleg, ha tudja a programozást és gyorsan képes a szükséges logikát megvalósítani egy szkripttel.
Ennek a megközelítésnek a nyilvánvaló előnye a megoldás "átjárhatósága" különböző szerverek között.
Személy szerint furcsának találom, hogy nincs lehetőség HTTP ügynökben egy másik elem adataihoz hozzáférni, és azokat a kérés törzsében vagy fejlécében behelyettesíteni [ ].
A kész sablon letölthető .
Forrás: habr.com
