Az előző cikkben Beszéltem arról, hogyan lehet megszerezni az autentikációs munkamenetet, és hogyan lehet beilleszteni azt a helyi gazda makrójába. Ebben a cikkben arról fogok beszélni, hogyan lehet összekapcsolni a Zabbixot az Asteriskkel külső szkriptek és szoftverek nélkül.
Az az ötlet, hogy összekapcsoljam ezeket a két rendszert, régóta megvolt, méghozzá anélkül, hogy bármi extra szoftvert vagy szkriptet telepítenék. Gyors keresgélés számos megoldási variációt adott, amelyek mind abban merültek ki, hogy szkripteket (PHP, Bash, Python stb.) kell a szerverre helyezni, és minden rendben lesz. Viszont én azt akartam megvalósítani, hogy a monitorozás "do it yourself" — külső szkriptek és extra szoftverek nélkül a monitorozó és az Asterisk szerverre.
Négy munkanapon keresztül foglalkoztam vele, de megérte az eredmény. Az AMI interfészen keresztüli munka, alacsony szintű észlelés, riasztások, és ami a legfontosabb, az Asterisk csatlakoztatása és minden további beállítás most már mindössze 15 percet vesz igénybe.
A Zabbix 4.4-es verziója áll rendelkezésre, körülbelül 100 darab 13-as verziójú Asterisk. Néhány Asterisk webes felülettel érkezik, mint a FreePBX, míg mások üres konzollal rendelkeznek, sok trükkel és integrációval a dialplan keresztül.
Adatok beszerzése az Asteriskből
Az első és legfontosabb dolog, amit meg kell oldani — az adatok beszerzése a peerekről és a SIP regisztrációkról. Ehhez az Asteriskben AGI, AMI, ARI és SSH konzol interfészek léteznek. További modulokat a világos okok miatt nem vittem figyelembe.
Először is meg kell érteni, hogy mit jelentenek ezek az AGI, AMI, ARI...
- AGI — szkriptek használata a dialplanban. Főként a hívások kezelésére használják.
- AMI — minden szükséges információt meg tud adni, a 5038-as porton működik a Telnet segítségével. Ez nekünk megfelelő!
- ARI — modern, divatos, JSON-szerű. Sok lehetőséget kínál, az adatformátum érthető a Zabbix számára, de számomra hiányzik a legfontosabb: a SIP regisztráció nem ellenőrizhető. Egy másik hátrány, hogy a peereknek csak két állapotuk van, online/offline, pedig több állapot létezik, és ezeket hasznos figyelembe venni a diagnózis során.
- SSH — mindent tud, de néha nem adják meg biztonsági okokból. A megfontolások különbözőek lehetnek, de erről most nem beszélek.
Mindazonáltal, a hátrányai ellenére az ARI a monitorozás 90%-át lefedi.
Zabbix és Telnet — a csalódásom
Az AMI-t jól ismerem, régen megvalósítottam a hívások követését a távoli irodák párhuzamos kezelése mellett, a hívások irányítását stb. A Telnet is teljesen világos: csatlakozás létrehozása, parancsok küldése és a válasz olvasása. Ezt megtettem, de az eredmény csalódást okozott.
A Zabbix Telnet nem olyan, mint a Linux konzolban, egy kicsit egyszerűbb és a standard hitelesítésekre van optimalizálva, mint például a felhasználónév/jelszó. Ha a hitelesítési logika más, és nincs felhasználónév/jelszó páros kérése, hiba lép fel. Miután hiábavaló próbálkozások sorozatával próbáltam megkerülni a hitelesítési követelményt, megnéztem a Telnet modul forráskódját.
Megértettem, hogy amíg nem lesz hagyományos felhasználónév és jelszó kérése, nem jutok tovább. Érdekességből eltávolítottam a kódból minden hitelesítéssel kapcsolatos részt és újra összeállítottam mindent. Működik! De a követelményeknek nem felel meg. Tovább lépünk...
Visszatérünk a kereséshez
Még egyszer átnéztem az ARI dokumentációt, végrehajtottam további teszteket — itt nincsenek SIP regisztrációk. Vannak peer-ek, vannak beszélgetések, vannak bridzsek, de regisztrációk nincsenek. Egy pillanatban elgondolkodtam, hogy tényleg szükség van-e a SIP regisztrációkra?
Vicces véletlen folytán ebben a pillanatban érkezik egy újabb kérés a felhasználótól, a kimenő hívások problémájával kapcsolatban. A probléma a SIP regisztráció felfüggesztésében volt, és a modul egyszerű újraindításával megoldható volt.
asterisk -rx "sip reload"Nagyszerű lenne, ha weben keresztül lehetne hozzáférni az AMI-hoz: ez minden problémát megoldana, gondoltam. Elkezdtem felfedezni ezt az irányt, és szinte az első keresési sor a hivatalos Asterisk dokumentációhoz vezetett, amelyben van egy opció a feladataimhoz. webenabled a fájlban /etc/asterisk/manager.conf, amelyet YES-ra kell állítani a [general]
szakaszban. Egy egyszerű webes kérés formájában kapjuk meg az összes szükséges információt.
A FreePBX felület használatakor a weben nem lehet ezt az opciót engedélyezni, ezt a konzolon kell bekapcsolni a manager.conf fájl módosításával. A FreePBX nem törli ezt a webes konfigurációs módosítások során.
Amennyi időt a különböző Asterisk integrációkkal töltöttem, soha nem láttam, hogy valahol említést nyerne ez a funkció. Meglepett, hogy senki nem ír erről a módszerről, hogy hogyan lehet kommunikálni az ATE-kkel. Még szándékosan is kerestem információkat a témában: gyakorlatilag semmi nincs, vagy teljesen más feladatokhoz használták.
WEB AMI — mi ez a dolog?
Az opció hozzáadása webenabled a fájlba manager.conf teljes körű hozzáférést biztosít az Asterisk kezeléséhez a weben. Az összes parancs, amely elérhető a szokásos AMI-n, most már a weben is elérhető, és lehetőség van az Asterisk eseményeinek figyelésére socket-en keresztül. A működési elv nem tér el a konzolos AMI-tól. E funkció aktiválása után az Asterisk-hez a következő címeken lehet hozzáférni:
— weboldal egy egyszerű felülettel, tesztelésre és manuális kérések küldésére. Minden válasz olvasható HTML formátumban van. Monitorozásra nem igazán alkalmas.
— csak szöveges kimenet, a formátum hasonló a konzolos AMI-hoz
— csak szöveges kimenet, XML formátumban. Ez tökéletes!
Itt azt gondoltam: „Ez az – megoldás! Most minden készen lesz! Egyszerű mint a faék”, de korai volt az öröm. A szükséges információk megszerzéséhez elegendő a megfelelő cselekvéssel rendelkező GET kérés használata. action, amely válaszul egy XML-t ad, ami az összes regisztrációt és azok állapotát tartalmazza. Ez rendben van, de szükséges a bejelentkezés szessziót megőrző cookie-val. Amikor a böngészőben tesztelsz, nem gondolsz erre a folyamatra.
Hitelesítési folyamat
Először a címre lépünk , a válaszként a szerver küld egy cookie-t a bejelentkezéshez. Itt van, hogyan néz ki a 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 A működéshez szükség van mansession_id="6f5de42c", vagyis magára a bejelentkezési cookie-ra.
A tartalmat csak annyira kell ellenőrizni, hogy a „Authentication accepted” válasz megérkezett. Ezután az Asterisk szerverhez tett minden kérés során hozzá kell adni a kéréshez a bejelentkezési cookie-t.
https://ats:8089/mxml?action=SIPpeers
Host: ats:8089
Connection: close
Cookie: mansession_id="6f5de42c"A bejelentkezési cookie megszerzéséről és más kérésekben való használatáról itt olvashatsz: „»
Az elemek automatikus nyomkövetésének létrehozásához az Asterisk-ben automatikus felfedezést fogok használni.
Automatikus felfedezés
Az automatikus felfedezéshez a regisztrációk és a párok állapotának nyomon követéséhez a következő címhez kell fordulni: vagy
Az Asterisk válaszként XML választ küld vissza:
...
... A válaszban sok fölösleges információ van, ezért a feldolgozás során szűrjük ezt mintával. XPath: //response/generic[@host]
Ezután kezdődik a legérdekesebb rész. Ahhoz, hogy a felfedezés működjön és dinamikusan elemeket hozzunk létre, a válasznak JSON formátumban kell lennie. Az XML automatikus felfedezések során nem támogatott.
Az XML JSON-ra történő átkonvertálásához kicsit játszanom kellett az automatikus cserével, ezért készítettem egy JS szkriptet.
Érdekes tény, hogy az ATC válaszában minden paramétert egyes idézőjelek ölelnek körül, majd a minta alkalmazása után //response/generic[@host] ezek dupla idézőjelekre cserélődnek.
Elemek létrehozásához használjuk az XML válaszból (most JSON) származó változókat.
SIP Regiszter
SIP regisztrációkhoz három változót használunk: username, host, port. Az elem neve számomra elfogadható volt. 111111@login.mtt.ru:5060, olyan helyzeteket nem találtam, ahol mind az öt változót használni kellene.
A fő elem, amely információt kap az összes regisztrációról, Asterisk — AMI SIPshowregistry. Minden percben GET kérést intéz a , ezt követően az XML válasz adatai minden függő elemhez eljutnak elemzésre. Minden regisztrációhoz egy-egy függő elemet hozok létre. Ez kényelmes, mivel aktuális információt kapunk egy kérés révén, nem pedig mindegyikért külön. Ennek a megoldásnak van egy jelentős hátránya — a processzorra nehezedő terhelés.
100 függő elem tesztelése során a terhelést nem észleltem, de 1700 elemnél ez jelentős, 15 másodperces terhelést okozott a processzoron. Ezt tartsd szem előtt, ha sok függő elem van.
Alternatív megoldásként a terhelés "elkenésére" vagy az elemek kérdezésének különböző frekvenciájának beállítására a feldolgozási logikát minden elemhez külön lehet kiemelni.
A megszerzett információt nem tárolom a fő elemben. Először is, nem látom ennek szükségességét, másodszor pedig, ha a válasz nagyobb mint 64K, akkor a Zabbix levágja.
Mivel a függő elemhez teljes XML választ használunk, előfeldolgozás során meg kell szereznünk ennek az elemnek az értékét. Ennek révén XPath ezt így lehet megtenni:
string(//response/generic[@event='RegistryEntry'][@username="{#SIP_REGISTRY_USERNAME}"][@host="{#SIP_REGISTRY_HOST}"][@port="{#SIP_REGISTRY_PORT}"]/@state)
A regisztrációk állapotához nem használtam szöveges státuszokat, hanem JavaScript segítségével numerikus formára alakítottam őket:
switch(value) {
case 'Registered':
return 1;
case 'Unregistered':
return 0;
default:
return -1;
}
SIP Peers
A SIP regisztrációkhoz hasonlóan az Asterisk fő elemét, az AMI SIPshowregistry-t is használom, amelyhez függő elemeket adunk hozzá.
Itt két függő elem jön létre:
- A peer státusza szöveges formában
- Az eszköz válaszideje — ha az állapot OK, akkor az eszköz válaszideje kerül megadásra, különben „-1”
Az elemhez vezető út már kicsit egyszerűbb XPath:
string(//response/generic[@objectname="{#SIP_PEER_OBJECTNAME}"]./@status)
A második elemhez JavaScriptet használtam, hogy elválasszam a válaszidőt a peer státuszától, mivel ezek együtt vannak tárolva:
if(value.substring(0,2) == 'OK'){
return value.match(/(d+)/gm);
}
else {
return -1;
}Zárás
A dobozból kiinduló megoldás bonyolult lehet és nem mindig érthető. Növekszik a rugalmasság és a hordozhatóság különböző rendszerek között.
Mindenkinek kellemes és zökkenőmentes integrációt kívánok! A beállítási sablon és útmutató a következőhöz: .
Forrás: habr.com
