Dans un article précédent Je vous ai expliqué comment recevoir une session d'autorisation et la remplacer par une macro hôte locale. Dans cet article, je vais vous expliquer comment connecter Zabbix à Asterisk sans scripts ni logiciels externes.
L'idée de « se faire des amis » entre 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 possibles, tout se résumait au fait de télécharger les scripts (en Pyha, Bash, Python, etc.) sur le serveur, et vous serez heureux. Je voulais mettre en œuvre une surveillance « prête à l'emploi » - sans scripts externes et sans installer de logiciels supplémentaires sur le serveur avec surveillance et PBX.
J'ai passé au total 4 jours de travail avec cela, mais le résultat en valait la peine. Travailler via l'interface AMI, la détection de bas niveau, les déclencheurs et, surtout, la connexion du PBX et tous les autres paramètres prend désormais environ 15 minutes.
Zabbix 4.4 est disponible, environ 100 pièces d'Asterisk version 13. Certains PBX sont livrés avec l'interface Web FreePBX, d'autres avec une console nue, de nombreuses astuces et une intégration via un plan de numérotation.
Réception de données du PBX
Le premier et principal point à résoudre est l’obtention de données sur les pairs et les enregistrements SIP. A cet effet, le PBX dispose d'interfaces de console AGI, AMI, ARI et SSH. Pour des raisons évidentes, je n'ai pas envisagé de modules supplémentaires.
Nous devons d'abord 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 - peut fournir toutes les informations nécessaires, fonctionne via le port 5038, similaire à Telnet. Nous convient!
- ARI - moderne, à la mode, JSON. Il existe de nombreuses possibilités, le format des données est compréhensible pour Zabbix, mais pour moi il n'y a pas d'essentiel : vous ne pouvez pas contrôler l'enregistrement sip. Un autre inconvénient est que pour les pairs, il n'y a que deux états en ligne/hors ligne, bien qu'il y ait plus d'états et qu'il soit utile d'en tenir compte lors du diagnostic.
- SSH peut tout faire, mais parfois il n'est pas autorisé pour des « raisons de sécurité ». Les considérations peuvent être différentes, je n’entrerai pas dans les détails.
Cependant, malgré toutes ses lacunes, l'ARI couvre 90 % de tous les besoins en matière de suivi.
Zabbix et Telnet - ma déception
Je connais bien AMI, j'ai déjà mis en place le suivi des pertes dans les conversations avec division par bureaux distants, gestion des appels, etc. Avec Telnet, tout est également très clair : ouvrez la connexion, envoyez les commandes et lisez 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 adapté aux autorisations standard telles que login/mot de passe. Si la logique d'autorisation est différente et qu'il n'y a pas de demande de couple login/mot de passe, une erreur se produit. Après de vaines tentatives pour contourner l'exigence d'autorisation, il était utile de regarder le code source du module Telnet.
J'ai réalisé que tant qu'il n'y aura pas une demande traditionnelle de connexion et de mot de passe, je n'irai pas de l'avant. Juste pour m'amuser, j'ai supprimé du code tout ce qui concernait l'autorisation et j'ai tout réassemblé. Travaux! Mais cela ne répond pas aux exigences. Poursuivre…
Revenons à la recherche
J'ai relu la documentation ARI, effectué des tests supplémentaires - il n'y a pas d'enregistrement sip ici. Il y a des fêtes, il y a des conversations, il y a des culottes, mais il n'y a pas d'inscriptions. À un moment donné, je me suis même demandé : avons-nous vraiment besoin d’un enregistrement des vautours ?
Par une drôle de coïncidence, à ce moment une autre demande arrive de l'utilisateur, avec un problème d'appels sortants. Le problème était que l'enregistrement SIP était gelé et a été résolu en redémarrant simplement le module.
asterisk -rx "sip reload"Ce serait formidable d'accéder à AMI via le Web : cela résoudrait tous les problèmes, pensais-je. Je commence à creuser dans cette direction, et littéralement la première ligne de recherche mène à la documentation officielle d'Asterisk, qui dit qu'il existe une option pour mes tâches Webenabled dans le fichier /etc/asterisk/manager.conf, qui doit être défini sur OUI, dans la section [général]
Après cela, via une demande Web régulière du formulaire nous obtenons toutes les informations nécessaires.
Lorsque vous utilisez l'interface FreePBX, vous ne pouvez pas activer cette option via le Web, vous devez l'activer via la console en apportant des modifications au fichier manager.conf. FreePBX ne l'efface pas lorsque des modifications de configuration sont apportées via le Web.
Je travaille depuis longtemps avec différents types d'intégrations Asterisk, mais je n'ai jamais vu cette fonctionnalité mentionnée nulle part. J'ai été surpris que personne ne décrive cette méthode d'interaction avec le PBX. Il était même particulièrement utile de rechercher des informations sur ce sujet : il n'y en a pratiquement rien ou elles ont été utilisées pour des tâches complètement différentes.
WEB AMI - quel genre de bête ?
Ajout d'une option Webenabled déposer manager.conf fourni un accès complet à la gestion ATS via le Web. Toutes les commandes disponibles via une AMI classique sont désormais sur le Web, vous pouvez écouter les événements du PBX via un socket. Le principe de fonctionnement n'est pas différent de la console AMI. Après avoir activé cette option, vous pouvez contacter le PBX aux adresses suivantes :
— une page Web avec une interface simple pour tester et envoyer manuellement des demandes. Toutes les réponses sont formatées en HTML lisible. Peu adapté au suivi.
— sortie texte uniquement, format similaire à celui de la console AMI
- sortie texte uniquement, au format XML. Nous convient!
Puis j’ai pensé : « C’est la solution ! Maintenant, tout sera prêt ! Un jus de citron facile à presser », mais il était trop tôt pour se réjouir. Pour obtenir les informations dont nous avons besoin, il suffit d'utiliser une requête GET avec l'action nécessaire action, qui renvoie en réponse du XML avec une liste de tous les enregistrements et leur statut. Tout cela est très bien, mais vous avez besoin d'une autorisation pour mémoriser la session à partir du cookie. Lorsque vous testez dans le navigateur, vous ne pensez pas à ce processus.
Processus d'autorisation
Nous abordons d'abord l'adresse , en réponse, le serveur nous envoie un cookie avec la session d'autorisation. Voici à quoi ressemble une 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: 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: 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
<ajax-response>
<response type="object" id="unknown">
<generic response="Success" message="Authentication accepted"/>
</response>
</ajax-response>
Pour y travailler, il faut mansession_id="6f5de42c", c'est-à-dire le cookie d'autorisation lui-même.
Contenu, il vous suffit de vérifier la réponse "Authentification acceptée" Ensuite, pour tous les appels vers le serveur PBX, nous devrons ajouter un cookie d'autorisation à la demande.
https://ats:8089/mxml?action=SIPpeers
Host: ats:8089
Connection: close
Cookie: mansession_id="6f5de42c"Découvrez comment obtenir un cookie d'autorisation et l'utiliser dans d'autres demandes ici : «»
Pour créer des éléments de suivi dans Zabbix, j'utiliserai la détection automatique.
Détection automatique
Pour détecter automatiquement les inscriptions et suivre les états des pairs, vous devez contacter l'adresse suivante : ou
En réponse, le PBX nous renvoie une réponse 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>
Il y a beaucoup de déchets dans la réponse, donc lors du prétraitement, nous la filtrons par modèle XPath: //réponse/générique[@host]
Alors le plaisir commence. Pour travailler avec la détection et créer dynamiquement des éléments, la réponse doit être au format JSON. XML n'est pas pris en charge pour les détections automatiques.
Pour convertir XML en JSON, j'ai dû jouer un peu avec le remplacement automatique, pour lequel j'ai réalisé un script en JS
Un point intéressant : dans la réponse ATS, tous les paramètres sont entourés de guillemets simples, et après application du modèle //réponse/générique[@host] ils sont remplacés par des doubles.
Pour créer des éléments, nous utilisons des variables de la réponse XML (maintenant JSON).
Registre SIP
Pour les enregistrements SIP, nous utilisons trois variables : Nom d'utilisateur, hôte, port. J'étais content du nom de l'élément [email protected]: 5060, je n'ai trouvé aucune situation dans laquelle vous devez utiliser les cinq variables.
L'élément principal qui reçoit des informations sur toutes les inscriptions, Astérisque - AMI SIPshowregistry. Une fois par minute, il effectue une requête GET pour , après quoi les données XML de réponse sont transmises à tous les éléments dépendants pour analyse. Pour chaque inscription je crée un élément qui en dépend. Ceci est pratique car nous recevons des informations à jour dans une seule demande, et non pour chaque demande séparément. Cette implémentation présente un inconvénient important : la charge sur le processeur.
Lors du test jusqu'à 100 éléments dépendants, je n'ai pas remarqué la charge, mais avec 1700 15 éléments, cela a donné une charge notable de XNUMX secondes sur le processeur. Gardez cela à l’esprit si vous disposez d’un grand nombre d’éléments dépendants.
En guise d'option permettant de « répartir » la charge ou de définir différentes fréquences d'interrogation pour un élément, vous pouvez déplacer la logique de traitement vers chaque élément séparément.
Je ne stocke pas les informations reçues dans l'élément principal. Premièrement, je n'en vois pas la nécessité, et deuxièmement, si la réponse est supérieure à 64 Ko, alors Zabbix la coupe.
Puisque nous utilisons une réponse XML complète pour l'élément dépendant, nous devons obtenir la valeur de cet élément lors du prétraitement. À travers XPath c'est fait comme ça:
string(//response/generic[@event="RegistryEntry"][@username="{#SIP_REGISTRY_USERNAME}"][@host="{#SIP_REGISTRY_HOST}"][@port="{#SIP_REGISTRY_PORT}"]/@ État)
Pour les statuts d'inscription, je n'ai pas utilisé de statuts textuels, mais je les ai convertis sous forme numérique à l'aide de JavaScript :
switch(value) {
case 'Registered':
return 1;
case 'Unregistered':
return 0;
default:
return -1;
}
Homologues SIP
Par analogie avec les enregistrements SIP, il existe un élément principal d'Asterisk - AMI SIPshowregistry, auquel s'ajoutent les éléments dépendants.
Cela crée deux éléments dépendants :
- Statut des pairs sous forme de texte
- Temps de réponse de l'appareil - si l'état est OK, alors le temps de réponse de l'appareil est écrit, sinon « -1 »
Le chemin vers l'élément lui-même est un peu plus simple XPath:
chaîne(//response/generic[@objectname="{#SIP_PEER_OBEJECTNAME}"]/@status)
Pour le deuxième élément, j'ai utilisé JavaScript pour séparer temps de réponse du statut de pair, puisqu'ils sont stockés ensemble :
if(value.substring(0,2) == 'OK'){
return value.match(/(d+)/gm);
}
else {
return -1;
}Conclusion
Une solution prête à l’emploi peut être complexe et pas immédiatement claire. Augmente la flexibilité et la portabilité entre différents systèmes
Bonne et facile intégration à tous ! Modèle et instructions de configuration .
Source: habr.com