Në një artikull të mëparshëm Unë ju thashë se si të merrni një seancë autorizimi dhe ta zëvendësoni atë në një makro pritës lokal. Në këtë artikull do t'ju tregoj se si ta lidhni Zabbix me Asterisk pa skripta dhe softuer të jashtëm.
Ideja për të “bërë miq” me këto dy sisteme ka lindur shumë kohë më parë, pa instaluar softuer apo skripta shtesë. Një kërkim i shpejtë në google dha shumë zgjidhje të mundshme, të gjitha përfunduan në faktin se ngarkoni skriptet (në Pyha, Bash, Python, etj.) në server dhe do të jeni të lumtur. Doja të zbatoja monitorimin "jashtë kutisë" - pa skripta të jashtëm dhe instalimi i softuerit shtesë në server me monitorim dhe PBX.
Kam kaluar gjithsej 4 ditë pune me këtë, por rezultati ia vlente. Puna përmes ndërfaqes AMI, zbulimit të nivelit të ulët, ndezësve dhe më e rëndësishmja, lidhja e PBX dhe të gjitha cilësimet e tjera tani zgjat rreth 15 minuta.
Zabbix 4.4 është në dispozicion, rreth 100 pjesë të versionit 13 të Asterisk. Disa PBX vijnë me ndërfaqen në internet FreePBX, disa me një tastierë të zhveshur, një mori trukesh dhe integrim përmes një plani telefonik.
Marrja e të dhënave nga PBX
Pika e parë dhe kryesore që duhet zgjidhur është marrja e të dhënave për regjistrimet e kolegëve dhe SIP. Për këtë qëllim, PBX ka ndërfaqe të konsolës AGI, AMI, ARI dhe SSH. Për arsye të dukshme, nuk kam marrë parasysh module shtesë.
Fillimisht duhet të kuptojmë se çfarë janë këta agi, ami, ari...
- AGI - duke përdorur skriptet në planin e numrit. Përdoret kryesisht për menaxhimin e thirrjeve.
- AMI - mund të sigurojë të gjithë informacionin e nevojshëm, punon nëpërmjet portit 5038, ngjashëm me Telnet. na përshtatet!
- ARI - moderne, në modë, JSON. Ka shumë mundësi, formati i të dhënave është i kuptueshëm për Zabbix, por për mua nuk ka gjë kryesore: nuk mund të kontrolloni regjistrimin e gllënjkës. Një tjetër disavantazh është se për kolegët ekzistojnë vetëm dy gjendje online/offline, megjithëse ka më shumë gjendje dhe është e dobishme t'i merren parasysh gjatë diagnostikimit.
- SSH mund të bëjë gjithçka, por ndonjëherë nuk lejohet për "arsye sigurie". Konsideratat mund të jenë të ndryshme, nuk do të hyj në to.
Megjithatë, me të gjitha mangësitë e saj, ARI mbulon 90% të të gjitha nevojave monitoruese.
Zabbix dhe Telnet - zhgënjimi im
Unë e njoh mirë AMI-në; në një kohë kam zbatuar gjurmimin e humbjeve në bisedat me divizionin nga zyrat në distancë, menaxhimin e thirrjeve, etj. Me Telnet, gjithçka është gjithashtu shumë e qartë: hapni lidhjen, dërgoni komandat dhe lexoni përgjigjen. Kështu bëra, por rezultati më zhgënjeu.
Telnet në Zabbix nuk është i njëjtë si në tastierën Linux, është pak më i thjeshtë dhe i përshtatur për autorizim standard si login/fjalëkalimi. Nëse logjika e autorizimit është e ndryshme dhe nuk ka kërkesë për një çift hyrje/fjalëkalim, ndodh një gabim. Pas përpjekjeve të kota për të anashkaluar kërkesën e autorizimit, ishte e dobishme të shikoni kodin burimor të modulit Telnet.
Kuptova që derisa të ketë një kërkesë tradicionale për hyrje dhe fjalëkalim, nuk do të eci përpara. Thjesht për argëtim, hoqa gjithçka që lidhej me autorizimin nga kodi dhe rimontova gjithçka. Punon! Por nuk i plotëson kërkesat. Shkoni përpara…
Le t'i kthehemi kërkimit
E lexova përsëri dokumentacionin e ARI-së, bëra teste shtesë - këtu nuk ka regjistrime të gllënjkave. Ka gosti, ka biseda, ka pantallona, por nuk ka regjistrime. Madje në një moment mendova, a kemi vërtet nevojë për regjistrimin e shkabave?
Për një rastësi qesharake, në këtë moment vjen një tjetër kërkesë nga përdoruesi, me një problem me thirrjet dalëse. Problemi ishte se regjistrimi i gllënjkës po ngrinte dhe u zgjidh thjesht duke rindezur modulin.
asterisk -rx "sip reload"Do të ishte mirë të hyni në AMI përmes internetit: kjo do të zgjidhte të gjitha problemet, mendova. Unë filloj të gërmoj në këtë drejtim, dhe fjalë për fjalë rreshti i parë i kërkimit të çon në dokumentacionin zyrtar të Asterisk, i cili thotë se ekziston një opsion për detyrat e mia uebenabled në dosje /etc/asterisk/manager.conf, e cila duhet të vendoset në PO, në seksion [e përgjithshme]
Pas kësaj, përmes një kërkese të rregullt në ueb të formularit marrim të gjithë informacionin e nevojshëm.
Kur përdorni ndërfaqen FreePBX, nuk mund ta aktivizoni këtë opsion përmes ueb-it; duhet ta aktivizoni atë përmes tastierës duke bërë ndryshime në skedarin manager.conf. FreePBX nuk e fshin atë kur bëhen ndryshimet e konfigurimit nëpërmjet internetit.
Unë kam punuar me lloje të ndryshme të integrimeve të Asterisk për një kohë të gjatë, por kurrë nuk e kam parë këtë veçori të përmendur askund. U habita që askush nuk e përshkruan këtë metodë të bashkëveprimit me PBX. Ishte madje veçanërisht e dobishme të kërkoni informacione për këtë temë: praktikisht nuk ka asgjë ose është përdorur për detyra krejtësisht të ndryshme.
WEB AMI - çfarë lloj bishë?
Shtimi i një opsioni uebenabled për të paraqitur menaxher.konf ofroi akses të plotë në menaxhimin e ATS nëpërmjet internetit. Të gjitha komandat e disponueshme përmes një AMI të rregullt janë tani në ueb, ju mund të dëgjoni ngjarje nga PBX përmes një prize. Parimi i funksionimit nuk është i ndryshëm nga tastiera AMI. Pas aktivizimit të këtij opsioni, mund të kontaktoni PBX në adresat e mëposhtme:
— një faqe interneti me një ndërfaqe të thjeshtë për testimin dhe dërgimin manual të kërkesave. Të gjitha përgjigjet janë të formatuara në HTML të lexueshme. Jo shumë i përshtatshëm për monitorim.
— vetëm prodhimi i tekstit, format i ngjashëm me AMI të konsolës
- vetëm prodhimi i tekstit, në formatin XML. na përshtatet!
Pastaj mendova: “Kjo është zgjidhja! Tani gjithçka do të jetë gati! Limon shtrydhëse e lehtë, por ishte herët për t'u gëzuar. Për të marrë informacionin që na nevojitet, mjafton të përdorim një kërkesë GET me veprimet e nevojshme veprim, e cila si përgjigje kthen xml me një listë të të gjitha regjistrimeve dhe statusin e tyre. E gjithë kjo është e mrekullueshme, por ju duhet autorizim për të kujtuar seancën nga cookie. Kur testoni në shfletues, nuk mendoni për këtë proces.
Procesi i autorizimit
Fillimisht i drejtohemi adresës , si përgjigje, serveri na dërgon një cookie me seancën e autorizimit. Kështu duket një kërkesë HTTP:
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: ru-RU,ru;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: 1Përgjigje:
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
<ajax-response>
<response type="object" id="unknown">
<generic response="Success" message="Authentication accepted"/>
</response>
</ajax-response>
Për të punuar atje ju duhet banesa_id="6f5de42c", pra vetë skedari i autorizimit.
Përmbajtja që ju duhet vetëm të kontrolloni për përgjigjen "Autentifikimi u pranua" Më pas, për të gjitha thirrjet në serverin PBX, do të na duhet të shtojmë një skedar autorizimi në kërkesë.
https://ats:8089/mxml?action=SIPpeers
Host: ats:8089
Connection: close
Cookie: mansession_id="6f5de42c"Lexoni se si të merrni një cookie autorizimi dhe ta përdorni atë në kërkesa të tjera këtu: "»
Për të krijuar elemente gjurmuese në Zabbix do të përdor zbulimin automatik.
Zbulimi automatik
Për të zbuluar automatikisht regjistrimet dhe për të gjurmuar gjendjet e kolegëve, duhet të kontaktoni adresën e mëposhtme: ose
Si përgjigje, PBX na kthen një përgjigje XML:
<ajax-response>
<response type="object" id="unknown">
<generic response="Success" eventlist="start" message="Registrations will follow"/>
</response>
...
<response type="object" id="unknown">
<generic event="RegistryEntry" host="login.mtt.ru" port="5060" username="111111" domain="login.mtt.ru" domainport="5060" refresh="105" state="Registered" registrationtime="1592502142"/>
</response>
<response type="object" id="unknown">
<generic event="RegistryEntry" host="voip.uiscom.ru" port="5060" username="222222" domain="voip.uiscom.ru" domainport="5060" refresh="105" state="Registered" registrationtime="1592502142"/>
</response>
<response type="object" id="unknown">
<generic event="RegistryEntry" host="voip.uiscom.ru" port="5060" username="333333" domain="voip.uiscom.ru" domainport="5060" refresh="105" state="Registered" registrationtime="1592502142"/>
</response>
...
</ajax-response>
Ka shumë mbeturina në përgjigje, kështu që gjatë përpunimit paraprak e filtrojmë sipas shabllonit XPath: //response/gjenerike[@host]
Pastaj fillon argëtimi. Për të punuar me zbulimin dhe për të krijuar në mënyrë dinamike elemente, përgjigja duhet të jetë në format JSON. XML nuk mbështetet për zbulimet automatike.
Për të kthyer XML në JSON, më duhej të luaja pak me zëvendësimin automatik, për të cilin bëra një skenar në JS
Një pikë interesante: në përgjigjen ATS, të gjithë parametrat janë të rrethuar nga thonjëza të vetme, dhe pas aplikimit të shabllonit //response/gjenerike[@host] ato zëvendësohen me të dyfishta.
Për të krijuar elementë, ne përdorim variabla nga përgjigja XML (tani JSON).
Regjistri SIP
Për regjistrimet e gllënjkës ne përdorim tre variabla: Emri i përdoruesit, mikpritës, port. Isha i kënaqur me emrin e elementit [email mbrojtur]: 5060, Nuk kam gjetur asnjë situatë ku duhet të përdorni të pesë variablat.
Elementi kryesor që merr informacion për të gjitha regjistrimet, Asterisk - AMI SIP Showregistry. Një herë në minutë ai bën një kërkesë GET , pas së cilës të dhënat XML të përgjigjes u kalohen të gjithë elementëve të varur për analizim. Për çdo regjistrim krijoj një element të varur prej tij. Kjo është e përshtatshme sepse ne marrim informacione të përditësuara në një kërkesë, dhe jo për secilën kërkesë veç e veç. Ky zbatim ka një pengesë të rëndësishme - ngarkesën në procesor.
Kur testova deri në 100 elementë të varur, nuk e vura re ngarkesën, por me 1700 elementë, kjo dha një ngarkesë të dukshme prej 15 sekondash në procesor. Mbajeni këtë parasysh nëse keni një numër të madh elementësh të varur.
Si një opsion për të "përhapur" ngarkesën ose për të vendosur frekuenca të ndryshme votimi për një element, ju mund të zhvendosni logjikën e përpunimit në secilin element veç e veç.
Unë nuk e ruaj informacionin e marrë në elementin kryesor. Së pari, nuk e shoh nevojën për këtë, dhe së dyti, nëse përgjigja është më shumë se 64K, atëherë Zabbix e ndërpret atë.
Meqenëse ne përdorim një përgjigje të plotë XML për elementin e varur, duhet të marrim vlerën e këtij elementi në parapërpunim. përmes XPath kjo është bërë si kjo:
string(//response/generic[@event="RegistryEntry"][@username="{#SIP_REGISTRY_USERNAME}"][@host="{#SIP_REGISTRY_HOST}"][@port="{#SIP_REGISTRY_PORT}"]/@ shtet)
Për statuset e regjistrimit, unë nuk përdora statuse teksti, por i konvertova në formë numerike duke përdorur JavaScript:
switch(value) {
case 'Registered':
return 1;
case 'Unregistered':
return 0;
default:
return -1;
}
SIP Peers
Për analogji me regjistrimet SIP, ekziston një element kryesor i Asterisk - AMI SIPshowregistry, të cilit i shtohen ato të varura.
Kjo krijon dy elementë të varur:
- Statusi i kolegëve në formë teksti
- Koha e përgjigjes së pajisjes - nëse statusi është në rregull, atëherë shkruhet koha e përgjigjes së pajisjes, përndryshe "-1"
Rruga drejt vetë elementit është pak më e thjeshtë XPath:
string(//response/generic[@objectname="{#SIP_PEER_OBEJECTNAME}"]/@status)
Për elementin e dytë kam përdorur JavaScript për të ndarë koha e përgjigjes nga statusi i kolegëve, pasi ato ruhen së bashku:
if(value.substring(0,2) == 'OK'){
return value.match(/(d+)/gm);
}
else {
return -1;
}Përfundim
Një zgjidhje jashtë kutisë mund të jetë komplekse dhe jo menjëherë e qartë. Rrit fleksibilitetin dhe transportueshmërinë ndërmjet sistemeve të ndryshme
Gëzuar dhe integrim të lehtë të gjithëve! Modeli dhe udhëzimet për konfigurimin .
Burimi: www.habr.com