Kiel konekti Zabbix kun Asterisk el la skatolo

En la antaŭa artikolo "Zabbix - vastiganta makrolimojn" Mi diris al vi kiel ricevi rajtigan sesion kaj anstataŭigi ĝin en lokan gastigan makroon. En ĉi tiu artikolo mi rakontos al vi kiel konekti Zabbix kun Asterisk sen eksteraj skriptoj kaj programaro.

La ideo "amiki" de ĉi tiuj du sistemoj naskiĝis antaŭ longe, sen instali pliajn programojn aŭ skriptojn. Rapida gugligado donis multajn eblajn solvojn, ĉio resumiĝis al tio, ke alŝutu la skriptojn (en Pyha, Bash, Python, ktp.) al la servilo, kaj vi estos feliĉa. Mi volis efektivigi monitoradon "el la skatolo" - sen eksteraj skriptoj kaj instali aldonan programaron sur la servilo kun monitorado kaj PBX.

Mi pasigis entute 4 labortagojn kun ĉi tio, sed la rezulto valoris ĝin. Labori tra la AMI-interfaco, malaltnivela detekto, ellasiloj, kaj plej grave, konekti la PBX kaj ĉiujn aliajn agordojn nun daŭras ĉirkaŭ 15 minutojn.

Zabbix 4.4 estas havebla, proksimume 100 pecoj de Asterisk-versio 13. Iuj PBXoj venas kun la interfaco FreePBX, iuj kun nuda konzolo, amaso da lertaĵoj kaj integriĝo per telefonplano.

Ricevante datumojn de la PBX

La unua kaj ĉefa punkto, kiu devas esti solvita, estas akiri datumojn pri samuloj kaj SIP-registradoj. Por tiu celo, la PBX havas AGI, AMI, ARI kaj SSH-konzolinterfacojn. Pro evidentaj kialoj, mi ne konsideris pliajn modulojn.

Unue ni devas eltrovi, kio estas ĉi tiuj agi, ami, ari...

  • AGI - uzante skriptojn en la dialplano. Ĉefe uzata por administrado de vokoj.
  • AMI - povas provizi ĉiujn necesajn informojn, funkcias per haveno 5038, simile al Telnet. konvenas al ni!
  • ARI - moderna, moda, JSON. Estas multaj eblecoj, la datumformato estas komprenebla por Zabbix, sed por mi ne estas ĉefa afero: vi ne povas kontroli la sip-registradon. Alia malavantaĝo estas, ke por samuloj ekzistas nur du ŝtatoj interrete/senrete, kvankam ekzistas pli da ŝtatoj kaj estas utile konsideri ilin dum diagnozo.
  • SSH povas fari ĉion, sed foje ĝi ne estas permesita pro "sekurecaj kialoj". Konsideroj povas esti malsamaj, mi ne eniros ilin.

Tamen, kun ĉiuj ĝiaj mankoj, ARI kovras 90% de ĉiuj monitoraj bezonoj.

Zabbix kaj Telnet - mia seniluziiĝo

Mi bone konas AMI; iam mi efektivigis spuradon de perdoj en konversacioj kun dividado per foraj oficejoj, voka administrado ktp. Kun Telnet, ĉio estas ankaŭ tre klara: malfermu la konekton, sendu la komandojn kaj legu la respondon. Tion mi faris, sed la rezulto seniluziigis min.

Telnet en Zabbix ne estas la sama kiel en la Linukso-konzolo, ĝi estas iom pli simpla kaj adaptita por norma rajtigo kiel ensaluto/pasvorto. Se la rajtiga logiko estas malsama, kaj ne estas peto por ensaluto/pasvorto paro, eraro okazas. Post vanaj provoj preteriri la rajtigan postulon, estis utile rigardi la fontkodon de la Telnet-modulo.

Mi rimarkis, ke ĝis estos tradicia ensaluto kaj pasvorta peto, mi ne antaŭeniros. Nur por amuzo, mi forigis ĉion rilatan al rajtigo de la kodo kaj rekonstruis ĉion. Verkoj! Sed ĝi ne plenumas la postulojn. Antaŭeniri…

Ni revenu al la serĉo

Mi relegis la ARI-dokumentadon denove, faris pliajn testojn - ĉi tie ne estas sip-registraĵoj. Estas festenoj, estas konversacioj, estas pantalonoj, sed ne estas registriĝoj. Iam mi eĉ pensis, ĉu ni vere bezonas vulturregistradon?

Pro amuza koincido, ĉi-momente alvenas alia peto de la uzanto, kun problemo kun elirantaj vokoj. La problemo estis, ke la sip-registro frostiĝis kaj estis solvita simple rekomencante la modulon.

asterisk -rx "sip reload"

Estus bonege aliri AMI per la reto: tio solvus ĉiujn problemojn, mi pensis. Mi komencas fosi en ĉi tiu direkto, kaj laŭvorte la unua serĉlinio kondukas al la oficiala Asterisk-dokumentado, kiu diras, ke ekzistas opcio por miaj taskoj. retebligita en dosiero /etc/asterisk/manager.conf, kiu devas esti agordita al JES, en la sekcio [ĝenerale]

Post tio, per regula TTT-peto de la formo http://ats:8089/mxml?action=SIPshowregistry ni ricevas ĉiujn necesajn informojn.

Kiam vi uzas la interfacon FreePBX, vi ne povas ebligi ĉi tiun opcion per la reto; vi devas ebligi ĝin per la konzolo per ŝanĝoj en la dosiero manager.conf. FreePBX ne forigas ĝin kiam agordaj ŝanĝoj estas faritaj per la reto.

Mi laboris kun diversaj specoj de Asterisk-integriĝoj dum longa tempo, sed mi neniam vidis ĉi tiun funkcion menciitan ie ajn. Mi surpriziĝis, ke neniu priskribas ĉi tiun metodon de interagado kun la PBX. Eĉ estis speciale utile serĉi informojn pri tiu ĉi temo: estas preskaŭ nenio aŭ ĝi estis uzata por tute malsamaj taskoj.

WEB AMI - kia besto?

Aldonante opcion retebligita arkivi manaĝero.konf provizis plenan aliron al ATS-administrado per la reto. Ĉiuj komandoj disponeblaj per regula AMI nun estas en la reto, vi povas aŭskulti eventojn de la PBX per ingo. La principo de funkciado ne diferencas de la konzolo AMI. Post aktivigo de ĉi tiu opcio, vi povas kontakti la PBX ĉe la sekvaj adresoj:

https://ats:8089/manager — retpaĝo kun simpla interfaco por testi kaj mane sendi petojn. Ĉiuj respondoj estas formatitaj en legeblan HTML. Ne tre taŭga por monitorado.
https://ats:8089/rawman — nur teksta eligo, formato simila al konzolo AMI
https://ats:8089/mxml - nur teksta eligo, en XML-formato. konvenas al ni!

Kiel konekti Zabbix kun Asterisk el la skatolo

Tiam mi pensis: “Jen la solvo! Nun ĉio estos preta! Facile-peezy lemon squeezey,” sed estis tro frue por ĝoji. Por akiri la informojn, kiujn ni bezonas, sufiĉas uzi GET-peton kun la necesa ago ago, kiu responde resendas xml kun listo de ĉiuj registradoj kaj ilia stato. Ĉio ĉi estas bonega, sed vi bezonas rajtigon por memori la sesion de la kuketo. Kiam vi testas en la retumilo, vi ne pensas pri ĉi tiu procezo.

Procezo de rajtigo

Unue ni traktas la adreson http://ats:8089/mxml?action=login&username=zabbix&secret=zabbix, en respondo, la servilo sendas al ni kuketon kun la rajtiga sesio. Jen kiel aspektas HTTP-peto:

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: 1

Respondo:

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>

Por labori tie vi bezonas mansession_id="6f5de42c", t.e. la rajtiga kuketo mem.
Enhavo, kiun vi nur bezonas kontroli por la respondo "Aŭtentigo akceptita" Poste, por ĉiuj vokoj al la PBX-servilo, ni devos aldoni rajtigan kuketon al la peto.

https://ats:8089/mxml?action=SIPpeers

Host: ats:8089
Connection: close
Cookie: mansession_id="6f5de42c"

Legu kiel akiri rajtigan kuketon kaj uzi ĝin en aliaj petoj ĉi tie: "Zabbix - vastiganta makrolimojn»

Por krei spurajn elementojn en Zabbix mi uzos aŭtomatan detekton.

Aŭtomata detekto

Por aŭtomate detekti registradojn kaj spuri kunajn ŝtatojn, vi devas kontakti la sekvan adreson: https://ats:8089/mxml?action=SIPshowregistryhttps://ats:8089/mxml?action=SIPpeers

En respondo, la PBX resendas al ni XML-respondon:

<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>

Estas multe da rubo en la respondo, do en antaŭprilaborado ni filtras ĝin laŭ ŝablono XPath: //response/generic[@gastiganto]
Tiam la amuzo komenciĝas. Por labori kun detekto kaj dinamike krei elementojn, la respondo devas esti en JSON-formato. XML ne estas subtenata por aŭtomataj detektoj.

Por konverti XML al JSON, mi devis ludi iomete per aŭtomata anstataŭigo, por kiu mi faris skripton en JS

Kiel konekti Zabbix kun Asterisk el la skatolo

Interesa punkto: en la respondo de ATS, ĉiuj parametroj estas ĉirkaŭitaj de unuopaj citiloj, kaj post aplikado de la ŝablono //response/generic[@gastiganto] ili estas anstataŭigitaj per duoblaj.

Por krei elementojn, ni uzas variablojn de la XML-respondo (nun JSON).

Kiel konekti Zabbix kun Asterisk el la skatolo

SIP-Registro

Por trinketaj registradoj ni uzas tri variablojn: uzantonomo, gastiganto, haveno. Mi estis feliĉa kun la nomo de la elemento [retpoŝte protektita]: 5060, Mi ne trovis iujn ajn situaciojn, kie vi bezonas uzi ĉiujn kvin variablojn.

La ĉefa elemento, kiu ricevas informojn pri ĉiuj registriĝoj, Asterisko - AMI SIPshowregistry. Unufoje minuton ĝi faras GET peton al https://ats:8089/mxml?action=SIPshowregistry, post kiu la respondaj XML-datumoj estas transdonitaj al ĉiuj dependaj elementoj por analizado. Por ĉiu registriĝo mi kreas elementon dependan de ĝi. Ĉi tio estas oportuna ĉar ni ricevas ĝisdatajn informojn en unu peto, kaj ne por ĉiu peto aparte. Ĉi tiu efektivigo havas gravan malavantaĝon - la ŝarĝo sur la procesoro.

Provante ĝis 100 dependaj elementoj, mi ne rimarkis la ŝarĝon, sed kun 1700 elementoj, ĉi tio donis rimarkindan 15-sekundan ŝarĝon sur la procesoro. Memoru ĉi tion se vi havas grandan nombron da dependaj elementoj.

Kiel opcio por "disvastigi" la ŝarĝon aŭ agordi malsamajn balotajn frekvencojn por elemento, vi povas movi la pretigan logikon al ĉiu elemento aparte.

Mi ne konservas la ricevitajn informojn en la ĉefa elemento. Unue, mi ne vidas la bezonon de ĉi tio, kaj due, se la respondo estas pli ol 64K, tiam Zabbix forigas ĝin.

Ĉar ni uzas plenan XML-respondon por la dependa elemento, ni devas akiri la valoron de ĉi tiu elemento en antaŭprilaborado. Tra XPath ĝi fariĝas jene:
string(//response/generic[@event="RegistryEntry"][@username="{#SIP_REGISTRY_USERNAME}"][@host="{#SIP_REGISTRY_HOST}"][@port="{#SIP_REGISTRY_PORT}"]/@ ŝtato)
Por registraj statusoj, mi ne uzis tekstajn statusojn, sed konvertis ilin al nombra formo per JavaScript:

switch(value) {
  case 'Registered':
    return 1;
  case 'Unregistered':
    return 0;
  default:
    return -1;
}

SIP Samuloj

Analogie kun SIP-registroj, ekzistas ĉefa elemento de Asterisk - AMI SIPshowregistry, al kiu dependaj estas aldonitaj.

Ĉi tio kreas du dependajn elementojn:

  • Sama statuso en teksta formo
  • Tempo de respondo de la aparato - se la stato estas bona, tiam la tempo de respondo de la aparato estas skribita, alie "-1"

La vojo al la elemento mem estas iom pli simpla XPath:

string(//response/generic[@objectname="{#SIP_PEER_OBEJECTNAME}"]/@status)

Por la dua elemento mi uzis JavaScript por apartigi responda tempo de la samranga statuso, ĉar ili estas stokitaj kune:

if(value.substring(0,2) == 'OK'){
	return value.match(/(d+)/gm);
}
else {
	return -1;
}

konkludo

Eksterordinara solvo povas esti kompleksa kaj ne tuj klara. Pliigas flekseblecon kaj porteblon inter malsamaj sistemoj

Feliĉa kaj facila integriĝo ĉiuj! Ŝablono kaj instrukcioj por agordo GitHub.

fonto: www.habr.com

Aldoni komenton