U prethodnom članku Objasnio sam kako dobiti autorizacijske sesije i umetnuti ih u lokalne makronaredbe hosta. U ovom članku ću opisati kako spojiti Zabbix s Asteriskom bez vanjskih skripti i softvera.
Ideja o 'spajanju' ovih dviju sustava postoji već dugo, i to bez instaliranja dodatnog softvera i skripti. Brzo pretraživanje interneta rezultiralo je brojnim rješenjima, svi su se svodili na to da ubacite skripte (na PHP-u, Bashu, Pythonu itd.) na server, i tada će sve biti u redu. Međutim, želio sam ostvariti praćenje 'iz kutije' — bez vanjskih skripti i instaliranja dodatnog softvera na server s praćenjem i PBX-om.
Proveo sam u tome ukupno 4 radna dana, ali rezultat je bio vrijedan truda. Rad preko AMI sučelja, nisko razine otkrivanje, okidači, a najvažnije, spajanje na PBX i sve ostale postavke sada traje samo 15 minuta.
Imamo Zabbix 4.4, otprilike 100 instanci Asteriska 13. Neki PBX-ovi dolaze s web sučeljem FreePBX, dok neki imaju samo golu konzolu, hrpu trikova i integraciju putem dijalnog plana.
Dobivanje podataka iz PBX-a
Prvi i osnovni zadatak koji treba riješiti je dobivanje informacija o peer-ovima i SIP registracijama. Za to u PBX-u postoje sučelja AGI, AMI, ARI i SSH konzola. Dodatne module iz očiglednih razloga nisam razmatrao.
Za početak, potrebno je razumjeti što predstavljaju ova AGI, AMI, ARI…
- AGI — korištenje skripti u dijalnom planu. Glavno se koristi za upravljanje pozivima.
- AMI — može pružiti sve potrebne informacije, radi na portu 5038 slično kao Telnet. To nam odgovara!
- ARI — moderno, trendy, u JSON formatu. Puno mogućnosti, format podataka u razumljivom obliku za Zabbix, ali nedostaje mi najvažnije: ne može kontrolirati SIP registraciju. Još jedan nedostatak, postoji samo dva stanja za peer-ove online/offline, iako ih ima više i korisno je uzeti ih u obzir prilikom dijagnostike.
- SSH — može sve, ali ponekad ga ne dozvoljavaju zbog 'sigurnosnih razloga'. Razlozi mogu biti razni, neću ih detaljno razrađivati.
Bez obzira na sve svoje nedostatke, ARI pokriva 90% svih potreba za praćenjem.
Zabbix i Telnet — moje razočaranje
AMI dobro poznajem, svojevremeno sam implementirao praćenje gubitaka u razgovorima s podjelom po udaljenim uredima, upravljanje pozivima itd. Telnet je također vrlo jednostavan: otvorite vezu, šaljite komande i čitajte odgovore. Tako sam i učinio, ali me rezultat razočarao.
Telnet u Zabbixu nije kao u Linux konzoli, malo je jednostavniji i fokusiran na standardnu autorizaciju tipa korisničko ime/lozinka. Ako je logika autorizacije drugačija, i nema zahtjeva za parom korisničko ime/lozinka, javlja se greška. Nakon bezuspješnih pokušaja zaobići zahtjev za autorizaciju, počeo sam gledati izvorne kodove modula Telnet.
Shvatio sam da neću napredovati dok ne bude tradicionalnog zahtjeva za korisničkim imenom i lozinkom. Iz znatiželje, uklonio sam iz koda sve što se tiče autorizacije, ponovo sastavio sve. Radi! No, ne odgovara zahtjevima. Idemo dalje…
Vraćamo se potrazi
Ponovno sam pročitao dokumentaciju o ARI, proveo dodatna ispitivanja — ovdje nema SIP registracija. Peeri postoje, razgovori postoje, bridgevi postoje, ali registracija nema. U nekom trenutku sam se čak zapitao, koliko su nam uopće potrebne SIP registracije?
Iz zabavne koincidencije, u tom trenutku dolazi još jedan zahtjev od korisnika, s problemom izlaznih poziva. Problem je bio u zakašnjenju SIP registracije i rješavao se običnim restartom modula.
asterisk -rx "sip reload"Bilo bi sjajno pristupiti AMI-ju putem weba: to bi riješilo sve probleme, pomislio sam. Počinjem istraživati u tom smjeru, i doslovno prva linija pretrage vodi na službenu dokumentaciju Asteriska, u kojoj se navodi da za moje zadatke postoji opcija webenabled u datoteci /etc/asterisk/manager.conf, koju treba postaviti na vrijednost YES, u sekciji [general]
Nakon toga, putem običnog web zahtjeva poput dobivamo sve potrebne informacije.
Pri korištenju sučelja FreePBX, putem weba ne možete uključiti tu opciju, treba je uključiti putem konzole, praveći izmjene u datoteci manager.conf. FreePBX je ne briše prilikom promjena konfiguracije putem weba.
Koliko god sam radio s različitim integracijama Asteriska, nikada nisam vidio da se ta funkcija negdje spominje. Iznenadilo me je što nitko ne opisuje ovu metodu interakcije s PBX-om. Čak sam posebno potražio informacije o ovoj temi: praktički ništa nema ili se koristi za potpuno druge svrhe.
WEB AMI — što je to?
Dodavanje opcije webenabled u datoteku manager.conf otvara pun pristup upravljanju PBX-om putem weba. Sve naredbe dostupne putem običnog AMI sada su dostupne na webu, moguće je slušati događaje s PBX-a putem socketa. Način rada se ne razlikuje od konzolnog AMI-a. Nakon aktivacije ove opcije, PBX se može kontaktirati na sljedećim adresama:
— web stranica s jednostavnim sučeljem, za testove i ručno slanje zahtjeva. Svi odgovori formatirani su u čitljiv HTML oblik. Za praćenje nije baš pogodna.
— samo tekstualni izlaz, format sličan konzolnom AMI-ju
— samo tekstualni izlaz, u XML formatu. Odgovara nam!
Tu sam pomislio: "Eto ga – rješenje! Sada će sve biti spremno! Lako-peasy limun squeezy", ali je bilo još prerano za radovanje. Za dobivanje potrebnih informacija dovoljno je koristiti GET zahtjev s potrebnom radnjom action, koji u odgovoru vraća xml sa svim registracijama i njihovim stanjima. To je super, ali potrebna je autentifikacija s pohranjivanjem sesije iz cookie-a. Kada testiraš u pregledniku, ne razmišljaš o tom procesu.
Proces autorizacije
Na početku se obraćamo na adresu , u odgovoru nam server šalje cookie s autentifikacijskom sesijom. Ovako izgleda HTTP zahtjev:
https://ats:8089/mxml?action=login&username=zabbix&secret=zabbix
Host: ats:8089
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:77.0) Gecko/20100101 Firefox/77.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: hr-HR,hr;q=0.8,en-US;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate, br
DNT: 1
Connection: keep-alive
Upgrade-Insecure-Requests: 1Odgovor:
GET: HTTP/1.1 200 OK
Server: Asterisk/13.29.2
Date: Thu, 18 Jun 2020 17:41:19 GMT
Cache-Control: no-cache, no-store
Content-type: text/xml
Set-Cookie: mansession_id="6f5de42c"; Version=1; Max-Age=600
Pragma: SuppressEvents
Content-Length: 146 Za rad je potrebna mansession_id="6f5de42c", tj. sama cookie autentifikacije.
Sadržaj treba samo provjeriti na prisutnost odgovora "Authentication accepted". Zatim, kod svih obraćanja serveru PBX-u, morat ćemo dodati cookie autentifikacije u zahtjev.
https://ats:8089/mxml?action=SIPpeers
Host: ats:8089
Connection: close
Cookie: mansession_id="6f5de42c"Kako dobiti cookie autentifikacije i koristiti je u drugim zahtjevima pročitajte ovdje: "»
Za kreiranje elemenata praćenja u Zabbixu koristit ću auto otkrivanje.
Auto otkrivanje
Za auto otkrivanje registracija i praćenje stanja peera potrebno je obratiti se adresi: ili
U odgovoru PBX nam vraća XML odgovor:
...
... U odgovoru ima puno smeća, zato ga filtriramo prema šablonu u preprocesiranju. XPath: //response/generic[@host]
Nakon toga dolazi najzanimljiviji dio. Da bismo radili s otkrivanjem i dinamički kreirali elemente, odgovor mora biti u JSON formatu. XML se ne podržava pri automatskom otkrivanju.
Da bih pretvorio XML u JSON, morao sam malo zaigrati s automatskom zamjenom, za što sam napravio skriptu na JS.
Zanimljiva stvar je da su svi parametri u odgovoru centralnog aparata obavijeni jednostrukim navodnicima, a nakon primjene šablona //response/generic[@host] se zamjenjuju dvostrukim.
Za kreiranje elemenata koristimo varijable iz XML odgovora (sada JSON).
SIP Registry
Za SIP registracije koristimo tri varijable: korisničko_ime, host, port. Bio sam zadovoljan nazivom elementa 111111@login.mtt.ru:5060, situacija kada je potrebno koristiti svih pet varijabli nisam pronašao.
Glavni element koji prima informacije o svim registracijama, Asterisk — AMI SIPshowregistry. Jednom u minuti šalje GET zahtjev na , nakon čega se podaci XML odgovora šalju svim zavisnim elementima na analizu. Element za svaku registraciju kreiram kao zavistan od njega. To je praktično, jer relevantne informacije dobivamo s jednim zahtjevom, a ne za svaki posebno. Ova implementacija ima značajan nedostatak — opterećenje procesora.
Prilikom testiranja do 100 zavisnih elemenata, opterećenje nisam primijetio, ali pri 1700 elemenata to je davalo značajno opterećenje od 15 sekundi na procesor. Imajte to na umu ako imate mnogo zavisnih elemenata.
Kao opcija za "raspršivanje" opterećenja ili postavljanje različite učestalosti upita za element, logiku obrade možete prenijeti u svaki element posebno.
Informacije koje dobijem ne pohranjujem u glavnu komponentu. Prvo, ne vidim potrebu za tim, a drugo, ako je odgovor veći od 64K, Zabbix ga skraćuje.
Budući da za zavisnu komponentu koristimo potpuni XML odgovor, potrebno je u preprocesiranju dobiti vrijednost te komponente. Kroz XPath to se radi ovako:
string(//response/generic[@event='RegistryEntry'][@username="{#SIP_REGISTRY_USERNAME}"][@host="{#SIP_REGISTRY_HOST}"][@port="{#SIP_REGISTRY_PORT}"]/@state)
Za statuse registracija nisam koristio tekstualne statuse, već sam ih preveo u numerički oblik pomoću JavaScripta:
switch(value) {
case 'Registered':
return 1;
case 'Unregistered':
return 0;
default:
return -1;
}
SIP Peers
Na sličan način kao i sa SIP registracijama, postoji glavna komponenta Asterisk — AMI SIPshowregistry, kojoj se dodaju zavisne.
Ovdje se kreiraju dva zavisna elementa:
- Status peera u tekstualnom obliku
- Vrijeme odgovora uređaja — ako je status OK, piše se vrijeme odgovora uređaja, inače «-1»
Sam put do komponente je nešto jednostavniji XPath:
string(//response/generic[@objectname="{#SIP_PEER_OBEJECTNAME}"]/@status)
Za drugi element koristio sam JavaScript da odvojim vrijeme odgovora od statusa peera, budući da se pohranjuju zajedno:
if(value.substring(0,2) == 'OK'){
return value.match(/(d+)/gm);
}
else {
return -1;
}Zaključak
Rješenje 'iz kutije' može biti složeno i nije odmah jasno. Povećava se fleksibilnost i prenosivost među različitim sistemima.
Želim svima ugodnu i laku integraciju! Predložak i upute za postavljanje na .
Izvor: habr.com
