Când am conceput soluția pentru client, au apărut două sarcini pe care mi-am dorit să le rezolv frumos și cu funcționalitățile standard ale Zabbix.
Sarcina 1. Monitorizarea versiunii actuale a firmware-ului pe routerele Mikrotik.
Sarcina se rezolvă ușor — prin adăugarea în șablonul agentului HTTP. Agentul obține versiunea actuală de pe site-ul Mikrotik, iar trigger-ul compară versiunea actuală cu cea curentă și, în cazul unor discrepanțe, emite un alert.
Când aveți 10 routere, un astfel de algoritm nu este critic, dar ce să facem cu 3000 de routere? Să trimitem 3000 de solicitări către server? Va funcționa, desigur, dar ideea de 3000 de solicitări nu mă satisfacea, mi-aș fi dorit să găsesc o altă soluție. În plus, o problemă a acestui algoritm este că cealaltă parte poate considera un astfel de număr de solicitări de pe un singur IP ca un atac DoS și ar putea să ne blocheze.
Sarcina 2. Utilizarea sesiunii de autorizare în diferiți agenți HTTP.
Când este necesar să obțineți informații de pe paginile "închise" prin agentul HTTP, este nevoie de un cookie de autorizare. De obicei, există o formă standard de autentificare cu un pereche "login/parolă" și setarea ID-ului sesiunii în cookie.
Dar există o problemă, nu se poate accesa datele unui element HTTP agent dintr-un alt element pentru a substitui această valoare în Header.
Există și "Scenariul Web", care are o altă restricție: nu permite obținerea conținutului pentru analiză și salvare ulterioară. Poate doar să verifice existența variabilelor necesare pe pagini sau să transfere variabilele obținute anterior între pașii scenariului web.
După ce am meditat puțin asupra acestor sarcini, am decis să folosesc macrocomenzi, care sunt vizibile în orice parte a sistemului de monitorizare: în șabloane, gazde, trigger-e sau elemente. În plus, macrocomenzile pot fi actualizate prin API-ul interfeței web.
Zabbix dispune de o documentație bună și detaliată despre API. Pentru schimbul de date prin API se utilizează formatul de date JSON. Puteți citi mai multe în .
Secvența acțiunilor pentru obținerea datelor necesare și salvarea acestora în macrocomenzi este prezentată în schema de mai jos.
Pasul 1
Cel mai întâi pas poate consiste dintr-o singură acțiune sau din mai multe. În primele etape se stabilește toată logica principală, iar cele mai importante sunt ultimele 3 pași.
În exemplul meu, în prima etapă s-a realizat obținerea cookie-ului de autorizare pe centrala telefonică pentru prima sarcină. Pentru a doua sarcină am obținut numărul versiunii curente a firmware-ului Mikrotik.
URL-urile versiunilor actuale ale firmware-ului Mikrotik
- — URL-ul pentru versiunea stabilă actuală
- — URL-ul pentru versiunea LTS actuală
Aceste adrese sunt accesate de echipamentul Mikrotik pentru a obține cea mai recentă versiune disponibilă a firmware-ului.
Primul pas este complet individualizat pentru fiecare caz și logica acestuia poate fi diferită. Totul depinde de sarcina ta.
Când lucrezi cu scenarii web, urmărește ce metodă de obținere a răspunsului ai nevoie. Anteturi Răspunsul HTTP sau doar corpul răspunsului fără antete?
Dacă ai nevoie de cookie-uri de autorizare, folosește metoda de răspuns Anteturi ca în cazul Asterisk.Dacă ai nevoie de date, ca în cazul răspunsului serverului mikrotik, folosește Corpul răspunsului fără antete.
Pasul 2
Trecem la pasul doi. Obținerea sesiunii de autorizare:
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 — versiunea protocolului JSON-RPC utilizat;
Zabbix folosește JSON-RPC versiunea 2.0;
- method — metoda apelată;
- params — parametrii transmiși metodei;
- id — identificatorul aleator al solicitării;
- auth — cheia de autentificare a utilizatorului; deoarece nu o avem încă, o vom indica ca fiind egală cu null.
Pentru a lucra cu API, am creat un cont separat, cu drepturi limitate. În primul rând, nu trebuie să oferi acces acolo unde nu este necesar. În al doilea rând, până la versiunea 5.0, parola setată prin macro-uri putea fi citită. Așadar, folosind parola administratorului Zabbix, contul admin putea fi ușor furat.
Acest lucru va fi deosebit de relevant atunci când lucrezi cu API prin scripturi externe și stochezi datele de autentificare pe partea ta.
De la versiunea 5.0 a apărut opțiunea de a ascunde parola stocată în macro.
Când creezi un cont separat pentru actualizarea datelor prin API, asigură-te că datele de care ai nevoie sunt disponibile prin interfața web și că actualizarea acestora este posibilă. Nu am verificat și apoi nu am putut înțelege de ce macro-ul necesar nu era vizibil prin API.
După ce am obținut autorizarea în API, trecem la obținerea listei de macro-uri.
Pasul 3
Interfața API nu permite actualizarea macro-ului host-ului după nume; este necesar întâi să obținem ID-ul macro-ului. În plus, pentru a obține lista macro-urilor unui host specific, trebuie să aflăm ID-ul acelui host, ceea ce înseamnă o cerere suplimentară. Utilizați un macro standard. {HOST.ID} în cerere nu poate fi. Am decis să învărt din această restricție astfel:
Am creat un macro local cu ID-ul acestui host. Este foarte ușor să afli ID-ul host-ului din interfața web.
Răspunsul cu lista tuturor macro-urilor acestui host poate fi filtrat după un șablon:
regex:{"hostmacroid":"([0-9]+)"[A-z0-9,":]+"{$MIKROTIK_VERSION}" 
Astfel, obținem ID-ul macro-ului dorit, unde MIKROTIK_VERSION — este numele macro-ului pe care îl căutăm. În cazul meu, se caută macro-ul MIKROTIK_VERSION, care a fost alocat host-ului.
Cererea arată astfel:
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
}
Variabilă {sid} obținută în pasul doi și va fi folosită constant pentru lucrul cu interfața API.
Pasul final 4 — actualizarea macro-ului
Acum știm ID-ul macro-ului pe care trebuie să-l actualizăm, cookie-ul de autorizare sau versiunea firmware-ului routerului. Putem actualiza macro-ul propriu-zis.
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} — este valoarea obținută în primul pas. În exemplul meu — versiunea firmware-ului actual al mikrotik.
{hostmacroid} — este valoarea obținută în pasul trei — ID-ul macro-ului pe care îl actualizăm.
Conclusions
Abordarea de a rezolva problema folosind funcționalitatea standard este mult mai complicată și necesită mai mult timp. În special, dacă știi programare și poți crea rapid logica necesară într-un script.
Un avantaj evident al acestei abordări este „portabilitatea” soluției între servere diferite.
Personal, mi se pare ciudat absența posibilității de a accesa, în agentul HTTP, datele unui alt item și de a le insera în corpul cererii sau în antet [ ].
Un șablon gata poate fi .
Sursa: habr.com
