Při tvorbě řešení pro klienta vyvstaly 2 úkoly, které jsem chtěl vyřešit krásně a s běžnou funkcionalitou Zabbix.
1 výzva. Sledování aktuální verze firmwaru na routerech Mikrotik.
Úloha je vyřešena jednoduše – přidáním agenta do HTTP šablony. Agent obdrží aktuální verzi z webu Mikrotik a trigger porovná aktuální verzi s aktuální a vydá upozornění v případě nesrovnalosti.
Když máte 10 routerů, takový algoritmus není kritický, ale co dělat s 3000 routery? Odeslat 3000 požadavků na server? Samozřejmě, že takové schéma bude fungovat, ale samotná myšlenka 3000 požadavků mi nevyhovovala, chtěl jsem najít jiné řešení. Navíc byl v takovém algoritmu stále nedostatek: druhá strana může na DoS útok spočítat takový počet požadavků z jedné IP, může to jednoduše zakázat.
2 výzva. Použití autorizační relace v různých HTTP agentech.
Když agent potřebuje přijímat informace z "uzavřených" stránek přes HTTP, je potřeba autorizační cookie. K tomu obvykle existuje standardní autorizační formulář s párem „login / password“ a nastavením ID relace v cookie.
Je tu ale problém, není možné získat přístup k datům jiné položky z jedné položky agenta HTTP a nahradit tuto hodnotu v záhlaví.
Existuje také "Webový skript", má další omezení, neumožňuje získat obsah pro analýzu a další ukládání. Mezi kroky webového skriptu můžete pouze zkontrolovat přítomnost nezbytných proměnných na stránkách nebo předávat dříve získané proměnné.
Poté, co jsem se nad těmito úkoly trochu zamyslel, rozhodl jsem se použít makra, která jsou dokonale viditelná v jakékoli části monitorovacího systému: v šablonách, hostitelích, triggerech nebo položkách. A makra můžete aktualizovat prostřednictvím rozhraní API webového rozhraní.
Zabbix má dobrou a podrobnou dokumentaci API. Pro výměnu dat přes api se používá datový formát Json. Podrobnosti najdete v .
Posloupnost akcí pro získání potřebných dat a jejich zaznamenání do makra je znázorněna na obrázku níže.
Krok 1
Úplně první krok může sestávat z jedné akce nebo více akcí. Veškerá hlavní logika je položena v prvních krocích a poslední 3 kroky jsou hlavní.
V mém příkladu bylo prvním krokem získání autorizačních cookies na ústředně pro první úlohu. U druhého úkolu jsem získal číslo aktuální verze firmwaru Mikrotiku.
URL aktuálních verzí firmwaru Mikrotik
- - URL adresa aktuální stabilní verze
- — URL adresa aktuální verze LTS
K těmto adresám přistupuje samotné zařízení Mikrotik, když je přijata nejnovější dostupná verze firmwaru.
První krok je pro každý případ zcela individuální a logika jeho práce může být odlišná. Vše závisí na vašem úkolu.
Při práci s webovým skriptováním sledujte, jakou metodu odezvy potřebujete. Tituly HTTP odpověď nebo vlastní тело odpověď bez hlaviček?
Pokud jsou potřeba autorizační soubory cookie, nastavte metodu odpovědi Tituly jako v případě Asterisk.Pokud potřebujete data, jako v případě odpovědi mikrotik serveru, vložte tělo odpověď bez hlaviček.
Krok 2
Přejděme 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 je verze protokolu JSON-RPC, která se používá;
Zabbix implementuje JSON-RPC verze 2.0;
- metoda - metoda, která je volána;
- params - parametry, které předává metoda;
- id je libovolný identifikátor požadavku;
- auth - klíč pro autentizaci uživatele; protože ji ještě nemáme, nastavíme ji na null.
Pro práci s API jsem vytvořil samostatný účet s omezenými právy. Za prvé, nemusíte poskytovat přístup tam, kde nepotřebujete. A za druhé, před verzí 5.0 bylo možné přečíst heslo nastavené přes makro. Pokud tedy používáte heslo správce Zabbix, účet správce lze snadno ukrást.
To bude platit zejména při práci s API prostřednictvím skriptů třetích stran a ukládání přihlašovacích údajů na straně.
Od verze 5.0 existuje možnost skrýt heslo uložené v makru.
Při vytváření samostatného účtu pro aktualizaci dat přes API si nezapomeňte ověřit, zda jsou data, která potřebujete, dostupná přes webové rozhraní a zda je možné je aktualizovat. Nekontroloval jsem to a pak jsem dlouho nemohl pochopit, proč makro, které jsem potřeboval, nebylo v API vidět.
Poté, co jsme obdrželi autorizaci v API, přistoupíme k získání seznamu maker.
Krok 3
Rozhraní API vám neumožňuje aktualizovat hostitelské makro podle názvu, musíte nejprve získat ID makra. Navíc, abyste získali seznam maker pro konkrétního hostitele, musíte znát ID tohoto hostitele, a to je další požadavek. Použít výchozí makro {HOST ID} v žádosti není povoleno. Rozhodl jsem se obejít omezení takto:
Vytvořil jsem místní makro s ID tohoto hostitele. Zjištění ID hostitele je velmi snadné z webového rozhraní.
Odpověď se seznamem všech maker na daném hostiteli lze filtrovat podle vzoru:
regex:{"hostmacroid":"([0-9]+)"[A-z0-9,":]+"{$MIKROTIK_VERSION}"
Tak získáme ID makra, které potřebujeme, kde MIKROTIK_VERSION je název makra, které hledáme. V mém případě se makro hledá MIKROTIK_VERSIONTo bylo přiděleno hostiteli.
Samotná žádost 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 budou používány neustále tam, kde potřebujete pracovat s rozhraním API.
Poslední 4 KROK - aktualizace makra
Nyní známe ID makra, které je třeba aktualizovat, autorizační cookie nebo verzi firmwaru routeru. Samotné makro můžete aktualizovat.
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 prvním kroku. V mém příkladu verze aktuálního firmwaru mikrotiku
{hostmacroid} - hodnota byla získána ve třetím kroku - id makra, které aktualizujeme.
Závěry
Přístup k řešení problému se standardní funkčností je mnohem složitější a delší. Zvláště pokud umíte programovat a umíte rychle přidat potřebnou logiku do skriptu.
Zjevnou výhodou tohoto přístupu je „přenositelnost“ řešení mezi různými servery.
Pro mě osobně je zvláštní, že HTTP agent nemůže přistupovat k datům jiné položky a nahradit je v těle požadavku nebo hlavičkách [ ].
Hotová šablona může .
Zdroj: www.habr.com