Nell'articolo precedente Ho spiegato come ottenere una sessione di autorizzazione e inserirla in un macro locale dell'host. In questo articolo parlerò di come integrare Zabbix con Asterisk senza script esterni e software.
L'idea di «integrare» questi due sistemi è emersa tempo fa, senza l'installazione di software o script aggiuntivi. Una ricerca veloce su Google ha restituito molte soluzioni, tutte basate sull'idea di caricare script (in PHP, Bash, Python, ecc.) sul server e sarete felici. A me invece interessava realizzare un monitoraggio «out of the box» – senza script esterni e installazione di software aggiuntivo sul server di monitoraggio e sull'UTC.
Ho dedicato a questo 4 giorni lavorativi, ma il risultato ne è valsa la pena. Lavoro attraverso l'interfaccia AMI, rilevamento a basso livello, trigger e, cosa più importante, ora per collegare l'UTC e tutte le altre impostazioni ci vogliono circa 15 minuti.
Ho Zabbix 4.4, circa 100 Asterisk di versione 13. Alcuni UTC hanno un'interfaccia web FreePBX, alcuni hanno una console nuda, con molte astuzie e integrazioni tramite il piano di chiamata.
Otteniamo dati dall'UTC
Il primo e principale punto da affrontare è l'ottenimento dei dati sulle registrazioni SIP e sui peer. A tal fine, nelle ASU sono disponibili le interfacce AGI, AMI, ARI e la console SSH. Non ho considerato moduli aggiuntivi per motivi evidenti.
Per iniziare, è necessario capire cosa rappresentano questi AGI, AMI, ARI...
- AGI — utilizzo di script nel dialplan. È principalmente usato per gestire le chiamate.
- AMI — può restituire tutte le informazioni necessarie, funziona attraverso la porta 5038 in modo simile a Telnet. Fa al caso nostro!
- ARI — moderno, alla moda, in formato JSON. Tante possibilità, formato dei dati in un aspetto comprensibile per Zabbix, ma per me manca la cosa principale: non è possibile controllare la registrazione SIP. Un altro svantaggio è che per i peer esistono solo due stati online/offline, sebbene ci siano più stati e sarebbe utile tenerli in considerazione per la diagnostica.
- SSH — può fare tutto, ma a volte non viene fornito per "motivi di sicurezza". I motivi possono essere vari, non li analizzerò.
Tuttavia, nonostante tutti i suoi difetti, ARI copre il 90% di tutte le esigenze di monitoraggio.
Zabbix e Telnet — la mia delusione.
Conosco bene AMI, in passato ho implementato il monitoraggio delle perdite nelle conversazioni suddividendo tra uffici remoti, gestione delle chiamate, ecc. Anche Telnet è molto chiaro: apri la connessione, invia comandi e leggi le risposte. E così ho fatto, ma il risultato mi ha deluso.
Telnet in Zabbix non è come nella console Linux, è un po' più semplice e ottimizzato per l'autenticazione standard tipo login/password. Se la logica di autenticazione è diversa e non c'è richiesta per una coppia login/password, esce un errore. Dopo tentativi infruttuosi di bypassare il requisito di autenticazione, è stato utile guardare il codice sorgente del modulo Telnet.
Ho capito che finché non ci sarà una richiesta tradizionale di login con password, non farò progressi. Per curiosità, ho rimosso dal codice tutto ciò che riguardava l'autenticazione e ho ricompilato tutto. Funziona! Ma non soddisfa i requisiti. Andiamo oltre...
Torniamo alla ricerca
Ho riletto di nuovo la documentazione su ARI e condotto test aggiuntivi: qui non ci sono registrazioni SIP. Ci sono peer, ci sono conversazioni, ci sono bridge, ma nessuna registrazione. A un certo punto ho persino pensato, sono davvero necessarie le registrazioni SIP?
Per uno strano scherzo del destino, in quel momento arriva una nuova richiesta da un utente riguardo a un problema con le chiamate in uscita. Il problema era dovuto a un blocco nella registrazione SIP e si risolveva con una semplice riavvio del modulo.
asterisk -rx "sip reload"Sarebbe fantastico poter accedere all'AMI tramite web: questo risolverebbe tutti i problemi, ho pensato. Inizio a cercare in questa direzione e la prima riga di ricerca porta alla documentazione ufficiale di Asterisk, dove si dice che per le mie esigenze c'è un'opzione webenabled nel file /etc/asterisk/manager.conf, che deve essere impostata su YES, nella sezione [general]
Dopo di che, tramite una normale richiesta web del tipo otteniamo tutte le informazioni necessarie.
Utilizzando l'interfaccia FreePBX, non è possibile abilitare questa opzione tramite web; deve essere abilitata tramite console, modificando il file manager.conf. FreePBX non la elimina quando si apportano modifiche alle configurazioni tramite web.
Da quando lavoro con diversi tipi di integrazioni Asterisk, non ho mai visto menzionata questa funzione. Sono rimasto sorpreso che nessuno descriva questo metodo di interazione con il centralino. Ho persino cercato informazioni sull'argomento: praticamente non c'è nulla, o è stato utilizzato per scopi completamente diversi.
WEB AMI — di cosa si tratta?
Aggiunta dell'opzione webenabled nel file manager.conf ha aperto un accesso completo al controllo del centralino via web. Tutti i comandi disponibili tramite il normale AMI sono ora presenti nel web, è possibile ascoltare eventi dal centralino tramite socket. Il principio di funzionamento non si differenzia da quello dell'AMI da console. Dopo aver attivato questa opzione, è possibile accedere al centralino ai seguenti indirizzi:
— pagina web con un'interfaccia semplice, per test e invio manuale di richieste. Tutte le risposte sono formattate in un formato HTML leggibile. Non è molto adatta per il monitoraggio.
— solo output testuale, il formato è simile a quello dell'AMI da console.
— solo output testuale, in formato XML. Questo ci va bene!
Qui avevo pensato: «Ecco la soluzione! Ora è tutto pronto! Facile facile», ma era presto per rallegrarsi. Per ottenere le informazioni che ci servono, è sufficiente utilizzare una richiesta GET con l'azione necessaria action, che restituisce in risposta un xml con l'elenco di tutte le registrazioni e il loro stato. È tutto bello, ma è necessaria l'autenticazione con memorizzazione della sessione dai cookie. Quando testi nel browser, non pensi a questo processo.
Il processo di autenticazione
Iniziamo a contattare l'indirizzo , in risposta il server ci invia un cookie con la sessione di autorizzazione. Ecco come appare la richiesta 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: 1Risposta:
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 Per lavorare lì è necessario mansession_id="6f5de42c", cioè il cookie di autorizzazione stesso.
Il contenuto deve solo essere controllato per la presenza della risposta «Autenticazione accettata». Inoltre, per ogni richiesta al server ATS, dovremo aggiungere nel messaggio il cookie di autorizzazione.
https://ats:8089/mxml?action=SIPpeers
Host: ats:8089
Connection: close
Cookie: mansession_id="6f5de42c"Per come ottenere il cookie di autorizzazione e usarlo in altre richieste leggi qui: «»
Per creare elementi di monitoraggio in Zabbix userò la scoperta automatica.
Scoperta automatica
Per la scoperta automatica delle registrazioni e il monitoraggio dello stato dei peer, è necessario fare riferimento all'indirizzo: o
In risposta, l'ATS ci restituisce una risposta XML:
...
... La risposta contiene molti dati inutili, quindi nel preprocessing li filtriamo secondo un modello. XPath: //response/generic[@host]
Qui inizia la parte interessante. Per lavorare con il rilevamento e creare dinamicamente gli elementi, è necessario che la risposta sia in formato JSON. XML non è supportato per le auto scoperte.
Per convertire XML in JSON ho dovuto fare qualche modifica con la sostituzione automatica, per la quale ho creato uno script in JS.
Un aspetto interessante: nella risposta della centrale telefonica tutti i parametri sono racchiusi tra apici singoli, e dopo l'applicazione del modello //response/generic[@host] vengono sostituiti con doppi.
Per creare elementi, utilizziamo le variabili dalla risposta XML (ora JSON).
Registro SIP
Per le registrazioni SIP, utilizziamo tre variabili: username, host, port. Mi piaceva il nome dell'elemento. 111111@login.mtt.ru:5060, non ho trovato situazioni in cui fosse necessario utilizzare tutte e cinque le variabili.
L'elemento principale che riceve informazioni su tutte le registrazioni, Asterisk — AMI SIPshowregistry. Una volta al minuto, effettua una richiesta GET a , dopo di che i dati della risposta XML vengono trasferiti a tutti gli elementi dipendenti per l'analisi. Creo un elemento per ogni registrazione, rendendolo dipendente da esso. Questo è comodo, poiché otteniamo informazioni aggiornate con una sola richiesta, invece di per ciascuno separatamente. Questa implementazione presenta un notevole svantaggio: il carico sulla CPU.
Durante i test fino a 100 elementi dipendenti, non ho notato il carico, ma con 1700 elementi, questo comportava un carico visibile di 15 secondi sulla CPU. Tenetelo a mente se avete un gran numero di elementi dipendenti.
Come opzione per 'distribuire' il carico o impostare diverse frequenze di polling per l'elemento, si può spostare la logica di elaborazione in ogni elemento separatamente.
Non memorizzo le informazioni ottenute nell'elemento principale. Innanzitutto, non vedo la necessità, e in secondo luogo, se la risposta supera i 64K, Zabbix la taglia.
Poiché per l'elemento dipendente utilizziamo la risposta XML completa, dobbiamo ottenere il valore di questo elemento nella preprocessazione. Attraverso XPath si fa così:
string(//response/generic[@event="RegistryEntry"][@username="{#SIP_REGISTRY_USERNAME}"][@host="{#SIP_REGISTRY_HOST}"][@port="{#SIP_REGISTRY_PORT}"]/@state)
Per gli stati delle registrazioni non ho usato gli stati testuali, ma li ho convertiti in forma numerica tramite JavaScript:
switch(value) {
case 'Registered':
return 1;
case 'Unregistered':
return 0;
default:
return -1;
}
SIP Peers
Analogamente alle registrazioni SIP, c'è l'elemento principale Asterisk — AMI SIPshowregistry, a cui vengono aggiunti gli elementi dipendenti.
Qui vengono creati due elementi dipendenti:
- Stato del peer in forma testuale
- Tempo di risposta del dispositivo — se lo stato è OK, viene registrato il tempo di risposta del dispositivo, altrimenti '-1'
Il percorso fino all'elemento è già un po' più semplice XPath:
string(//response/generic[@objectname="{#SIP_PEER_OBEJECTNAME}"]/@status)
Per il secondo elemento ho usato JavaScript per separare il tempo di risposta dallo stato del peer, poiché sono memorizzati insieme:
if(value.substring(0,2) == 'OK'){
return value.match(/(d+)/gm);
}
else {
return -1;
}Conclusione
La soluzione «chiavi in mano» può risultare complessa e poco intuitiva. Aumenta la flessibilità e la portabilità tra diversi sistemi.
Auguro a tutti una facile e piacevole integrazione! Modello e istruzioni per la configurazione su .
Fonte: habr.com
