I en tidligere artikel Jeg fortalte dig, hvordan du modtager en godkendelsessession og erstatter den med en lokal værtsmakro. I denne artikel vil jeg fortælle dig, hvordan du forbinder Zabbix med Asterisk uden eksterne scripts og software.
Ideen om at "blive venner" med disse to systemer blev født for længe siden uden at installere yderligere software eller scripts. En hurtig google gav mange mulige løsninger, det hele gik ud på at uploade scripts (i Pyha, Bash, Python osv.) til serveren, og du bliver glad. Jeg ville implementere overvågning "ud af boksen" - uden eksterne scripts og installere ekstra software på serveren med overvågning og PBX.
Jeg brugte i alt 4 arbejdsdage med dette, men resultatet var det værd. Det tager nu omkring 15 minutter at arbejde gennem AMI-grænsefladen, registrering på lavt niveau, triggere og vigtigst af alt, at forbinde PBX'en og alle andre indstillinger.
Zabbix 4.4 er tilgængelig, omkring 100 stykker Asterisk version 13. Nogle PBX'er kommer med FreePBX-webgrænsefladen, nogle med en blottet konsol, en masse tricks og integration via en opkaldsplan.
Modtagelse af data fra PBX
Det første og vigtigste punkt, der skal løses, er indhentning af data om peers og SIP-registreringer. Til dette formål har PBX'en AGI-, AMI-, ARI- og SSH-konsolgrænseflader. Af indlysende grunde overvejede jeg ikke yderligere moduler.
Først skal vi finde ud af, hvad disse agi, ami, ari er...
- AGI - ved hjælp af scripts i opkaldsplanen. Anvendes hovedsageligt til opkaldsstyring.
- AMI - kan give alle nødvendige oplysninger, fungerer via port 5038, svarende til Telnet. Passer til os!
- ARI - moderne, moderigtigt, JSON. Der er mange muligheder, dataformatet er forståeligt for Zabbix, men for mig er der ingen hovedting: du kan ikke styre slurk-registreringen. En anden ulempe er, at der for jævnaldrende kun er to tilstande online/offline, selvom der er flere tilstande, og det er nyttigt at tage hensyn til dem, når man diagnosticerer.
- SSH kan alt, men nogle gange er det ikke tilladt på grund af "sikkerhedsmæssige årsager". Overvejelser kan være anderledes, dem vil jeg ikke komme ind på.
Men med alle dens mangler dækker ARI 90 % af alle overvågningsbehov.
Zabbix og Telnet - min skuffelse
Jeg kender AMI godt; på et tidspunkt implementerede jeg sporing af tab i samtaler med division ved fjernkontorer, opkaldsstyring osv. Med Telnet er alt også meget klart: åbn forbindelsen, send kommandoerne og læs svaret. Det var det, jeg gjorde, men resultatet skuffede mig.
Telnet i Zabbix er ikke det samme som i Linux-konsollen, det er lidt enklere og skræddersyet til standardautorisation såsom login/adgangskode. Hvis autorisationslogikken er anderledes, og der ikke er nogen anmodning om et login/adgangskode-par, opstår der en fejl. Efter forgæves forsøg på at omgå autorisationskravet, var det nyttigt at se på kildekoden til Telnet-modulet.
Jeg indså, at indtil der er en traditionel login- og adgangskodeanmodning, vil jeg ikke komme videre. For sjov fjernede jeg alt relateret til autorisation fra koden og genopbyggede alt. Arbejder! Men det opfylder ikke kravene. Fortsæt…
Lad os vende tilbage til søgningen
Jeg genlæste ARI-dokumentationen igen, kørte yderligere test - der er ingen sip-registreringer her. Der er fester, der er samtaler, der er ridebukser, men der er ingen tilmeldinger. På et tidspunkt tænkte jeg endda, har vi virkelig brug for gribberegistrering?
Ved et sjovt tilfælde kommer der i dette øjeblik endnu en anmodning fra brugeren med et problem med udgående opkald. Problemet var, at sip-registreringen fryser og blev løst ved blot at genstarte modulet.
asterisk -rx "sip reload"Det ville være fantastisk at få adgang til AMI over nettet: det ville løse alle problemerne, tænkte jeg. Jeg begynder at grave i denne retning, og bogstaveligt talt fører den første søgelinje til den officielle Asterisk-dokumentation, som siger, at der er en mulighed for mine opgaver webaktiveret i fil /etc/asterisk/manager.conf, som skal indstilles til JA, i afsnittet [generel]
Herefter gennem en almindelig webanmodning af formularen vi får alle nødvendige oplysninger.
Når du bruger FreePBX-grænsefladen, kan du ikke aktivere denne mulighed via internettet; du skal aktivere den via konsollen ved at foretage ændringer i filen manager.conf. FreePBX sletter det ikke, når konfigurationsændringer foretages via internettet.
Jeg har arbejdet med forskellige former for Asterisk-integrationer i lang tid, men jeg har aldrig set denne funktion nævnt nogen steder. Jeg var overrasket over, at ingen beskriver denne metode til at interagere med PBX. Det var endda særligt nyttigt at lede efter information om dette emne: der er praktisk talt intet, eller det blev brugt til helt andre opgaver.
WEB AMI - hvilken slags udyr?
Tilføjelse af en mulighed webaktiveret at arkivere manager.conf givet fuld adgang til ATS-styring via nettet. Alle kommandoer, der er tilgængelige gennem en almindelig AMI, er nu på nettet, du kan lytte til begivenheder fra PBX'en via et stik. Funktionsprincippet er ikke forskelligt fra konsollens AMI. Når du har aktiveret denne mulighed, kan du kontakte PBX'en på følgende adresser:
— en webside med en enkel grænseflade til test og manuel afsendelse af anmodninger. Alle svar er formateret til læsbar HTML. Ikke særlig velegnet til overvågning.
— Kun tekstoutput, format svarende til konsol AMI
- Kun tekstoutput i XML-format. Passer til os!
Så tænkte jeg: “Dette er løsningen! Nu vil alt være klar! Let-peezy citronpresser,” men det var for tidligt at glæde sig. For at få de oplysninger, vi har brug for, er det nok at bruge en GET-anmodning med den nødvendige handling Action, som som svar returnerer xml med en liste over alle registreringer og deres status. Det hele er fantastisk, men du skal have tilladelse til at huske sessionen fra cookien. Når du tester i browseren, tænker du ikke på denne proces.
Autorisationsproces
Først adresserer vi adressen , som svar sender serveren os en cookie med godkendelsessessionen. Sådan ser en HTTP-anmodning ud:
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>
For at arbejde der har du brug for mansession_id="6f5de42c", dvs. selve autorisationscookien.
Indhold du bare skal tjekke for svaret "Godkendelse accepteret" Dernæst, for alle opkald til PBX-serveren, skal vi tilføje en autorisationscookie til anmodningen.
https://ats:8089/mxml?action=SIPpeers
Host: ats:8089
Connection: close
Cookie: mansession_id="6f5de42c"Læs, hvordan du får en autorisationscookie og bruger den i andre anmodninger her: "»
For at oprette sporingselementer i Zabbix vil jeg bruge automatisk detektion.
Automatisk registrering
For automatisk at registrere registreringer og spore peer-tilstande skal du kontakte følgende adresse: eller
Som svar returnerer PBX os et 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>
Der er meget skrald i svaret, så i forbehandlingen filtrerer vi det efter skabelon XPath: //respons/generisk[@host]
Så begynder det sjove. For at arbejde med detektion og dynamisk oprette elementer, skal svaret være i JSON-format. XML er ikke understøttet til automatisk registrering.
For at konvertere XML til JSON skulle jeg lege lidt med automatisk udskiftning, som jeg lavede et script til i JS
Et interessant punkt: i ATS-svaret er alle parametre omgivet af enkelte anførselstegn, og efter anvendelse af skabelonen //respons/generisk[@host] de erstattes af dobbelte.
For at oprette elementer bruger vi variabler fra XML-svaret (nu JSON).
SIP-registrering
Til sip-registreringer bruger vi tre variabler: brugernavn, host, port. Jeg var glad for navnet på elementet [e-mail beskyttet]: 5060, Jeg har ikke fundet nogen situationer, hvor du skal bruge alle fem variabler.
Hovedelementet, der modtager information om alle tilmeldinger, Asterisk - AMI SIPshowregistry. En gang i minuttet sender den en GET-anmodning til , hvorefter responsen XML-data sendes til alle afhængige elementer til parsing. For hver registrering opretter jeg et element afhængigt af det. Dette er praktisk, fordi vi modtager opdaterede oplysninger i én anmodning og ikke for hver anmodning separat. Denne implementering har en betydelig ulempe - belastningen på processoren.
Ved test af op til 100 afhængige elementer bemærkede jeg ikke belastningen, men med 1700 elementer gav dette en mærkbar 15 sekunders belastning på processoren. Husk dette, hvis du har et stort antal afhængige elementer.
Som en mulighed for at "sprede" belastningen eller indstille forskellige polling-frekvenser for et element, kan du flytte behandlingslogikken til hvert element separat.
Jeg gemmer ikke de modtagne oplysninger i hovedelementet. For det første kan jeg ikke se behovet for dette, og for det andet, hvis svaret er mere end 64K, så afbryder Zabbix det.
Da vi bruger et fuldt XML-svar til det afhængige element, er vi nødt til at få værdien af dette element i forbehandlingen. igennem XPath det gøres sådan her:
string(//response/generic[@event="RegistryEntry"][@username="{#SIP_REGISTRY_USERNAME}"][@host="{#SIP_REGISTRY_HOST}"][@port="{#SIP_REGISTRY_PORT}"]/@ stat)
Til registreringsstatusser brugte jeg ikke tekststatusser, men konverterede dem til numerisk form ved hjælp af JavaScript:
switch(value) {
case 'Registered':
return 1;
case 'Unregistered':
return 0;
default:
return -1;
}
SIP Peers
Analogt med SIP-registreringer er der et hovedelement i Asterisk - AMI SIPshowregistry, hvortil afhængige tilføjes.
Dette skaber to afhængige elementer:
- Peer-status i tekstform
- Enhedens responstid - hvis status er OK, skrives enhedens responstid, ellers "-1"
Vejen til selve elementet er lidt enklere XPath:
string(//response/generic[@objectname="{#SIP_PEER_OBEJECTNAME}"]/@status)
Til det andet element brugte jeg JavaScript til at adskille responstid fra peer-status, da de er gemt sammen:
if(value.substring(0,2) == 'OK'){
return value.match(/(d+)/gm);
}
else {
return -1;
}Konklusion
En out-of-the-box løsning kan være kompleks og ikke umiddelbart klar. Øger fleksibilitet og portabilitet mellem forskellige systemer
Glad og nem integration alle sammen! Skabelon og instruktioner til opsætning .
Kilde: www.habr.com