I en tidigare artikel Jag berättade för dig hur du tar emot en auktoriseringssession och ersätter den med ett lokalt värdmakro. I den här artikeln kommer jag att berätta hur du ansluter Zabbix med Asterisk utan externa skript och programvara.
Idén att "bli vänner" med dessa två system föddes för länge sedan, utan att installera ytterligare programvara eller skript. En snabb googling gav många möjliga lösningar, det hela gick ut på att ladda upp skripten (i Pyha, Bash, Python, etc.) till servern, och du kommer att bli nöjd. Jag ville implementera övervakning "out of the box" - utan externa skript och installera ytterligare programvara på servern med övervakning och PBX.
Jag tillbringade totalt 4 arbetsdagar med detta, men resultatet var värt det. Arbetet genom AMI-gränssnittet, lågnivådetektering, triggers och viktigast av allt, att ansluta PBX och alla andra inställningar tar nu cirka 15 minuter.
Zabbix 4.4 är tillgänglig, cirka 100 stycken av Asterisk version 13. Vissa PBX:er kommer med FreePBX-webbgränssnittet, vissa med en blottad konsol, en massa knep och integration via en uppringningsplan.
Tar emot data från telefonväxeln
Den första och viktigaste punkten som måste lösas är att få fram data om peers och SIP-registreringar. För detta ändamål har telefonväxeln AGI-, AMI-, ARI- och SSH-konsolgränssnitt. Av förklarliga skäl övervägde jag inte ytterligare moduler.
Först måste vi ta reda på vad dessa agi, ami, ari är...
- AGI - använder skript i uppringningsplanen. Används främst för samtalshantering.
- AMI - kan tillhandahålla all nödvändig information, fungerar via port 5038, liknande Telnet. Passar oss!
- ARI - modern, moderiktig, JSON. Det finns många möjligheter, dataformatet är förståeligt för Zabbix, men för mig är det inget huvudsakligt: du kan inte styra sippregistreringen. En annan nackdel är att det för kamrater bara finns två tillstånd online/offline, även om det finns fler tillstånd och det är användbart att ta hänsyn till dem vid diagnostisering.
- SSH kan göra allt, men ibland är det inte tillåtet på grund av "säkerhetsskäl". Överväganden kan vara olika, jag går inte in på dem.
Men med alla sina brister täcker ARI 90 % av alla övervakningsbehov.
Zabbix och Telnet - min besvikelse
Jag känner till AMI väl; vid ett tillfälle implementerade jag spårning av förluster i konversationer med division av fjärrkontor, samtalshantering, etc. Med Telnet är allt också väldigt tydligt: öppna anslutningen, skicka kommandona och läs svaret. Det var vad jag gjorde, men resultatet gjorde mig besviken.
Telnet i Zabbix är inte detsamma som i Linux-konsolen, det är lite enklare och skräddarsytt för standardauktorisering som inloggning/lösenord. Om auktoriseringslogiken är annorlunda och det inte finns någon begäran om ett inloggnings-/lösenordspar, uppstår ett fel. Efter meningslösa försök att kringgå behörighetskravet var det användbart att titta på källkoden för Telnet-modulen.
Jag insåg att tills det finns en traditionell inloggnings- och lösenordsbegäran kommer jag inte att gå vidare. Bara för skojs skull tog jag bort allt relaterat till auktorisering från koden och satte ihop allt igen. Arbetar! Men den uppfyller inte kraven. Varsågod…
Låt oss återgå till sökningen
Jag läste ARI-dokumentationen igen, körde ytterligare tester - det finns inga sip-registreringar här. Det finns fester, det är samtal, det finns ridbyxor, men det finns inga anmälningar. Någon gång tänkte jag till och med, behöver vi verkligen gamregistrering?
Av en rolig slump kommer i detta ögonblick ytterligare en förfrågan från användaren, med ett problem med utgående samtal. Problemet var att sip-registreringen höll på att frysa och löstes genom att helt enkelt starta om modulen.
asterisk -rx "sip reload"Det skulle vara bra att få tillgång till AMI över webben: det skulle lösa alla problem, tänkte jag. Jag börjar gräva i den här riktningen, och bokstavligen leder den första sökraden till den officiella Asterisk-dokumentationen, som säger att det finns ett alternativ för mina uppgifter webbaktiverad i fil /etc/asterisk/manager.conf, som måste ställas in på JA, i avsnittet [allmän]
Efter detta, genom en vanlig webbförfrågan av formuläret vi får all nödvändig information.
När du använder FreePBX-gränssnittet kan du inte aktivera det här alternativet via webben, du måste aktivera det via konsolen genom att göra ändringar i filen manager.conf. FreePBX raderar det inte när konfigurationsändringar görs via webben.
Jag har arbetat med olika typer av Asterisk-integrationer under lång tid, men jag har aldrig sett den här funktionen nämnts någonstans. Jag blev förvånad över att ingen beskriver denna metod för att interagera med PBX. Det var till och med särskilt användbart att leta efter information om detta ämne: det finns praktiskt taget ingenting eller så användes det för helt andra uppgifter.
WEB AMI - vilken sorts best?
Lägger till ett alternativ webbaktiverad att arkivera manager.conf gav full tillgång till ATS-hantering via webben. Alla kommandon som är tillgängliga via en vanlig AMI finns nu på webben, du kan lyssna på händelser från telefonväxeln via ett uttag. Funktionsprincipen skiljer sig inte från konsolens AMI. Efter att ha aktiverat detta alternativ kan du kontakta telefonväxeln på följande adresser:
— en webbsida med ett enkelt gränssnitt för att testa och manuellt skicka förfrågningar. Alla svar är formaterade till läsbar HTML. Inte särskilt lämplig för övervakning.
— Endast textutmatning, format som liknar konsolens AMI
- Endast textutmatning, i XML-format. Passar oss!
Då tänkte jag: ”Det här är lösningen! Nu ska allt vara klart! Lättpeezy citronpress”, men det var för tidigt att glädjas. För att få den information vi behöver räcker det att använda en GET-förfrågan med nödvändig åtgärd handling, som som svar returnerar xml med en lista över alla registreringar och deras status. Det här är bra, men du behöver auktorisering för att komma ihåg sessionen från cookien. När du testar i webbläsaren tänker du inte på den här processen.
Auktoriseringsprocess
Först tar vi upp adressen , som svar skickar servern oss en cookie med auktoriseringssessionen. Så här ser en HTTP-förfrågan ut:
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: 1Svar:
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>
För att arbeta där behöver du mansession_id="6f5de42c", det vill säga själva auktoriseringscookien.
Innehåll du behöver bara kolla efter svaret "Autentisering accepteras" Därefter, för alla samtal till PBX-servern, måste vi lägga till en auktoriseringscookie till begäran.
https://ats:8089/mxml?action=SIPpeers
Host: ats:8089
Connection: close
Cookie: mansession_id="6f5de42c"Läs hur du får en auktoriseringscookie och använder den i andra förfrågningar här: "»
För att skapa spårningselement i Zabbix kommer jag att använda autodetektering.
Automatisk upptäckt
För att automatiskt upptäcka registreringar och spåra peer-tillstånd måste du kontakta följande adress: eller
Som svar returnerar PBX:en ett XML-svar:
<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>
Det är mycket skräp i svaret, så i förbearbetningen filtrerar vi det efter mall XPath: //respons/generic[@host]
Sedan börjar det roliga. För att arbeta med detektering och dynamiskt skapa element måste svaret vara i JSON-format. XML stöds inte för automatisk upptäckt.
För att konvertera XML till JSON var jag tvungen att leka lite med automatisk ersättning, för vilket jag gjorde ett script i JS
En intressant punkt: i ATS-svaret är alla parametrar omgivna av enstaka citattecken och efter applicering av mallen //respons/generic[@host] de ersätts med dubbla.
För att skapa element använder vi variabler från XML-svaret (nu JSON).
SIP-registret
För sip-registreringar använder vi tre variabler: Användarnamn, värd, port. Jag var nöjd med namnet på elementet [e-postskyddad]: 5060, Jag har inte hittat några situationer där du behöver använda alla fem variablerna.
Huvudelementet som får information om alla registreringar, Asterisk - AMI SIPshowregistry. En gång i minuten gör den en GET-förfrågan till , varefter XML-svarsdata skickas till alla beroende element för analys. För varje registrering skapar jag ett element som är beroende av det. Detta är bekvämt eftersom vi får uppdaterad information i en förfrågan och inte för varje förfrågan separat. Denna implementering har en betydande nackdel - belastningen på processorn.
När jag testade upp till 100 beroende element märkte jag inte belastningen, men med 1700 element gav detta en märkbar 15 sekunders belastning på processorn. Tänk på detta om du har ett stort antal beroende element.
Som ett alternativ för att "sprida ut" lasten eller ställa in olika avfrågningsfrekvenser för ett element, kan du flytta bearbetningslogiken till varje element separat.
Jag lagrar inte den mottagna informationen i huvudelementet. För det första ser jag inte behovet av detta, och för det andra, om svaret är mer än 64K, så avbryter Zabbix det.
Eftersom vi använder ett fullständigt XML-svar för det beroende elementet, måste vi få värdet av detta element i förbearbetningen. Genom XPath det är gjort så här:
string(//response/generic[@event="RegistryEntry"][@username="{#SIP_REGISTRY_USERNAME}"][@host="{#SIP_REGISTRY_HOST}"][@port="{#SIP_REGISTRY_PORT}"]/@ stat)
För registreringsstatusar använde jag inte textstatus, utan konverterade dem till numerisk form med JavaScript:
switch(value) {
case 'Registered':
return 1;
case 'Unregistered':
return 0;
default:
return -1;
}
SIP-kamrater
I analogi med SIP-registreringar finns det ett huvudelement i Asterisk - AMI SIPshowregistry, till vilket beroende läggs till.
Detta skapar två beroende element:
- Peer-status i textform
- Enhetens svarstid - om statusen är OK skrivs enhetens svarstid, annars "-1"
Vägen till själva elementet är lite enklare XPath:
string(//response/generic[@objectname="{#SIP_PEER_OBEJECTNAME}"]/@status)
För det andra elementet använde jag JavaScript för att separera respons tid från peer-statusen, eftersom de lagras tillsammans:
if(value.substring(0,2) == 'OK'){
return value.match(/(d+)/gm);
}
else {
return -1;
}Slutsats
En färdig lösning kan vara komplex och inte direkt tydlig. Ökar flexibiliteten och portabiliteten mellan olika system
Glad och enkel integration alla! Mall och instruktioner för installation .
Källa: will.com