Při řešení pro zákazníka se objevily dva úkoly, které bylo možné vyřešit elegantně a pomocí standardní funkcionality Zabbix.
Úkol 1. Sledování aktuální verze firmwaru na routerech Mikrotik.
Úkol se snadno vyřeší — přidáním do šablony HTTP agenta. Agent získá aktuální verzi z webu Mikrotik a spouštěč porovnává aktuální verzi s tou stávající a v případě nesouladu vydává upozornění.
Když máte 10 routerů, takový algoritmus není kritický, ale co dělat se 3000 routery? Odesílat 3000 dotazů na server? Fungovat to samozřejmě bude, ale sama myšlenka 3000 dotazů mi nepřipadala optimální, chtěl jsem najít jiné řešení. Navíc, nevýhodou takového algoritmu je, že druhá strana může považovat takové množství dotazů z jedné IP adresy za DoS útok a mohou jednoduše zablokovat.
Úkol 2. Použití autorizační relace v různých HTTP agentech.
Když je potřeba získat informace z "uzavřených" stránek skrze HTTP agenta, je potřeba autentizační cookie. Obvykle existuje standardní forma autentizace s dvojicí "uživatelské jméno/heslo" a nastavením ID relace v cookie.
Ale je tu problém, není možné se z jednoho prvku HTTP agenta obrátit na data jiného prvku a vložit tuto hodnotu do záhlaví.
Existuje také "Webový skript", má jiná omezení, nedovoluje získat obsah pro analýzu a následné uložení. Lze pouze zkontrolovat přítomnost potřebných proměnných na stránkách nebo předávat dříve získané proměnné mezi kroky webového skriptu.
Po malém zamyšlení nad těmito úkoly jsem se rozhodl využít makra, která jsou skvěle viditelná v jakékoliv části monitorovacího systému: ve šablonách, hostech, spouštěčích nebo prvcích. A makra lze aktualizovat přes API webového rozhraní.
Zabbix má dobrou a podrobnou dokumentaci k API. Pro výměnu dat přes API se používá formát dat Json. Podrobně si o tom můžete přečíst v .
Pořadí akcí pro získání potřebných dat a jejich zápis do makra je znázorněno na schématu níže.
Krok 1
Nejprve krok se může skládat z jednoho nebo mnoha kroků. V prvních krocích je zapsána veškerá hlavní logika a klíčové jsou poslední 3 kroky.
V mém příkladu byl na prvním kroku proveden zisk autentizační cookie na PBX pro první úkol. Pro druhý úkol jsem získal číslo aktuální verze firmwaru Mikrotik.
URL aktuálních verzí firmwaru Mikrotik
- — URL adresa aktuální Stable verze
- — URL adresa aktuální LTS verze
K těmto adresám se přístroj Mikrotik sám obrací při získávání poslední dostupné verze firmwaru.
První krok je zcela individuální pro každý případ a logika jeho fungování se může lišit. Všechno závisí na vašem úkolu.
Při práci s webovými scénáři sledujte, jaká metoda získání odpovědi je potřeba. Hlavičky HTTP odpovědi nebo samotné tělo odpovědi bez hlaviček?
Pokud potřebujete autorizační cookies, nastavte metodu odpovědi Hlavičky stejně jako v případě Asterisku.Pokud potřebujete data, jako v případě odpovědi serveru Mikrotik, nastavte Tělo odpověď bez hlaviček.
Krok 2
Přejdeme k druhému kroku. Získání autorizační relace:
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 — verze protokolu JSON-RPC, která se používá;
Zabbix implementuje JSON-RPC verze 2.0;
- method — metoda, která se volá;
- params — parametry, které se předávají metodě;
- id — libovolný identifikátor požadavku;
- auth — klíč pro autentizaci uživatele; protože ho ještě nemáme, uvedeme ho jako null.
Pro práci s API jsem vytvořil samostatný účet s omezenými právy. Za prvé, není potřeba dávat přístup tam, kde není potřeba. A za druhé, do verze 5.0 bylo možné přečíst heslo nastavené prostřednictvím makra. Odpovídajícím způsobem, pokud byste použili heslo správce Zabbix, může být účet admina snadno ukraden.
To bude obzvláště aktuální, když pracujete s API přes externí skripty a uchováváte přihlašovací údaje na straně.
Od verze 5.0 byla přidána možnost skrýt heslo uložené v makru.
Když vytváříte samostatný účet pro aktualizaci dat přes API, důkladně zkontrolujte, zda jsou potřebná data dostupná prostřednictvím webového rozhraní a zda je možné je aktualizovat. Nezkontroloval jsem to, a pak jsem dlouho nemohl pochopit, proč nebylo potřebné makro viditelné přes API.
Poté, co jste získali autorizaci v API, přejdeme k získání seznamu makr.
Krok 3
API rozhraní neumožňuje aktualizovat makro hostitele podle jména, nejprve je nutné získat ID makra. Dále, pro získání seznamu makrů konkrétního hostitele, je třeba zjistit ID tohoto hostitele, což je navíc další dotaz. Použít standardní makro {HOST.ID} v dotazu není možné. Omezení jsem se rozhodl obejít takto:
Vytvořil jsem lokální makro s ID tohoto hostitele. Zjistit ID hostitele je velmi snadné z webového rozhraní.
Odpověď se seznamem všech makrů tohoto hostitele může být filtrována podle vzoru:
regex:{"hostmacroid":"([0-9]+)"[A-z0-9,":]+"{$MIKROTIK_VERSION}" 
Tímto způsobem získáváme ID požadovaného makra, kde MIKROTIK_VERSION — je název makra, které hledáme. V mém případě se hledá makro MIKROTIK_VERSION, které bylo přiřazeno k hostiteli.
Samotný dotaz vypadá 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
}
Proměnná {sid} získaná v druhém kroku a bude používána neustále, kdykoli je třeba pracovat s API rozhraním.
Konečný 4. KROK — aktualizace makra
Nyní známe ID makra, které je třeba aktualizovat, cookie autorizace nebo verzi firmwaru routeru. Můžeme aktualizovat samotné 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} — hodnota získaná v prvním kroku. V mém příkladu — verze aktuálního firmwaru mikrotik
{hostmacroid} — hodnota získaná ve třetím kroku — id makra, které aktualizujeme.
Závěry
Přístup k řešení úkolu standardní funkcionalitou je mnohem složitější a časově náročnější. Zvlášť když znáte programování a můžete rychle vytvořit potřebnou logiku ve skriptu.
Zřejmým přínosem tohoto přístupu je „přenositelnost“ řešení mezi různými servery.
Osobně mi přijde zvláštní absence možnosti obrátit se v HTTP agentovi na data jiného prvku a vložit je do těla dotazu nebo do hlaviček [ ].
Hotovou šablonu lze .
Zdroj: habr.com
