Pri robení riešenia pre klienta vyvstali 2 úlohy, ktoré som chcel vyriešiť krásne a s bežnou funkcionalitou Zabbix.
Úloha 1. Sledovanie aktuálnej verzie firmvéru na smerovačoch Mikrotik.
Úloha je vyriešená jednoducho – pridaním agenta do HTTP šablóny. Agent dostane aktuálnu verziu z webu Mikrotik a spúšťač porovná aktuálnu verziu s aktuálnou a v prípade nezrovnalosti vydá upozornenie.
Keď máte 10 smerovačov, takýto algoritmus nie je kritický, ale čo robiť s 3000 smerovačmi? Odoslať 3000 požiadaviek na server? Takáto schéma bude samozrejme fungovať, ale samotná myšlienka 3000 žiadostí mi nevyhovovala, chcel som nájsť iné riešenie. Okrem toho mal takýto algoritmus ešte jednu nevýhodu: druhá strana dokáže spočítať taký počet žiadostí z jednej IP na DoS útok, môže ho jednoducho zakázať.
Úloha 2. Použitie relácie autorizácie v rôznych agentoch HTTP.
Keď agent potrebuje prijímať informácie z „uzavretých“ stránok cez HTTP, je potrebný autorizačný súbor cookie. Na tento účel zvyčajne existuje štandardný autorizačný formulár s párom „login / password“ a nastavením ID relácie v súbore cookie.
Je tu však problém, nie je možné získať prístup k údajom inej položky z jednej položky agenta HTTP a nahradiť túto hodnotu v hlavičke.
Existuje aj "Webový skript", má ďalšie obmedzenie, neumožňuje získať obsah na analýzu a ďalšie ukladanie. Môžete len skontrolovať prítomnosť potrebných premenných na stránkach alebo odovzdať predtým získané premenné medzi krokmi webového skriptu.
Keď som sa nad týmito úlohami trochu zamyslel, rozhodol som sa použiť makrá, ktoré sú dokonale viditeľné v akejkoľvek časti monitorovacieho systému: v šablónach, hostiteľoch, spúšťačoch alebo položkách. A makrá môžete aktualizovať prostredníctvom rozhrania API webového rozhrania.
Zabbix má dobrú a podrobnú dokumentáciu API. Na výmenu dát cez api sa používa dátový formát Json. Podrobnosti nájdete v .
Postupnosť akcií na získanie potrebných údajov a ich zaznamenanie do makra je znázornená na obrázku nižšie.
Krok 1
Úplne prvý krok môže pozostávať z jednej akcie alebo viacerých akcií. Všetka hlavná logika je položená v prvých krokoch a posledné 3 kroky sú hlavné.
V mojom príklade bolo prvým krokom získanie autorizačných cookies na PBX pre prvú úlohu. Pri druhej úlohe som dostal číslo aktuálnej verzie firmvéru Mikrotik.
URL aktuálnych verzií firmvéru Mikrotik
- - URL adresa aktuálnej stabilnej verzie
- — URL adresa aktuálnej verzie LTS
K týmto adresám pristupuje samotné zariadenie Mikrotik po prijatí najnovšej dostupnej verzie firmvéru.
Prvý krok je pre každý prípad úplne individuálny a logika jeho práce môže byť iná. Všetko závisí od vašej úlohy.
Pri práci s webovým skriptovaním sledujte, aký spôsob odozvy potrebujete. tituly HTTP odpoveď alebo self тело odpoveď bez hlavičiek?
Ak sú potrebné autorizačné súbory cookie, nastavte spôsob odpovede tituly ako v prípade Asterisk.Ak potrebujete údaje, ako v prípade odpovede mikrotik servera, vložte telo odpoveď bez hlavičiek.
Krok 2
Prejdime k druhému kroku. Získanie relácie autorizácie:
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 je verzia protokolu JSON-RPC, ktorá sa používa;
Zabbix implementuje JSON-RPC verzie 2.0;
- metóda - metóda, ktorá sa volá;
- params - parametre, ktoré sa odovzdávajú metódou;
- id je ľubovoľný identifikátor požiadavky;
- auth - autentifikačný kľúč užívateľa; keďže ho ešte nemáme, nastavíme ho na null.
Pre prácu s API som vytvoril samostatný účet s obmedzenými právami. Po prvé, nemusíte poskytovať prístup tam, kde to nepotrebujete. A po druhé, pred verziou 5.0 bolo možné prečítať heslo nastavené cez makro. Ak teda použijete heslo správcu Zabbix, účet správcu sa dá ľahko ukradnúť.
To bude platiť najmä pri práci s API prostredníctvom skriptov tretích strán a ukladaní poverení na strane.
Od verzie 5.0 existuje možnosť skryť heslo uložené v makre.
Pri vytváraní samostatného účtu na aktualizáciu údajov cez API si nezabudnite skontrolovať, či sú potrebné údaje dostupné cez webové rozhranie a či je možné ich aktualizovať. Nekontroloval som to a potom som dlho nemohol pochopiť, prečo makro, ktoré som potreboval, nebolo viditeľné v rozhraní API.
Po získaní autorizácie v rozhraní API pristúpime k získaniu zoznamu makier.
Krok 3
Rozhranie API vám neumožňuje aktualizovať hostiteľské makro podľa názvu, najprv musíte získať ID makra. Okrem toho, ak chcete získať zoznam makier pre konkrétneho hostiteľa, musíte poznať ID tohto hostiteľa, a to je dodatočná požiadavka. Použiť predvolené makro {HOST ID} v žiadosti nie je povolené. Rozhodol som sa obísť obmedzenie takto:
Vytvoril som lokálne makro s ID tohto hostiteľa. Zistenie ID hostiteľa je veľmi jednoduché z webového rozhrania.
Odpoveď so zoznamom všetkých makier na danom hostiteľovi možno filtrovať podľa vzoru:
regex:{"hostmacroid":"([0-9]+)"[A-z0-9,":]+"{$MIKROTIK_VERSION}"
Takto získame ID makra, ktoré potrebujeme, kde MIKROTIK_VERSION je názov makra, ktoré hľadáme. V mojom prípade sa makro hľadá MIKROTIK_VERSIONTá bola pridelená hostiteľovi.
Samotná žiadosť vyzerá takto:
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
}
Variabilné {sid} získané v druhom kroku a budú sa používať neustále tam, kde potrebujete pracovať s rozhraním API.
Posledný 4 KROK - aktualizácia makra
Teraz poznáme ID makra, ktoré je potrebné aktualizovať, autorizačný súbor cookie alebo verziu firmvéru smerovača. Samotné makro môžete aktualizovať.
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} je hodnota získaná v prvom kroku. V mojom príklade je to verzia aktuálneho firmvéru mikrotiku
{hostmacroid} - hodnota bola získaná v treťom kroku - id makra, ktoré aktualizujeme.
Závery
Prístup k riešeniu problému štandardnou funkcionalitou je oveľa komplikovanejší a dlhší. Najmä ak ovládate programovanie a viete rýchlo pridať potrebnú logiku do skriptu.
Zjavnou výhodou tohto prístupu je „prenosnosť“ riešenia medzi rôznymi servermi.
Pre mňa osobne je zvláštne, že HTTP agent nemôže pristupovať k údajom inej položky a nahradiť ich v tele požiadavky alebo hlavičkách [ ].
Hotová šablóna môže .
Zdroj: hab.com