En un article anterior Us vaig dir com rebre una sessió d'autorització i substituir-la per una macro d'amfitrió local. En aquest article us explicaré com connectar Zabbix amb Asterisk sense scripts i programari externs.
La idea de "fer amics" d'aquests dos sistemes va néixer fa molt de temps, sense instal·lar programari ni scripts addicionals. Una ràpida recerca de google va donar moltes possibles solucions, tot es va reduir al fet de pujar els scripts (en Pyha, Bash, Python, etc.) al servidor i estareu contents. Volia implementar la supervisió "fora de la caixa", sense scripts externs i instal·lar programari addicional al servidor amb monitorització i PBX.
Vaig passar un total de 4 dies laborables amb això, però el resultat va valdre la pena. Treballar a través de la interfície AMI, detecció de baix nivell, activadors i, el més important, connectar la central i totes les altres configuracions triga uns 15 minuts.
Zabbix 4.4 està disponible, unes 100 peces de la versió 13 d'Asterisk. Alguns PBX inclouen la interfície web FreePBX, alguns amb una consola nua, un munt de trucs i integració mitjançant un pla de marcació.
Recepció de dades de la central
El primer i principal punt que cal resoldre és l'obtenció de dades sobre iguals i registres SIP. Amb aquesta finalitat, la central té interfícies de consola AGI, AMI, ARI i SSH. Per raons òbvies, no vaig considerar mòduls addicionals.
Primer hem d'esbrinar què són aquests agi, ami, ari...
- AGI: utilitzant scripts al pla de marcatge. S'utilitza principalment per a la gestió de trucades.
- AMI: pot proporcionar tota la informació necessària, funciona a través del port 5038, similar a Telnet. Ens convé!
- ARI - modern, de moda, JSON. Hi ha moltes possibilitats, el format de les dades és comprensible per a Zabbix, però per a mi no hi ha res principal: no podeu controlar el registre del glop. Un altre inconvenient és que per als companys només hi ha dos estats online/offline, tot i que n'hi ha més i és útil tenir-los en compte a l'hora de diagnosticar.
- SSH pot fer de tot, però de vegades no està permès per "motius de seguretat". Les consideracions poden ser diferents, no hi entraré.
No obstant això, amb totes les seves mancances, ARI cobreix el 90% de totes les necessitats de seguiment.
Zabbix i Telnet: la meva decepció
Conec bé AMI en un moment en què vaig implementar el seguiment de pèrdues en converses amb divisió per oficines remotes, gestió de trucades, etc. Amb Telnet, també està tot molt clar: obriu la connexió, envieu les ordres i llegiu la resposta. Això és el que vaig fer, però el resultat em va decebre.
El Telnet de Zabbix no és el mateix que el de la consola. LinuxÉs una mica més senzill i està dissenyat per a l'autenticació estàndard d'inici de sessió/contrasenya. Si la lògica d'autenticació és diferent i no es sol·licita cap parell d'inici de sessió/contrasenya, es produeix un error. Després d'intentar sense èxit eludir el requisit d'autenticació, vaig començar a mirar el codi font del mòdul Telnet.
Em vaig adonar que fins que no hi hagi una sol·licitud d'inici de sessió i contrasenya tradicional, no avançaré. Només per divertir-me, vaig eliminar del codi tot allò relacionat amb l'autorització i ho vaig tornar a muntar. Funciona! Però no compleix els requisits. Endavant…
Tornem a la recerca
Vaig tornar a llegir la documentació de l'ARI, vaig fer proves addicionals: aquí no hi ha registres per sip. Hi ha festes, hi ha converses, hi ha calzones, però no hi ha inscripcions. En algun moment fins i tot vaig pensar, realment necessitem el registre de voltors?
Per una divertida coincidència, en aquest moment arriba una altra petició de l'usuari, amb un problema amb les trucades sortints. El problema va ser que el registre sip s'estava congelant i es va resoldre simplement reiniciant el mòdul.
asterisk -rx "sip reload"Seria fantàstic accedir a AMI a través del web: això resoldria tots els problemes, vaig pensar. Començo a cavar en aquesta direcció i, literalment, la primera línia de cerca condueix a la documentació oficial d'Asterisk, que diu que hi ha una opció per a les meves tasques. habilitat per a la web a l'arxiu /etc/asterisk/manager.conf, que s'ha d'establir en SÍ, a la secció [general]
Després d'això, mitjançant una sol·licitud web habitual del formulari obtenim tota la informació necessària.
Quan utilitzeu la interfície FreePBX, no podeu habilitar aquesta opció a través del web, heu d'activar-la a través de la consola fent canvis al fitxer manager.conf. FreePBX no l'esborra quan es fan canvis de configuració a través del web.
He treballat amb diversos tipus d'integracions d'Asterisk durant molt de temps, però mai no he vist esmentar aquesta funció enlloc. Em va sorprendre que ningú descrigui aquest mètode d'interacció amb la central. Fins i tot va ser especialment útil buscar informació sobre aquest tema: pràcticament no hi ha res o s'utilitzava per a tasques completament diferents.
WEB AMI: quin tipus de bèstia?
Afegint una opció habilitat per a la web arxivar gestor.conf proporcionava accés complet a la gestió ATS a través del web. Totes les ordres disponibles a través d'una AMI normal es troben ara al web, podeu escoltar esdeveniments des de la central mitjançant un sòcol. El principi de funcionament no és diferent de l'AMI de la consola. Després d'activar aquesta opció, podeu contactar amb la central a les adreces següents:
— una pàgina web amb una interfície senzilla per provar i enviar sol·licituds manualment. Totes les respostes tenen un format HTML llegible. Poc adequat per al seguiment.
— Només sortida de text, format similar a l'AMI de la consola
- només sortida de text, en format XML. Ens convé!
Llavors vaig pensar: “Aquesta és la solució! Ara tot estarà a punt! Espremedora de llimona fàcil de fer", però era massa aviat per alegrar-se. Per obtenir la informació que necessitem, n'hi ha prou amb utilitzar una sol·licitud GET amb l'acció necessària acció, que en resposta retorna xml amb una llista de tots els registres i el seu estat. Tot això és fantàstic, però necessiteu autorització per recordar la sessió de la galeta. Quan proveu al navegador, no penseu en aquest procés.
Procés d'autorització
Primer ens dirigim a l'adreça , com a resposta, el servidor ens envia una cookie amb la sessió d'autorització. Així és com es veu una sol·licitud 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: 1Resposta:
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> Per treballar-hi necessites mansession_id="6f5de42c", és a dir, la pròpia galeta d'autorització.
Contingut que només has de comprovar la resposta "S'ha acceptat l'autenticació" A continuació, per a totes les trucades al servidor PBX, haurem d'afegir una galeta d'autorització a la sol·licitud.
https://ats:8089/mxml?action=SIPpeers
Host: ats:8089
Connection: close
Cookie: mansession_id="6f5de42c"Llegiu com obtenir una galeta d'autorització i utilitzar-la en altres sol·licituds aquí: "»
Per crear elements de seguiment a Zabbix, utilitzaré la detecció automàtica.
Detecció automàtica
Per detectar automàticament els registres i fer un seguiment dels estats iguals, cal que us poseu en contacte amb l'adreça següent: o
En resposta, la central ens retorna una resposta 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> Hi ha moltes escombraries a la resposta, de manera que en el preprocessament la filtrem per plantilla XPath: //resposta/genèric[@host]
Llavors comença la diversió. Per treballar amb la detecció i crear elements dinàmicament, la resposta ha d'estar en format JSON. XML no és compatible amb les deteccions automàtiques.
Per convertir XML a JSON, vaig haver de jugar una mica amb la substitució automàtica, per a la qual vaig fer un script en JS
Un punt interessant: a la resposta ATS, tots els paràmetres estan envoltats per cometes simples i després d'aplicar la plantilla //resposta/genèric[@host] se substitueixen per dobles.
Per crear elements, utilitzem variables de la resposta XML (ara JSON).
Registre SIP
Per als registres per glop utilitzem tres variables: nom d'usuari, host, port. Estic content amb el nom de l'element 111111@login.mtt.ru:5060, no he trobat cap situació en què hàgiu d'utilitzar les cinc variables.
L'element principal que rep informació sobre totes les inscripcions, Asterisk - AMI SIPshowregistry. Una vegada per minut fa una sol·licitud GET a , després del qual les dades XML de resposta es passen a tots els elements dependents per analitzar-los. Per a cada registre en creo un element dependent. Això és convenient perquè rebem informació actualitzada en una sol·licitud, i no per a cada sol·licitud per separat. Aquesta implementació té un inconvenient important: la càrrega del processador.
Quan vaig provar fins a 100 elements dependents, no vaig notar la càrrega, però amb 1700 elements, això va donar una càrrega notable de 15 segons al processador. Tingueu-ho en compte si teniu un gran nombre d'elements dependents.
Com a opció per "estendre" la càrrega o establir diferents freqüències de sondeig per a un element, podeu moure la lògica de processament a cada element per separat.
No guardo la informació rebuda a l'element principal. En primer lloc, no veig la necessitat d'això i, en segon lloc, si la resposta és de més de 64K, Zabbix ho talla.
Com que utilitzem una resposta XML completa per a l'element dependent, hem d'obtenir el valor d'aquest element en el preprocessament. A través de XPath es fa així:
string(//response/generic[@event="RegistryEntry"][@username="{#SIP_REGISTRY_USERNAME}"][@host="{#SIP_REGISTRY_HOST}"][@port="{#SIP_REGISTRY_PORT}"]/@ estat)
Per als estats de registre, no vaig utilitzar estats de text, sinó que els vaig convertir en forma numèrica mitjançant JavaScript:
switch(value) {
case 'Registered':
return 1;
case 'Unregistered':
return 0;
default:
return -1;
}
SIP Peers
Per analogia amb els registres SIP, hi ha un element principal d'Asterisk - AMI SIPshowregistry, al qual s'afegeixen els depenents.
Això crea dos elements dependents:
- Estat dels iguals en forma de text
- Temps de resposta del dispositiu: si l'estat és correcte, s'escriu el temps de resposta del dispositiu, en cas contrari "-1"
El camí cap a l'element en si és una mica més senzill XPath:
string(//response/generic[@objectname="{#SIP_PEER_OBEJECTNAME}"]/@status)
Per al segon element he utilitzat JavaScript per separar-lo temps de resposta de l'estat d'igual, ja que s'emmagatzemen junts:
if(value.substring(0,2) == 'OK'){
return value.match(/(d+)/gm);
}
else {
return -1;
}Conclusió
Una solució fora de la caixa pot ser complexa i no clara immediatament. Augmenta la flexibilitat i la portabilitat entre diferents sistemes
Feliç i fàcil integració a tothom! Plantilla i instruccions per a la seva configuració .
Font: www.habr.com
