Eelnevas artiklis Ma rääkisin, kuidas saada autentimisseanss ja sisestada see hosti kohandatud makrosse. Selles artiklis räägin, kuidas siduda Zabbix Asteriskiga ilma välistest skriptidest ja tarkvarast.
Idee „siduda“ need kaks süsteemi tekkis ammu, ilma et oleks vaja installida täiendavat tarkvara ja skripte. Kiire Google'i otsing andis välja mitmeid lahendusi, kuid kõik viitasid sellele, et laadige serverisse skriptid (PHP-s, Bashis, Pythoni jne) ja kõik on korras. Mina soovisisin aga teostada jälgimist „karbist välja“ — ilma välistest skriptidest ja täiendava tarkvara installimiseta serverisse, kus on jälgimine ja PBX.
Käisin selle kallal kokku 4 tööpäeva, kuid tulemus vääris vaeva. Töö AMI liidese kaudu, madala taseme tuvastamine, käivitajad ning mis kõige tähtsam, PBX-i ühenduse ja kõigi teiste seadistuste tegemine kulub nüüd 15 minutit.
Kasutan Zabbix 4.4 ja umbes 100 Asterisk 13 versiooniga. Mõned PBX-id tulevad koos FreePBX veebiliidesega, teised on lihtsalt konsooliga, paljude nippidega ja integreerimisega läbi kõneplaani.
Saame andmeid PBX-ilt
Esimene ja peamine punkt, millega tegeleda, on teabe saamine peer'ide ja SIP registreerimise kohta. Selleks on PBX-is AGI, AMI, ARI ja SSH konsooli liidesed. Täiendavaid mooduleid ei ole arvesse võetud arusaadavatel põhjustel.
Alustamiseks tuleb mõista, mida need AGI, AMI, ARI … endast kujutavad.
- AGI — skriptide kasutamine dialplan'is. Peamiselt kasutatakse helistamiste juhtimiseks.
- AMI — suudab edastada kogu vajaliku teabe, töötab pordi 5038 kaudu sama moodi nagu Telnet. Meile sobib!
- ARI — kaasaegne, moes, JSON-iline. Palju võimalusi, andmeformaat arusaadavas vormis Zabbix jaoks, kuid mulle puudub peamine: SIP registreerimist ei saa jälgida. Veel üks miinus on see, et peer'ide jaoks on vaid kaks olekut: online/offline, kuigi olekuid on rohkem ja nende arvestamine on diagnostika jaoks kasulik.
- SSH — oskab kõike, aga vahel ei anta seda "turvakaalutluste" tõttu. Kaalutlused võivad olla erinevad, ei hakka neid lahkama.
Siiski, kõikide oma puuduste eest katab ARI 90% kõikidest monitorimise vajadustest.
Zabbix ja Telnet — minu pettumus.
AMI tunnen hästi, kunagi rakendasin kadude jälgimist vestlustes kaugkontorite vahel, kõnede haldamist jne. Telnet'i osas on samuti kõik selge: ava ühendus, saada käsud ja loe vastus. Nii ma ka tegin, kuid tulemus pettis mind.
Telnet Zabbixis ei ole sama, mis Linuxi konsoolis, see on veidi lihtsam ja suunatud tavalisele autoriseerimisele nagu kasutajanimi/parool. Kui autoriseerimise loogika on erinev ja kasutajanime/parooli paari küsitakse, ilmub viga. Pärast mitmeid ebaõnnestunud katseid autoriseerimise nõuet vältida, otsisin Telnet'i mooduli lähtekoodi.
Mõistsin, et kuni ei tule traditsioonilist kasutajanime ja parooli küsimist, ei edene ma edasi. Huvi pärast viskasin koodist välja kõik, mis autoriseerimisega seotud, ja ehitasin kõik ümber. Töötab! Kuid nõuetele ei vasta. Jätkame edasi …
Tagasi otsingusse
Lugesin ARI dokumentatsiooni veelkord, tegin täiendavaid teste — siin ei ole SIP registreerimisi. Peerid on, kõned on, sillad on, registreerimisi ei ole. Mingil hetkel mõtlesin isegi, kas meil on SIP registreerimised tõeliselt vajalikud?
Naljakal juhusel saabub just sel hetkel järgmine päring kasutajalt, kes kurdab väljaminevate kõnede probleeme. Probleem seisnes SIP registreerimise hangumises, mis lahendati tavalise mooduli taaskäivitamisega.
asterisk -rx "sip reload"Oleks tore webi kaudu pöörduda AMI poole: see lahendaks kõik probleemid, mõtlesin ma. Alustan selle suuna uurimist, ja esimene otsingu rida viib mind Asteriski ametlikku dokumentatsiooni, kus öeldakse, et minu vajadustele on olemas valik webenabled failis /etc/asterisk/manager.conf, mis tuleb seada väärtusele YES ja sektsiooni [general]
Pärast seda, tavapärase veebipäringu vormis saame kogu vajaliku teabe.
FreePBX liidese kasutamisel ei saa seda valikut veebist aktiveerida, see tuleb lubada konsooliga, muutes faili manager.conf. FreePBX ei kustuta seda muudatuste tegemisel veebis.
Olen töötanud mitmesuguste Asterisk'i integratsioonidega, kuid pole kunagi näinud, et see funktsioon kuskil mainitud oleks. Mind üllatas, et keegi ei kirjelda seda meetodit suhtlemiseks PBX-iga. Isegi kui otsisin teavet selle teema kohta, ei leidnud ma praktiliselt midagi või oli see kasutatud täiesti muude ülesannete jaoks.
Mis asi on WEB AMI?
Valiku lisamine webenabled faili manager.conf avatakse täieõiguslik juurdepääs PBX-i haldamiseks veebis. Kõik käsud, mis on kergesti saadavad tavalise AMI kaudu, on nüüd veebis saadaval, saab kuulata PBX-i sündmusi soketi kaudu. Tööprincip ei erine tavalisest AMI-st. Pärast selle valiku aktiveerimist saab PBX-ile pöörduda järgmiste aadresside kaudu:
— veebileht lihtsa liidesega, testimiseks ja käsitsi päringute saatmiseks. Kõik vastused vormindatakse loetavasse HTML-vormi. Jälgimiseks pole see väga sobiv.
— ainult tekstiväljund, formaat sarnaneb konsooli AMI-le
— ainult tekstiväljund, XML-vormingus. Meie jaoks sobib!
Siin mõtlesin: „Noh, see on lahendus! Nüüd on kõik valmis! Lihtne nagu maasikaäpp!”, aga rõõmustamiseks oli veel vara. Vajalikku teavet saame kätte, kui kasutame GET-päringut koos vajalike toimingutega. action, mis vastuseks tagastab xml-i, kus on kirjas kõik registreerimised ja nende olek. See on kõik tore, aga vajalik on autentimine, mis salvestab sessiooni cookie-s. Kui testid brauseris, ei mõtle sa sellele protsessile.
Autoriseerimisprotsess
Esialgu pöördume aadressile , millele server vastuseks saadab autentimisseansi küpsise. Selline näeb välja HTTP päring:
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: et-EE,et;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: 1Vastus:
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 Seal töötamiseks on vajalik mansession_id="6f5de42c", st autentimisküpsis ise.
Sisuleidmisel tuleb vaid kontrollida, kas vastus "Autentimine on vastu võetud". Edasi, kõikides suhtlustes ADSL serveriga peame lisama taotlusesse autentimiskuuki.
https://ats:8089/mxml?action=SIPpeers
Host: ats:8089
Connection: close
Cookie: mansession_id="6f5de42c"Kuidas saada autentimiskuuki ja kasutada seda teistes päringutes, loe siit: "»
Zabbixis jälgimisobjektide loomiseks kasutan automaatset avastamist.
Automaatne avastus
Registreerimise ja peeride oleku jälgimise automaatseks avastamiseks on vaja pöörduda järgmise aadressi poole: või
ATS tagastab meile XML-vastuse:
...
... Vastus sisaldab palju prügi, seetõttu filtreerime selle eeltöötluses mustri alusel. XPath: //response/generic[@host]
Edasi hakkab toimuma kõige huvitavam. Et töötada avastamisega ja dünaamiliselt luua elemente, peab vastus olema JSON-formaadis. XML ei toeta automaatset avastamist.
XML-i konverteerimiseks JSON-iks pidin natuke mängima automaatse asendamisega, mille jaoks tegin JS-i skripti.
Huvitav punkt, et ATS-i vastuses on kõik parameetrid ühekordsete jutumärkidega, aga pärast mustri rakendamist //response/generic[@host] need asendatakse kahekordsetega.
Elementide loomiseks kasutame XML-i vastusest (nüüd JSON-ist) muutujaid.
SIP Registry
SIP registreerimiste jaoks kasutame kolme muutuja: username, host, port. Mind rahuldas elemendi nimi 111111@login.mtt.ru:5060, olukordi, kus kõik viis muutujat oleks vaja kasutada, ma ei leidnud.
Peamine element, mis saab kogu registreerimise teabe, Asterisk — AMI SIPshowregistry. Kord minutis saadab ta GET-päringu. , mille pärast edastatakse XML vastuse andmed kõigile sõltuvatele elementidele analüüsimiseks. Iga registreeringu element teen sõltuvana. See on mugav, kuna me saame kehtivat teavet ühe päringu kaudu, mitte igaks eraldi. Selle teostuse suur puudus on aga koormus protsessorile.
Sõltuvate elementide testimisel kuni 100, ma ei märganud koormust, kuid 1700 elemendi puhul, see andis märgatava 15-sekundilise koormuse protsessorile. Pidage seda meeles, kui teil on suur hulk sõltuvaid elemente.
Koormuse 'mahalo' või erineva küsimise sageduse seadmiseks iga elemendi puhul, võib töötluslogika viia iga elemendi eraldi.
Saadud teavet ma põhielemendis ei hoia. Esiteks, ma ei näe selles vajadust, ja teiseks, kui vastus on suurem kui 64K, siis Zabbix lõikab selle ära.
Kuna sõltuva elemendi jaoks kasutame me täit XML vastust, peame eelprotsessis saama selle elemendi väärtuse. Läbi XPath see tehakse nii:
string(//response/generic[@event="RegistryEntry"][@username="{#SIP_REGISTRY_USERNAME}"][@host="{#SIP_REGISTRY_HOST}"][@port="{#SIP_REGISTRY_PORT}"]/@state)
Kuna registratsioonide staatustele ei kasutanud ma tekstilisi staatuseid, vaid tõlisin need numbrivormingusse JavaScripti abil:
switch(value) {
case 'Registered':
return 1;
case 'Unregistered':
return 0;
default:
return -1;
}
SIP teised
Sama nagu SIP registreerimiste puhul, on peamine element Asterisk — AMI SIPshowregistry, millele lisanduvad sõltuvad.
Siin luuakse kaks sõltuvat elementi:
- Pira staatus tekstivormingus
- Seadme vastusaeg — kui staatus on OK, siis märgitakse seadme vastusaeg, muidu "-1"
Elementi tee on juba veidi lihtsam XPath:
string(//response/generic[@objectname="{#SIP_PEER_OBEJECTNAME}"]/@status)
Teise elemendi puhul kasutasin JavaScripti, et eraldada vastusaeg pira staatusest, kuna need salvestatakse koos:
if(value.substring(0,2) == 'OK'){
return value.match(/(d+)/gm);
}
else {
return -1;
}Kokkuvõte
Lahendus „karbist välja“ võib olla keeruline ja mitte kohe arusaadav. Suurendab paindlikkust ja ühilduvust erinevate süsteemide vahel.
Kasutage meeldivat ja sujuvat integreerimist! Mall ja seadistamise juhend on .
Allikas: habr.com
