V předchozím článku Řekl jsem vám, jak přijmout autorizační relaci a nahradit ji makrem místního hostitele. V tomto článku vám řeknu, jak propojit Zabbix s Asterisk bez externích skriptů a softwaru.
Myšlenka „spřátelit“ tyto dva systémy se zrodila již dávno, bez instalace dalšího softwaru nebo skriptů. Rychlé googlování přineslo mnoho možných řešení, vše se scvrklo na fakt, že nahrajete skripty (v Pyha, Bash, Python atd.) na server a budete spokojeni. Chtěl jsem implementovat monitoring „out of the box“ – bez externích skriptů a instalace dalšího softwaru na server s monitoringem a PBX.
Strávil jsem s tím celkem 4 pracovní dny, ale výsledek stál za to. Práce přes rozhraní AMI, nízkoúrovňová detekce, triggery a hlavně připojení ústředny a všechna další nastavení nyní zabere asi 15 minut.
K dispozici je Zabbix 4.4, asi 100 kusů Asterisk verze 13. Některé PBX jsou dodávány s webovým rozhraním FreePBX, některé s holou konzolí, spoustou triků a integrací přes dialplan.
Příjem dat z ústředny
První a hlavní bod, který je třeba vyřešit, je získávání dat o peerech a registracích SIP. K tomuto účelu má ústředna konzolová rozhraní AGI, AMI, ARI a SSH. Z pochopitelných důvodů jsem o přídavných modulech neuvažoval.
Nejprve musíme zjistit, co jsou tito agi, ami, ari...
- AGI - použití skriptů v dialplanu. Používá se hlavně pro správu hovorů.
- AMI - umí poskytnout všechny potřebné informace, funguje přes port 5038, podobně jako Telnet. Vyhovuje nám!
- ARI - moderní, módní, JSON. Možností je mnoho, formát dat je pro Zabbix srozumitelný, ale pro mě neexistuje žádná hlavní věc: nemůžete ovládat registraci sip. Další nevýhodou je, že pro peery jsou pouze dva stavy online/offline, i když stavů je více a je užitečné je při diagnostice zohlednit.
- SSH umí všechno, ale někdy to není z „bezpečnostních důvodů“ povoleno. Úvahy mohou být různé, nebudu je rozebírat.
Se všemi svými nedostatky však ARI pokrývá 90 % všech potřeb monitorování.
Zabbix a Telnet – moje zklamání
AMI dobře znám, svého času jsem implementoval sledování ztrát v rozhovorech s divizí podle vzdálených poboček, správu hovorů atd. S Telnetem je také vše velmi jasné: otevřete připojení, odešlete příkazy a přečtěte si odpověď. To jsem udělal, ale výsledek mě zklamal.
Telnet v Zabbix není stejný jako v linuxové konzoli, je o něco jednodušší a přizpůsobený pro standardní autorizaci, jako je login/heslo. Pokud je logika autorizace odlišná a neexistuje žádný požadavek na pár přihlašovací jméno/heslo, dojde k chybě. Po marných pokusech obejít požadavek autorizace bylo užitečné podívat se na zdrojový kód modulu Telnet.
Uvědomil jsem si, že dokud nebude tradiční požadavek na přihlášení a heslo, neposunu se dál. Jen pro zajímavost jsem z kódu odstranil vše, co se týkalo autorizace a vše znovu poskládal. Funguje! Ale nesplňuje požadavky. Pokračuj…
Vraťme se k hledání
Znovu jsem si přečetl dokumentaci k ARI, provedl další testy - zde nejsou žádné sip registrace. Jsou hody, jsou rozhovory, jsou kalhoty, ale nejsou žádné registrace. V určitém okamžiku jsem si dokonce myslel, že opravdu potřebujeme registraci supů?
Vtipnou shodou okolností v tuto chvíli přichází další požadavek od uživatele s problémem s odchozími hovory. Problém byl v tom, že registrace sip zamrzala a byla vyřešena jednoduchým restartem modulu.
asterisk -rx "sip reload"Bylo by skvělé mít přístup k AMI přes web: to by vyřešilo všechny problémy, pomyslel jsem si. Začínám kopat tímto směrem a doslova první vyhledávací řádek vede k oficiální dokumentaci Asterisk, která říká, že pro mé úkoly existuje možnost web povolen v souboru /etc/asterisk/manager.conf, kterou je potřeba v sekci nastavit na ANO [obecně]
Poté prostřednictvím běžné webové žádosti formuláře získáme všechny potřebné informace.
Při použití rozhraní FreePBX nelze tuto možnost povolit přes web, musíte ji povolit prostřednictvím konzole provedením změn v souboru manager.conf. FreePBX jej nevymaže, když jsou změny konfigurace provedeny přes web.
Dlouho jsem pracoval s různými druhy integrací Asterisk, ale nikdy jsem nikde neviděl tuto funkci zmíněnou. Překvapilo mě, že tento způsob interakce s ústřednou nikdo nepopisuje. Dokonce bylo obzvláště užitečné hledat informace na toto téma: prakticky nic nebo bylo použito pro úplně jiné úkoly.
WEB AMI - jaký druh bestie?
Přidání možnosti web povolen do souboru manager.conf poskytl plný přístup ke správě ATS přes web. Všechny příkazy dostupné přes běžné AMI jsou nyní na webu, události z PBX můžete poslouchat přes zásuvku. Princip fungování se neliší od konzole AMI. Po aktivaci této možnosti můžete ústřednu kontaktovat na následujících adresách:
— webová stránka s jednoduchým rozhraním pro testování a ruční odesílání požadavků. Všechny odpovědi jsou formátovány do čitelného HTML. Není příliš vhodný pro sledování.
— pouze textový výstup, formát podobný konzolovému AMI
- pouze textový výstup ve formátu XML. Vyhovuje nám!
Pak jsem si pomyslel: „To je řešení! Nyní bude vše připraveno! Snadno peezy citronové mačkání,“ ale na radost bylo příliš brzy. Pro získání informací, které potřebujeme, stačí použít požadavek GET s potřebnou akcí akce, který jako odpověď vrátí xml se seznamem všech registrací a jejich stavem. To vše je skvělé, ale k zapamatování relace ze souboru cookie potřebujete autorizaci. Když testujete v prohlížeči, nemyslíte na tento proces.
Autorizační proces
Nejprve řešíme adresu , jako odpověď nám server odešle cookie s autorizační relací. Takto vypadá požadavek 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: 1Odpověď:
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>
Abyste tam mohli pracovat, potřebujete mansession_id="6f5de42c“, tedy samotný autorizační soubor cookie.
Obsah, u kterého stačí zkontrolovat odpověď "Autentizace přijata" Dále pro všechna volání na server PBX budeme muset k požadavku přidat autorizační cookie.
https://ats:8089/mxml?action=SIPpeers
Host: ats:8089
Connection: close
Cookie: mansession_id="6f5de42c"Přečtěte si, jak získat autorizační soubor cookie a použít jej v dalších požadavcích zde: “»
K vytvoření sledovacích prvků v Zabbixu použiji automatickou detekci.
Automatická detekce
Chcete-li automaticky zjišťovat registrace a sledovat stavy rovnocenných partnerů, musíte kontaktovat následující adresu: nebo
V odpovědi nám ústředna vrátí odpověď 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>
V odpovědi je spousta smetí, takže v předzpracování je filtrujeme podle šablony XPath: //response/generic[@host]
Pak začíná zábava. Chcete-li pracovat s detekcí a dynamicky vytvářet prvky, musí být odpověď ve formátu JSON. XML není podporováno pro automatické detekce.
Pro převod XML do JSON jsem si musel trochu pohrát s automatickou náhradou, pro kterou jsem udělal skript v JS
Zajímavý bod: v odpovědi ATS jsou všechny parametry obklopeny jednoduchými uvozovkami a po použití šablony //response/generic[@host] jsou nahrazeny dvojitými.
K vytvoření prvků používáme proměnné z odpovědi XML (nyní JSON).
Registr SIP
Pro registrace sip používáme tři proměnné: uživatelské jméno, hostitel, přístav. S názvem prvku jsem byl spokojený [chráněno e-mailem]: 5060, nenašel jsem žádné situace, kdy byste potřebovali použít všech pět proměnných.
Hlavním prvkem, který přijímá informace o všech registracích, Hvězdička - AMI SIPshowregistry. Jednou za minutu vytvoří požadavek GET , po kterém jsou data XML odpovědi předána všem závislým prvkům k analýze. Pro každou registraci vytvořím prvek na ní závislý. To je výhodné, protože aktuální informace dostáváme v jedné žádosti, nikoli pro každou žádost zvlášť. Tato implementace má značnou nevýhodu - zatížení procesoru.
Při testování do 100 závislých prvků jsem zátěž nezaznamenal, ale s 1700 prvky to dávalo procesoru citelné 15 sekundové zatížení. Mějte to na paměti, pokud máte velký počet závislých prvků.
Jako možnost „rozložit“ zatížení nebo nastavit různé frekvence dotazování pro prvek můžete přesunout logiku zpracování na každý prvek samostatně.
Přijaté informace neukládám do hlavního prvku. Za prvé, nevidím potřebu toho, a za druhé, pokud je odezva větší než 64 kB, Zabbix ji přeruší.
Protože pro závislý prvek používáme úplnou odpověď XML, potřebujeme získat hodnotu tohoto prvku v předběžném zpracování. Přes XPath dělá se to takto:
string(//response/generic[@event="RegistryEntry"][@username="{#SIP_REGISTRY_USERNAME}"][@host="{#SIP_REGISTRY_HOST}"][@port="{#SIP_REGISTRY_PORT}"]/@ Stát)
Pro stavy registrace jsem nepoužil textové stavy, ale převedl je do číselné podoby pomocí JavaScriptu:
switch(value) {
case 'Registered':
return 1;
case 'Unregistered':
return 0;
default:
return -1;
}
SIP Peers
Analogicky k registracím SIP existuje hlavní prvek Asterisk - AMI SIPshowregistry, ke kterému jsou přidány závislé.
Tím se vytvoří dva závislé prvky:
- Stav rovnocenného partnera v textové podobě
- Doba odezvy zařízení - pokud je stav v pořádku, zapíše se doba odezvy zařízení, jinak "-1"
Cesta k samotnému prvku je o něco jednodušší XPath:
string(//response/generic[@objectname="{#SIP_PEER_OBEJECTNAME}"]/@status)
Pro druhý prvek jsem k oddělení použil JavaScript doba odezvy ze stavu peer, protože jsou uloženy společně:
if(value.substring(0,2) == 'OK'){
return value.match(/(d+)/gm);
}
else {
return -1;
}Závěr
Hotové řešení může být složité a nemusí být hned jasné. Zvyšuje flexibilitu a přenositelnost mezi různými systémy
Šťastnou a snadnou integraci všem! Šablona a pokyny pro nastavení .
Zdroj: www.habr.com