Dans l'article précédent J'ai expliqué comment obtenir une session d'authentification et l'intégrer dans un macro local de l'hÎte. Dans cet article, je vais expliquer comment faire fonctionner Zabbix avec Asterisk sans scripts externes ni logiciels.
L'idĂ©e de « faire fonctionner » ces deux systĂšmes est nĂ©e il y a longtemps, sans installer de logiciels ou de scripts supplĂ©mentaires. Une recherche rapide sur Google a donnĂ© de nombreuses solutions, mais tout se rĂ©duisait Ă dĂ©poser des scripts (en PHP, Bash, Python, etc.) sur le serveur, et cela vous apporterait la satisfaction. Je souhaitais en revanche rĂ©aliser la surveillance « clĂ© en main » â sans scripts externes ni installation de logiciels supplĂ©mentaires sur le serveur de surveillance et la centrale tĂ©lĂ©phonique.
J'ai travaillé là -dessus pendant 4 jours de travail, mais le résultat en valait la peine. Travailler via l'interface AMI, détection de bas niveau, déclencheurs, et surtout, la connexion à la centrale téléphonique et tous les autres réglages ne prennent maintenant que 15 minutes.
En ce qui concerne Zabbix 4.4, il y a environ 100 systÚmes Asterisk de la version 13. Certaines centrales téléphoniques ont une interface web FreePBX, d'autres ont une console basique, avec un tas d'astuces et d'intégration via le plan de numérotation.
Obtenir des données de la centrale téléphonique
Le premier et principal point à résoudre est l'acquisition des données sur les pairs et les enregistrements SIP. Pour ce faire, la centrale téléphonique dispose d'interfaces AGI, AMI, ARI et d'une console SSH. Je n'ai pas considéré les modules supplémentaires pour des raisons évidentes.
Pour commencer, il faut comprendre ce que sont ces AGI, AMI, ARI....
- AGI â utilisation de scripts dans le plan de numĂ©rotation. Principalement utilisĂ© pour la gestion des appels.
- AMI â capable de fournir toutes les informations nĂ©cessaires, fonctionne via le port 5038, Ă l'instar de Telnet. C'est parfait pour nous !
- ARI â moderne, Ă la mode, basĂ© sur JSON. Beaucoup de possibilitĂ©s, format de donnĂ©es dans un format comprĂ©hensible pour Zabbix, mais pour moi, il manque l'essentiel : il n'est pas possible de contrĂŽler l'enregistrement SIP. Un autre inconvĂ©nient est qu'il n'y a que deux Ă©tats pour les pairs : en ligne/hors ligne, alors qu'il y a plus d'Ă©tats et il serait utile de les prendre en compte lors du diagnostic.
- SSH â peut tout faire, mais parfois, il n'est pas accordĂ© pour des « raisons de sĂ©curitĂ© ». Ces prĂ©occupations peuvent varier, je ne vais pas les examiner.
Néanmoins, malgré tous ses défauts, ARI couvre 90 % des besoins de surveillance.
Zabbix et Telnet â ma dĂ©ception.
Je connais bien AMI, j'avais mis en place le suivi des pertes lors des appels avec répartition entre les bureaux distants, la gestion des appels, etc. Pour Telnet, c'est également trÚs clair : ouvre la connexion, envoie des commandes et lis la réponse. C'est ce que j'ai fait, mais le résultat m'a déçu.
Telnet dans Zabbix n'est pas le mĂȘme que dans la console Linux, il est un peu plus simple et conçu pour l'authentification standard du type login/mot de passe. Si la logique d'authentification est diffĂ©rente et qu'il n'y a pas de demande de paire login/mot de passe, une erreur survient. AprĂšs d'innombrables tentatives de contourner cette exigence d'authentification, j'ai dĂ©cidĂ© de regarder le code source du module Telnet.
J'ai compris que tant qu'il n'y aurait pas de demande traditionnelle de login avec mot de passe, je ne progresserais pas. Par curiositĂ©, j'ai retirĂ© du code tout ce qui touchait Ă l'authentification et j'ai tout recompilĂ©. Ăa fonctionne ! Mais ça ne correspond pas aux exigences. Continuons...
Retour Ă la recherche
J'ai relu la documentation sur ARI et effectuĂ© des tests supplĂ©mentaires â il n'y a pas d'enregistrements SIP ici. Il y a des pairs, il y a des conversations, il y a des ponts, mais pas d'enregistrements. Ă un moment, je me suis mĂȘme demandĂ©, avons-nous vraiment besoin d'enregistrements SIP ?
Par un curieux concours de circonstances, un nouvel utilisateur m'a envoyé une demande concernant un problÚme d'appels sortants. Le problÚme était dû à un blocage de l'enregistrement SIP, résolu simplement par un redémarrage du module.
asterisk -rx "sip reload"Ce serait génial d'accéder à AMI via le web : cela résoudrait tous les problÚmes, me suis-je dit. Je commence à creuser dans cette direction, et la toute premiÚre ligne de recherche me renvoie à la documentation officielle d'Asterisk, qui indique qu'il existe une option pour mes besoins. webenabled dans le fichier /etc/asterisk/manager.conf, que je dois régler sur YES, dans la section [general]
AprĂšs cela, en effectuant une requĂȘte web normale de type on obtient toutes les informations nĂ©cessaires.
En utilisant l'interface FreePBX, on ne peut pas activer cette option via le web, il faut l'activer par la console en modifiant le fichier manager.conf. FreePBX ne l'efface pas lors des modifications de configuration via le web.
Au cours de mes travaux avec divers types d'intĂ©grations Asterisk, je n'ai jamais vu mentionner cette fonctionnalitĂ©. Cela m'a Ă©tonnĂ© que personne ne dĂ©crit ce mode d'interaction avec le PBX. J'ai mĂȘme cherchĂ© des informations sur ce sujet : pratiquement rien n'existe ou cela a Ă©tĂ© utilisĂ© pour des tĂąches complĂštement diffĂ©rentes.
WEB AMI â qu'est-ce que c'est ?
Ajout de l'option webenabled dans le fichier manager.conf ouvrait un accĂšs complet Ă la gestion de l'IPBX via le web. Toutes les commandes disponibles via l'AMI classique sont dĂ©sormais accessibles sur le web, il est possible d'Ă©couter les Ă©vĂ©nements de l'IPBX via un socket. Le principe de fonctionnement n'est pas diffĂ©rent de l'AMI en ligne de commande. AprĂšs l'activation de cette option, l'IPBX peut ĂȘtre accĂ©dĂ© aux adresses suivantes :
une page web avec une interface simple, pour des tests et l'envoi manuel de requĂȘtes. Toutes les rĂ©ponses sont formatĂ©es en HTML lisible. Pas trĂšs adaptĂ© pour le monitoring.
uniquement une sortie textuelle, le format est similaire Ă l'AMI en ligne de commande.
uniquement une sortie textuelle, au format XML. Ăa m'intĂ©resse !
Ă ce moment, j'ai pensĂ© : « VoilĂ â la solution ! Tout sera prĂȘt maintenant ! Facile comme tout », mais il Ă©tait encore trop tĂŽt pour se rĂ©jouir. Pour obtenir les informations nĂ©cessaires, il suffit d'utiliser une requĂȘte GET avec l'action requise action, qui retourne en rĂ©ponse un XML avec la liste de tous les enregistrements et leur Ă©tat. Tout cela est super, mais une autorisation avec mĂ©morisation de session depuis les cookies est nĂ©cessaire. Quand on teste dans le navigateur, on ne pense pas Ă ce processus.
Le processus d'autorisation
Au dĂ©but, nous nous adressons Ă l'adresse , en rĂ©ponse le serveur nous envoie un cookie avec la session d'autorisation. Voici Ă quoi ressemble la requĂȘte 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: fr-FR,fr;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: 1RĂ©ponse :
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 Pour cela, il faut mansession_id="6f5de42c", c'est-Ă -dire le cookie d'autorisation lui-mĂȘme.
Il suffit de vĂ©rifier la prĂ©sence de la rĂ©ponse «Authentication accepted». Ensuite, pour toutes les requĂȘtes au serveur IPBX, il sera nĂ©cessaire d'ajouter le cookie d'autorisation dans la requĂȘte.
https://ats:8089/mxml?action=SIPpeers
Host: ats:8089
Connection: close
Cookie: mansession_id="6f5de42c"Pour savoir comment obtenir le cookie d'autorisation et l'utiliser dans d'autres requĂȘtes, lisez ici : «»
Pour créer des éléments de suivi dans Zabbix, je vais utiliser la détection automatique.
DĂ©tection automatique
Pour la détection automatique des enregistrements et le suivi des états des pairs, il est nécessaire de s'adresser à l'adresse : ou
En réponse, l'IPBX nous retourne une réponse XML :
...
... La réponse contient beaucoup de bruit, c'est pourquoi nous le filtrons dans le prétraitement selon un modÚle. XPath: //response/generic[@host]
Ensuite, commence la partie la plus intéressante. Pour travailler avec la détection et créer dynamiquement des éléments, il faut que la réponse soit au format JSON. XML n'est pas pris en charge lors des détections automatiques.
Pour convertir XML en JSON, j'ai dĂ» un peu jouer avec le remplacement automatique, c'est pourquoi j'ai fait un script en JS.
Un point intéressant, dans la réponse de la centrale, tous les paramÚtres sont entourés de guillemets simples, et aprÚs l'application du modÚle, //response/generic[@host] ils sont remplacés par des guillemets doubles.
Pour créer des éléments, nous utilisons des variables de la réponse XML (maintenant JSON).
SIP Registry
Pour les enregistrements SIP, nous utilisons trois variables : username, host, port. Le nom de l'Ă©lĂ©ment me convenait. 111111@login.mtt.ru:5060, je n'ai pas trouvĂ© de situations oĂč il fallait utiliser toutes les cinq variables.
L'Ă©lĂ©ment principal qui reçoit des informations sur tous les enregistrements, Asterisk â AMI SIPshowregistry. Une fois par minute, il fait une requĂȘte GET Ă , aprĂšs quoi les donnĂ©es de la rĂ©ponse XML sont transmises Ă tous les Ă©lĂ©ments dĂ©pendants pour analyse. Je crĂ©e un Ă©lĂ©ment pour chaque enregistrement, dĂ©pendant de lui. C'est pratique, car nous obtenons des informations actuelles en une seule requĂȘte, et non pas pour chacune sĂ©parĂ©ment. Cette implĂ©mentation a un inconvĂ©nient majeur â la charge sur le processeur.
Lors des tests avec jusqu'à 100 éléments dépendants, je n'ai pas remarqué de charge, mais avec 1700 éléments, cela entraßnait une charge notable de 15 secondes sur le processeur. Gardez cela à l'esprit si vous avez un grand nombre d'éléments dépendants.
Une option pour "étaler" la charge ou établir une fréquence d'interrogation différente pour l'élément est de déplacer la logique de traitement dans chaque élément séparément.
Je ne conserve pas l'information obtenue dans l'élément principal. Tout d'abord, je ne vois pas la nécessité de le faire, et deuxiÚmement, si la réponse dépasse 64k, Zabbix la tronque.
Puisque nous utilisons une réponse XML complÚte pour l'élément dépendant, nous devons obtenir la valeur de cet élément dans le prétraitement. Via XPath cela se fait comme suit :
string(//response/generic[@event='RegistryEntry'][@username="{#SIP_REGISTRY_USERNAME}" ][@host="{#SIP_REGISTRY_HOST}"][@port="{#SIP_REGISTRY_PORT}"]/@state)
Pour les statuts d'enregistrement, je n'ai pas utilisé les statuts textuels, mais les ai convertis en forme numérique à l'aide de JavaScript :
switch(value) {
case 'Registered':
return 1;
case 'Unregistered':
return 0;
default:
return -1;
}
Pairs SIP
De mĂȘme pour les enregistrements SIP, il y a l'Ă©lĂ©ment principal Asterisk â AMI SIPshowregistry, auquel s'ajoutent les dĂ©pendants.
Ici, deux éléments dépendants sont créés :
- Statut du pair en forme textuelle
- Le temps de rĂ©ponse de l'appareil â si le statut est OK, le temps de rĂ©ponse de l'appareil est indiquĂ©, sinon «-1»
Le chemin vers l'élément est déjà un peu plus simple XPath:
string(//response/generic[@objectname="{#SIP_PEER_OBEJECTNAME}"]/@status)
Pour le deuxiÚme élément, j'ai utilisé JavaScript pour séparer le temps de réponse du statut du pair, car ils sont stockés ensemble :
if(value.substring(0,2) == 'OK'){
return value.match(/(d+)/gm);
}
else {
return -1;
}Conclusion
La solution «clĂ© en main» peut ĂȘtre complexe et pas toujours Ă©vidente. Cela augmente la flexibilitĂ© et la portabilitĂ© entre diffĂ©rents systĂšmes.
à tous, une intégration agréable et facile ! ModÚle et instructions pour la configuration sur .
Source : habr.com
