Pri izradi rješenja za klijenta, pojavila su se dva zadatka koja sam želio rešiti na lep i funkcionalan način kroz Zabbix.
Zadatak 1. Praćenje aktuelne verzije firmware-a na Mikrotik ruterima.
Zadatak se lako rešava — dodavanjem u šablon HTTP agenta. Agent dovlači aktuelnu verziju sa Mikrotik sajta, a okidač upoređuje aktuelnu verziju s trenutnom i u slučaju neslaganja šalje alerter.
Kada imate 10 rutera, takav algoritam nije kritičan, ali šta da radite sa 3000 rutera? Slati 3000 zahteva na server? Raditi će, naravno, ali sama ideja o 3000 zahteva mi nije prijala, želeo sam pronaći drugo rešenje. Osim toga, nedostatak takvog algoritma je i to što druga strana može smatrati takav broj zahteva sa jednog IP-a DoS napadom i mogu jednostavno blokirati.
Zadatak 2. Korišćenje sesije za autentifikaciju u različitim HTTP agentima.
Kada treba da dobijete informacije sa 'zatvorenih' stranica putem HTTP agenta, potrebna je autentifikacijska kolačić. Obično postoji standardni obrazac za autentifikaciju sa parom 'korisničko ime/lozinka' i postavkom ID-a sesije u kolačiću.
Ali postoji problem, nije moguće iz jednog elementa HTTP agenta pristupiti podacima drugog elementa kako bi se ta vrednost postavila u Header.
Takođe postoji 'Web skript', koji ima drugo ograničenje, ne omogućava vam da dobijete sadržaj za analizu i dalje čuvanje. Možete samo proveriti prisustvo potrebnih varijabli na stranicama ili preneti prethodno dobijene varijable između koraka web skripta.
Nakon malo razmišljanja o ovim zadacima, odlučio sam koristiti makroe koji su jasno vidljivi u svakom delu sistema za praćenje: u šablonima, hostovima, okidačima ili elementima. A makroe možete ažurirati putem API-ja web sučelja.
Zabbix ima dobru i detaljnu dokumentaciju o API-ju. Za razmenu podataka putem API-ja koristi se JSON format podataka. Detaljno se može pročitati u .
Sekvenca radnji za dobijanje potrebnih podataka i zapisivanje u makros je prikazana na dijagramu ispod.
Korak 1
Prvi korak može se sastojati od jedne radnje ili više radnji. U prvih nekoliko koraka polagaće se cela osnovna logika, a glavni su poslednja 3 koraka.
U mom primeru, u prvom koraku dobijena je kolačić za autentifikaciju na PBX-u za prvi zadatak. Za drugi zadatak sam dobijao broj trenutne verzije firmware-a Mikrotik.
URL актуualne verzije Mikrotik firmware-a
- — URL adresa aktualne Stable verzije
- — URL adresa aktualne LTS verzije
Ove adrese koristi sam uređaj Mikrotik prilikom preuzimanja najnovije dostupne verzije firmware-a.
Prvi korak je potpuno individualan za svaki slučaj i logika njegovog rada može se razlikovati. Sve zavisi od vašeg zadatka.
Prilikom rada s web skriptama, pratite koji vam način preuzimanja odgovora treba. Zaglavlja HTTP odgovora ili samo tijelo odgovora bez zaglavlja?
Ako su potrebni kolačići za autorizaciju, odredite način odgovora Zaglavlja kao u slučaju s Asteriskom.Ako su potrebni podaci, kao u slučaju s odgovorom servera Mikrotik, postavite Tijelo odgovora bez zaglavlja.
Korak 2
Prelazimo na drugi korak. Dobivanje sesije autorizacije:
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 — verzija JSON-RPC protokola koja se koristi;
Zabbix implementira JSON-RPC verzije 2.0;
- method — metoda koja se poziva;
- params — parametri koji se predaju metodom;
- id — proizvoljni identifikator zahtjeva;
- auth — ključ za autentifikaciju korisnika; kako ga još nemamo, postavit ćemo ga na null.
Za rad s API-em, kreirao sam odvojeni korisnički račun s ograničenim pravima. Prvo, ne treba davati pristup tamo gdje nije potrebno. Drugo, do verzije 5.0, zadan preko makroa lozinku je bilo moguće pročitati. Stoga, korištenje lozinke administratora Zabbixa može lako rezultirati krađom administratorskog računa.
To će biti posebno relevantno kada radite s API-jem preko vanjskih skripti i čuvate korisničke podatke na strani.
Od verzije 5.0 postoji opcija sakrivanja lozinke spremljene u makrou.
Kada kreirate odvojeni korisnički račun za ažuriranje podataka putem API-a, obavezno provjerite jesu li potrebni podaci dostupni kroz web sučelje i je li moguće njihovo ažuriranje. Nisam provjerio, a zatim dugo nisam mogao shvatiti zašto putem API-a ne vidim potreban makro.
Nakon što dobijemo autorizaciju u API-u, prelazimo na dobivanje popisa makroa.
Korak 3
API sučelje ne omogućuje ažuriranje makroa hosta po imenu, za to prvo treba dobiti ID makroa. Štoviše, da bi se dobio popis makroa određenog hosta, potrebno je znati ID tog hosta, a to je dodatni upit. Koristiti standardni makro {HOST.ID} u upitu nije moguće. Ograničenje sam pokušao zaobići na sljedeći način:
Stvorio sam lokalni makro s ID-jem ovog hosta. Saznati ID hosta vrlo je jednostavno putem web sučelja.
Odgovor s popisom svih makroa ovog hosta može se filtrirati prema obrascu:
regex:{"hostmacroid":"([0-9]+)"[A-z0-9,":]+"{$MIKROTIK_VERSION}" 
Na taj način dobivamo ID potrebnog makroa, gdje MIKROTIK_VERSION je ime makroa koji tražimo. U mom slučaju tražim makro MIKROTIK_VERSION, koji je bio dodijeljen hostu.
Sami zahtjev izgleda ovako:
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
}
Varijabla {sid} dobiven na drugom koraku i bit će korišten trajno, gdje je potrebno raditi s API sučeljem.
Završni 4 KORAK — ažuriranje makroa
Sada znamo ID makroa koji treba ažurirati, kolačić za autorizaciju ili verziju firmvera usmjerivača. Može se ažurirati sam 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} je vrijednost dobivena u prvom koraku. U mom primjeru — verzija aktualnog firmvera mikrotik
{hostmacroid} je vrijednost dobivena u trećem koraku — id makroa koji ažuriramo.
Zaključci
Pristup rješavanju zadatka standardnom funkcionalnošću je mnogo složeniji i duži. Osobito ako poznaješ programiranje i možeš brzo izraditi potrebnu logiku u skripti.
Očigledna prednost ovog pristupa je "prenosivost" rješenja između različitih poslužitelja.
Osobno mi je čudno što ne postoji mogućnost pozivanja HTTP agenta na podatke drugog artikla i umetanja njih u tijelo zahteva ili zaglavlja [ ].
Gotov obrazac se može .
Izvor: habr.com
