Egy kliensnek megoldás készítése során 2 feladat merült fel, amit szépen és rendes Zabbix funkcionalitással szerettem volna megoldani.
1 kihívás. Az aktuális firmware-verzió nyomon követése Mikrotik útválasztókon.
A feladat egyszerűen megoldható – ügynök hozzáadásával a HTTP-sablonhoz. Az ügynök a Mikrotik webhelyről kapja meg az aktuális verziót, a trigger pedig összehasonlítja az aktuális verziót a jelenlegivel, és eltérés esetén riasztást ad ki.
Ha 10 útválasztója van, egy ilyen algoritmus nem kritikus, de mit kell tenni 3000 útválasztóval? 3000 kérést küld a szervernek? Természetesen egy ilyen séma működni fog, de maga a 3000 kérés ötlete nem jött be, más megoldást akartam találni. Ráadásul még mindig volt egy hátránya egy ilyen algoritmusnak: a másik oldal ennyi kérést számolhat egy IP-ről egy DoS támadáshoz, egyszerűen letilthatja.
2 kihívás. Engedélyezési munkamenet használata különböző HTTP-ügynökökben.
Ha egy ügynöknek HTTP-n keresztül információkat kell kapnia a "zárt" oldalakról, akkor engedélyezési cookie-ra van szükség. Ehhez általában van egy szabványos engedélyezési űrlap, amely egy "bejelentkezési / jelszó" párost tartalmaz, és a cookie-ban beállítja a munkamenet azonosítóját.
De van egy probléma, nem lehet elérni egy másik elem adatait egy HTTP-ügynök elemből, hogy ezt az értéket a fejlécben helyettesítse.
Létezik "Web script" is, ennek van még egy korlátja, nem teszi lehetővé, hogy elemzésre és további mentésre alkalmas tartalmat kapjon. Csak a szükséges változók meglétét ellenőrizheti az oldalakon, vagy átadhatja a korábban kapott változókat a webszkript lépései között.
Miután kicsit átgondoltam ezeket a feladatokat, úgy döntöttem, hogy olyan makrókat használok, amelyek tökéletesen láthatóak a megfigyelő rendszer bármely részében: sablonokban, gazdagépekben, triggerekben vagy elemekben. A makrókat pedig a webes felület API-n keresztül frissítheti.
A Zabbix jó és részletes API-dokumentációval rendelkezik. Az API-n keresztüli adatcseréhez a Json adatformátumot használják. A részletek megtalálhatók a .
A szükséges adatok megszerzéséhez és makróba való rögzítéséhez szükséges műveletek sorrendjét az alábbi diagram mutatja.
Lépés 1
A legelső lépés egy vagy több műveletből állhat. Az összes fő logika az első lépésekben van lefektetve, és az utolsó 3 lépés a fő.
Példámban az első lépés az volt, hogy engedélyező sütiket kaptam az alközponton az első feladathoz. A második feladathoz megkaptam az aktuális Mikrotik firmware verziószámát.
A Mikrotik firmware aktuális verzióinak URL-je
- - Az aktuális stabil verzió URL-címe
- — az aktuális LTS-verzió URL-címe
Ezeket a címeket maga a Mikrotik berendezés éri el, amikor megkapja a legújabb elérhető firmware-verziót.
Az első lépés minden esetben teljesen egyedi, és a munka logikája eltérő lehet. Minden a feladatától függ.
Amikor webes szkriptekkel dolgozik, kövesse nyomon, hogy melyik válaszmódszerre van szüksége. Címsorok HTTP válasz vagy önmaga тело válasz fejléc nélkül?
Ha engedélyezési cookie-kra van szükség, állítsa be a válaszmódot Címsorok mint az Asterisk esetében.Ha adatokra van szüksége, mint a mikrotik szerver válasz esetén, tegye test válasz fejlécek nélkül.
Lépés 2
Térjünk át a második lépésre. Engedélyezési munkamenet lekéré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 JSON-RPC protokoll használt verziója;
A Zabbix a JSON-RPC 2.0-s verzióját valósítja meg;
- metódus – az elnevezett metódus;
- params - a metódus által átadott paraméterek;
- id egy tetszőleges kérésazonosító;
- auth - felhasználói hitelesítési kulcs; mivel még nincs meg, állítsuk nullára.
Az API használatához külön fiókot hoztam létre korlátozott jogokkal. Először is, nem kell hozzáférést adnia oda, ahol nem kell. Másodszor, az 5.0-s verzió előtt a makrón keresztül beállított jelszó olvasható volt. Ennek megfelelően, ha a Zabbix rendszergazdai jelszót használja, az adminisztrátori fiók könnyen ellopható.
Ez különösen igaz, ha az API-val harmadik féltől származó szkripteken keresztül dolgozik, és a hitelesítő adatokat az oldalon tárolja.
Az 5.0-s verzió óta lehetőség van a makróba mentett jelszó elrejtésére.
Amikor külön fiókot hoz létre az adatok API-n keresztüli frissítéséhez, mindenképpen ellenőrizze, hogy a szükséges adatok elérhetőek-e a webes felületen keresztül, illetve lehetséges-e a frissítés. Nem ellenőriztem, aztán sokáig nem értettem, miért nem látható az API-ban a szükséges makró.
Miután megkaptuk az engedélyt az API-ban, folytatjuk a makrók listájának lekérését.
Lépés 3
Az API nem teszi lehetővé a gazdagép makró név szerinti frissítését, először meg kell szereznie a makró azonosítóját. Sőt, egy adott gazdagéphez tartozó makrók listájának megtekintéséhez ismernie kell ennek a gazdagépnek az azonosítóját, és ez egy extra kérés. Használja az alapértelmezett makrót {HOST ID} a kérésben nem megengedett. Úgy döntöttem, hogy megkerülöm a korlátozást a következőképpen:
Létrehoztam egy helyi makrót ennek a gazdagépnek az azonosítójával. A gazdagép azonosítójának megállapítása nagyon egyszerű a webes felületről.
Az adott gazdagépen található összes makró listáját tartalmazó válasz minta alapján szűrhető:
regex:{"hostmacroid":"([0-9]+)"[A-z0-9,":]+"{$MIKROTIK_VERSION}"
Így megkapjuk a szükséges makró azonosítóját, hol MIKROTIK_VERSION a keresett makró neve. Az én esetemben a makrót keresik MIKROTIK_VERSIONA gazdához lett rendelve.
Maga 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 kapjuk meg és folyamatosan használják, ahol az API felülettel kell dolgozni.
Utolsó 4 LÉPÉS – a makró frissítése
Most már tudjuk a frissítendő makróazonosítót, az engedélyezési cookie-t vagy az útválasztó firmware-verzióját. Frissítheti magát a makrót.
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 kapott érték. Példámban a jelenlegi mikrotik firmware verziója
{hostmacroid} - az értéket a harmadik lépésben kaptuk meg - a makró azonosítóját, amelyet frissítünk.
Álláspontja
A probléma szabványos funkcionalitással történő megoldásának megközelítése sokkal bonyolultabb és hosszabb. Főleg, ha ismeri a programozást, és gyorsan hozzá tudja adni a szükséges logikát a szkripthez.
Ennek a megközelítésnek a nyilvánvaló előnye a megoldás „hordozhatósága” a különböző szerverek között.
Számomra személy szerint furcsa, hogy a HTTP-ügynök nem tud hozzáférni egy másik elem adataihoz, és nem tudja behelyettesíteni azokat a kérés törzsében vagy fejlécében [ ].
A kész sablon lehet .
Forrás: will.com