Când am realizat o soluție pentru un client, au apărut 2 sarcini pe care am vrut să le rezolv frumos și cu funcționalitatea obișnuită Zabbix.
Sarcina 1. Urmărirea versiunii actuale de firmware pe routerele Mikrotik.
Sarcina este rezolvată cu ușurință - prin adăugarea unui agent la șablonul HTTP. Agentul primește versiunea curentă de pe site-ul Mikrotik, iar declanșatorul compară versiunea actuală cu cea actuală și emite o alertă în cazul unei discrepanțe.
Când ai 10 routere, un astfel de algoritm nu este critic, dar ce să faci cu 3000 de routere? Trimiteți 3000 de solicitări către server? Desigur, o astfel de schemă va funcționa, dar însăși ideea de 3000 de solicitări nu mi-a convenit, am vrut să găsesc o altă soluție. În plus, mai exista un dezavantaj în un astfel de algoritm: cealaltă parte poate număra un astfel de număr de solicitări de la un IP pentru un atac DoS, îl pot interzice pur și simplu.
Sarcina 2. Utilizarea unei sesiuni de autorizare în diferiți agenți HTTP.
Când un agent trebuie să primească informații din pagini „închise” prin HTTP, este necesar un cookie de autorizare. Pentru a face acest lucru, există de obicei un formular de autorizare standard cu o pereche „login/parolă” și setarea ID-ului sesiunii în cookie.
Dar există o problemă, este imposibil să accesați datele unui alt articol dintr-un articol de agent HTTP pentru a înlocui această valoare în Antet.
Există și un „script web”, are o altă limitare, nu vă permite să obțineți conținut pentru analiză și salvare ulterioară. Puteți verifica doar prezența variabilelor necesare în pagini sau puteți trece variabilele primite anterior între pașii de script web.
După ce m-am gândit puțin la aceste sarcini, am decis să folosesc macrocomenzi care sunt perfect vizibile în orice parte a sistemului de monitorizare: în șabloane, gazde, declanșatoare sau articole. Și puteți actualiza macrocomenzi prin API-ul interfeței web.
Zabbix are o documentație API bună și detaliată. Pentru schimbul de date prin api, este utilizat formatul de date Json. Detalii pot fi găsite în .
Secvența de acțiuni pentru obținerea datelor de care avem nevoie și înregistrarea lor într-o macro este prezentată în diagrama de mai jos.
Pasul 1
Primul pas poate consta dintr-o singură acțiune sau mai multe acțiuni. Toată logica principală este așezată în primii pași, iar ultimii 3 pași sunt cei principali.
În exemplul meu, primul pas a fost să obținem cookie-uri de autorizare pe PBX pentru prima sarcină. Pentru a doua sarcină, am primit numărul versiunii curente a firmware-ului Mikrotik.
Adresa URL a versiunilor actuale de firmware Mikrotik
- - Adresa URL a versiunii Stable actuale
- — adresa URL a versiunii LTS curente
Aceste adrese sunt accesate chiar de echipamentul Mikrotik atunci când este primită cea mai recentă versiune de firmware disponibilă.
Primul pas este complet individual pentru fiecare caz și logica activității sale poate fi diferită. Totul depinde de sarcina ta.
Când lucrați cu scripturi web, urmăriți metoda de răspuns de care aveți nevoie. Titluri Răspuns HTTP sau auto тело răspuns fără antete?
Dacă sunt necesare cookie-uri de autorizare, atunci setați metoda de răspuns Titluri ca în cazul lui Asterisk.Dacă aveți nevoie de date, ca în cazul răspunsului serverului mikrotik, puneți corp răspuns fără antete.
Pasul 2
Să trecem la pasul al doilea. Obținerea unei sesiuni 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 este versiunea protocolului JSON-RPC care este utilizată;
Zabbix implementează JSON-RPC versiunea 2.0;
- metoda - metoda care se numeste;
- params - parametri care sunt trecuți de metodă;
- id este un identificator de cerere arbitrar;
- auth - cheie de autentificare a utilizatorului; deoarece nu-l avem încă, să-l setăm la null.
Pentru a lucra cu API-ul, am creat un cont separat cu drepturi limitate. În primul rând, nu trebuie să oferiți acces acolo unde nu aveți nevoie. Și în al doilea rând, înainte de versiunea 5.0, parola setată prin macro-ul putea fi citită. În consecință, dacă utilizați parola de administrator Zabbix, contul de administrator este ușor de furat.
Acest lucru va fi valabil mai ales atunci când lucrați cu API prin scripturi terță parte și stocați acreditările pe partea laterală.
Din versiunea 5.0 există o opțiune de a ascunde parola salvată în macrocomandă.
Când creați un cont separat pentru actualizarea datelor prin API, asigurați-vă că verificați dacă datele de care aveți nevoie sunt disponibile prin interfața web și dacă este posibil să le actualizați. Nu am verificat, iar apoi o lungă perioadă de timp nu am putut înțelege de ce macrocomanda de care aveam nevoie nu era vizibilă în API.
După ce am primit autorizarea în API, trecem la obținerea unei liste de macrocomenzi.
Pasul 3
API-ul nu vă permite să actualizați o macrocomandă gazdă după nume, trebuie mai întâi să obțineți ID-ul macrocomenzii. Mai mult, pentru a obține o listă de macrocomenzi pentru o anumită gazdă, trebuie să cunoașteți ID-ul acestei gazde, iar aceasta este o solicitare suplimentară. Utilizați macrocomandă implicită {ID HOST} în cerere nu este permisă. Am decis să ocol restricția astfel:
Am creat o macrocomandă locală cu ID-ul acestei gazde. Aflarea ID-ului gazdei este foarte ușor din interfața web.
Un răspuns cu o listă a tuturor macrocomenzilor de pe o anumită gazdă poate fi filtrat după un model:
regex:{"hostmacroid":"([0-9]+)"[A-z0-9,":]+"{$MIKROTIK_VERSION}"
Astfel, obținem ID-ul macro-ului de care avem nevoie, unde MIKROTIK_VERSION este numele macrocomenzii pe care o căutăm. În cazul meu, macro-ul este căutat MIKROTIK_VERSIONAcesta a fost atribuit gazdei.
Cererea în sine 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 a doua etapă și va fi folosit constant, acolo unde trebuie să lucrați cu interfața API.
Ultimul 4 PAS - actualizarea macro-ului
Acum știm ID-ul macro care trebuie actualizat, cookie-ul de autorizare sau versiunea de firmware a routerului. Puteți actualiza macrocomandă în sine.
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 prima etapă. În exemplul meu, versiunea firmware-ului actual mikrotik
{hostmacroid} - valoarea a fost obținută în pasul al treilea - id-ul macro-ului pe care îl actualizăm.
Constatări
Abordarea rezolvării problemei cu funcționalitatea standard este mult mai complicată și mai lungă. Mai ales dacă știi programare și poți adăuga rapid logica necesară în script.
Avantajul evident al acestei abordări este „portabilitatea” soluției între diferite servere.
Pentru mine personal, este ciudat că agentul HTTP nu poate accesa datele altui articol și le poate înlocui în corpul sau anteturile cererii [ ].
Șablonul finit poate .
Sursa: www.habr.com