Egy korábbi cikkben Elmondtam, hogyan fogadhat engedélyezési munkamenetet, és hogyan helyettesítheti azt helyi gazdagépmakróval. Ebben a cikkben elmondom, hogyan lehet csatlakoztatni a Zabbix-ot az Asteriskhez külső szkriptek és szoftverek nélkül.
Az ötlet, hogy „barátkozzunk” ezzel a két rendszerrel, már régen megszületett, további szoftverek vagy szkriptek telepítése nélkül. Egy gyors guglizás sok lehetséges megoldást hozott, minden abban dőlt el, hogy töltsd fel a szkripteket (Pyha, Bash, Python stb.) a szerverre, és boldog leszel. A „dobozból” való megfigyelést szerettem volna megvalósítani - külső szkriptek és további szoftverek telepítése nélkül a szerverre felügyelettel és alközponttal.
Összesen 4 munkanapot töltöttem ezzel, de az eredmény megérte. Az AMI interfész, az alacsony szintű észlelés, a triggerek, és ami a legfontosabb, az alközpont és az összes többi beállítás csatlakoztatása most körülbelül 15 percet vesz igénybe.
A Zabbix 4.4 elérhető, körülbelül 100 darab Asterisk 13-as verzió. Egyes alközpontok FreePBX webes felülettel, mások csupasz konzollal, egy csomó trükkel és tárcsázós integrációval rendelkeznek.
Adatok fogadása az alközpontról
Az első és legfontosabb megoldandó pont az egyenrangú és SIP-regisztrációkra vonatkozó adatok beszerzése. Erre a célra az alközpont rendelkezik AGI, AMI, ARI és SSH konzol interfészekkel. Nyilvánvaló okokból nem vettem számításba további modulokat.
Először is rá kell jönnünk, hogy mik ezek az agi, ami, ari...
- AGI - szkriptek használata a tárcsázási tervben. Főleg híváskezelésre használják.
- AMI - minden szükséges információt megadhat, az 5038-as porton keresztül működik, hasonlóan a Telnethez. Nekünk megfelel!
- ARI - modern, divatos, JSON. Sok lehetőség van, az adatformátum a Zabbix számára érthető, de számomra nem a lényeg: nem tudod ellenőrizni a korty regisztrációt. További hátránya, hogy a társak számára csak két online/offline állapot létezik, bár több állapot van, és ezeket célszerű figyelembe venni a diagnózis során.
- Az SSH mindent meg tud csinálni, de néha „biztonsági okokból” nem megengedett. A megfontolások eltérőek lehetnek, nem megyek bele.
Az ARI azonban minden hiányosságával együtt az összes monitorozási igény 90%-át fedezi.
Zabbix és Telnet – csalódásom
Jól ismerem az AMI-t, valamikor a veszteségek nyomon követését valósítottam meg a távoli irodákkal folytatott megosztással, híváskezeléssel stb. A Telnet esetében is minden nagyon világos: nyissa meg a kapcsolatot, küldje el a parancsokat és olvassa el a választ. Így tettem, de az eredmény csalódást okozott.
A Zabbix Telnet nem ugyanaz, mint a Linux konzolban, kicsit egyszerűbb, és szabványos jogosultságokhoz, például bejelentkezési/jelszóhoz szabott. Ha az engedélyezési logika eltérő, és nincs kérés bejelentkezés/jelszó párra, hiba történik. Az engedélyezési követelmény megkerülésére tett hiábavaló próbálkozások után hasznos volt megnézni a Telnet modul forráskódját.
Rájöttem, hogy amíg nincs hagyományos bejelentkezés és jelszó kérés, addig nem lépek tovább. A móka kedvéért mindent kivettem a kódból, ami az engedélyezéssel kapcsolatos, és mindent újra összeraktam. Művek! De nem felel meg a követelményeknek. Menj tovább…
Térjünk vissza a kereséshez
Újra elolvastam az ARI dokumentációját, lefuttattam további teszteket - itt nincs korty regisztráció. Vannak lakomák, vannak beszélgetések, van bricsesz, de nincs regisztráció. Valamikor még arra is gondoltam, hogy valóban szükségünk van keselyű regisztrációra?
Vicces egybeesés folytán ebben a pillanatban újabb kérés érkezik a felhasználótól, probléma a kimenő hívásokkal. A probléma az volt, hogy a sip regisztráció lefagyott, és a modul egyszerű újraindításával megoldódott.
asterisk -rx "sip reload"Jó lenne elérni az AMI-t a weben keresztül: az minden problémát megoldana, gondoltam. Elkezdek ásni ebbe az irányba, és szó szerint az első keresősor a hivatalos Asterisk dokumentációhoz vezet, amely azt mondja, hogy van lehetőség a feladataimra weben engedélyezve fájlban /etc/asterisk/manager.confszakaszban, amelyet IGEN-re kell állítani [Tábornok]
Ezt követően az űrlap szokásos webes lekérésével minden szükséges információt megkapunk.
A FreePBX interfész használatakor ezt az opciót nem engedélyezheti a weben keresztül, ezt a konzolon keresztül kell engedélyezni a manager.conf fájl módosításával. A FreePBX nem törli azt, ha a konfigurációt az interneten keresztül módosítja.
Sokáig dolgoztam különféle Asterisk integrációkkal, de ezt a funkciót még soha nem láttam sehol említve. Meglepett, hogy senki nem írja le az alközponttal való interakciónak ezt a módját. Még kifejezetten hasznos volt tájékozódni ebben a témában: gyakorlatilag semmi, vagy teljesen más feladatokra használták.
WEB AMI - milyen vadállat?
Opció hozzáadása weben engedélyezve fájlhoz manager.conf teljes hozzáférést biztosított az ATS kezeléséhez a weben keresztül. A normál AMI-n keresztül elérhető összes parancs már elérhető a weben, az alközpontról egy aljzaton keresztül hallgathatja az eseményeket. A működési elve nem különbözik a konzolos AMI-től. Az opció aktiválása után a következő címeken léphet kapcsolatba az alközponttal:
— egyszerű felülettel rendelkező weboldal a kérések teszteléséhez és kézi küldéséhez. Minden válasz olvasható HTML-be van formázva. Nem túl alkalmas megfigyelésre.
— csak szövegkimenet, a konzolos AMI-hez hasonló formátum
- csak szöveges kimenet, XML formátumban. Nekünk megfelel!
Aztán arra gondoltam: „Ez a megoldás! Most minden készen lesz! Easy-peezy citrom squeezey”, de még korai volt örülni. A szükséges információk megszerzéséhez elegendő egy GET kérést használni a szükséges művelettel akció, amely válaszul az xml fájlt adja vissza az összes regisztráció listájával és azok állapotával. Ez mind nagyszerű, de engedélyre van szüksége ahhoz, hogy megjegyezze a munkamenetet a cookie-ból. Amikor a böngészőben tesztel, nem gondol erre a folyamatra.
Engedélyezési folyamat
Először a címmel foglalkozunk , válaszul a szerver cookie-t küld nekünk az engedélyezési munkamenettel együtt. Így néz ki egy HTTP-kérés:
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: 1Válasz:
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>
Ott dolgozni kell házazonosító="6f5de42c", azaz maga az engedélyezési cookie.
Tartalom, amire csak ellenőrizned kell a választ"A hitelesítés elfogadva" Ezután az alközponti kiszolgálóhoz intézett összes híváshoz egy engedélyezési cookie-t kell hozzáadnunk a kéréshez.
https://ats:8089/mxml?action=SIPpeers
Host: ats:8089
Connection: close
Cookie: mansession_id="6f5de42c"Olvassa el, hogyan szerezhet be engedélyezési cookie-t, és hogyan használhatja más kérésekhez: "»
A nyomkövető elemek létrehozásához a Zabbixban az automatikus felismerést fogom használni.
Automatikus felismerés
A regisztrációk automatikus észleléséhez és a társállapotok követéséhez vegye fel a kapcsolatot a következő címen: vagy
Válaszul az alközpont egy XML választ ad vissza:
<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>
Sok a szemét a válaszban, ezért az előfeldolgozásnál sablon szerint szűrjük XPath: //response/generic[@host]
Aztán kezdődik a móka. Az észleléssel való munkavégzéshez és az elemek dinamikus létrehozásához a válasznak JSON formátumban kell lennie. Az XML nem támogatott az automatikus észleléshez.
Az XML JSON-ba konvertálásához egy kicsit játszanom kellett az automatikus cserével, amihez készítettem egy szkriptet JS-ben
Érdekes pont: az ATS válaszban az összes paramétert egyetlen idézőjel veszi körül, és a sablon alkalmazása után //response/generic[@host] kettősre cserélik őket.
Az elemek létrehozásához az XML-válaszból (jelenleg JSON) származó változókat használunk.
SIP Registry
A korty regisztrációhoz három változót használunk: felhasználónév, vendéglátó, kikötő. Örültem az elem nevének [e-mail védett]: 5060, Nem találtam olyan helyzetet, amikor mind az öt változót használni kellene.
A fő elem, amely minden regisztrációról információt kap, Csillag – AMI SIPshowregistry. Percenként egyszer GET kérést küld a címre , amely után a válasz XML-adatai az összes függő elemhez kerülnek elemzésre. Minden regisztrációhoz létrehozok egy attól függő elemet. Ez azért kényelmes, mert egy kérésben kapjuk meg a naprakész információkat, és nem minden kérésről külön-külön. Ennek a megvalósításnak van egy jelentős hátránya - a processzor terhelése.
100 függő elem tesztelésekor nem vettem észre a terhelést, de 1700 elemnél ez érezhető 15 másodperces terhelést adott a processzornak. Tartsa ezt szem előtt, ha nagyszámú függő eleme van.
A terhelés „kiterítésére” vagy egy elemhez különböző lekérdezési frekvenciák beállítására szolgáló lehetőségként a feldolgozási logikát minden elemre külön-külön áthelyezheti.
A kapott információkat nem tárolom a fő elemben. Először is, nem látom ennek szükségét, másodszor, ha a válasz több mint 64K, akkor a Zabbix levágja.
Mivel teljes XML választ használunk a függő elemhez, ezért az előfeldolgozás során ennek az elemnek az értékét kell megkapnunk. Keresztül XPath így történik:
string(//response/generic[@event="RegistryEntry"][@username="{#SIP_REGISTRY_USERNAME}"][@host="{#SIP_REGISTRY_HOST}"][@port="{#SIP_REGISTRY_PORT}"]/@ állapot)
A regisztrációs állapotokhoz nem használtam szöveges állapotokat, hanem JavaScript segítségével numerikus formába konvertáltam:
switch(value) {
case 'Registered':
return 1;
case 'Unregistered':
return 0;
default:
return -1;
}
SIP Peers
A SIP-regisztrációkkal analóg módon van az Asterisk - AMI SIPshowregistry fő eleme, amelyhez a függő bejegyzések is hozzáadódnak.
Ez két függő elemet hoz létre:
- Peer státusz szöveges formában
- Eszköz válaszidő - ha az állapot rendben van, akkor az eszköz válaszideje kerül kiírásra, ellenkező esetben „-1”
Magához az elemhez vezető út egy kicsit egyszerűbb XPath:
string(//response/generic[@objectname="{#SIP_PEER_OBEJECTNAME}"]/@status)
A második elemhez JavaScriptet használtam a szétválasztáshoz válaszidő a társállapotból, mivel együtt vannak tárolva:
if(value.substring(0,2) == 'OK'){
return value.match(/(d+)/gm);
}
else {
return -1;
}Következtetés
Egy kész megoldás lehet összetett és nem azonnal egyértelmű. Növeli a rugalmasságot és a hordozhatóságot a különböző rendszerek között
Boldog és könnyű integrációt mindenkinek! Sablon és utasítások a beállításhoz .
Forrás: will.com