I forrige artikkel
Ideen om å "bli venner" med disse to systemene ble født for lenge siden, uten å installere ekstra programvare eller skript. En rask googling ga mange mulige løsninger, det hele kokte ned til at man laster opp skriptene (i Pyha, Bash, Python, etc.) til serveren, så blir du fornøyd. Jeg ønsket å implementere overvåking "ut av boksen" - uten eksterne skript og installere tilleggsprogramvare på serveren med overvåking og PBX.
Jeg brukte totalt 4 arbeidsdager med denne, men resultatet var verdt det. Å jobbe gjennom AMI-grensesnittet, lavnivådeteksjon, triggere og viktigst av alt, tilkobling av PBX og alle andre innstillinger tar nå omtrent 15 minutter.
Zabbix 4.4 er tilgjengelig, omtrent 100 stykker av Asterisk versjon 13. Noen PBX-er kommer med FreePBX-nettgrensesnittet, noen med en bar konsoll, en haug med triks og integrasjon via en oppringningsplan.
Motta data fra PBX
Det første og viktigste punktet som må løses er innhenting av data om jevnaldrende og SIP-registreringer. For dette formålet har PBX AGI, AMI, ARI og SSH konsollgrensesnitt. Av åpenbare grunner vurderte jeg ikke tilleggsmoduler.
Først må vi finne ut hva disse agi, ami, ari er...
- AGI - ved å bruke skript i telefonplanen. Brukes hovedsakelig til samtalehåndtering.
- AMI - kan gi all nødvendig informasjon, fungerer via port 5038, lik Telnet. Passer oss!
- ARI - moderne, moteriktig, JSON. Det er mange muligheter, dataformatet er forståelig for Zabbix, men for meg er det ingen hovedsak: du kan ikke kontrollere slurkregistreringen. En annen ulempe er at for jevnaldrende er det bare to stater online/offline, selv om det er flere stater og det er nyttig å ta hensyn til dem ved diagnostisering.
- SSH kan gjøre alt, men noen ganger er det ikke tillatt på grunn av "sikkerhetsårsaker". Hensynene kan være forskjellige, jeg vil ikke gå inn på dem.
Men med alle sine mangler dekker ARI 90 % av alle overvåkingsbehov.
Zabbix og Telnet - min skuffelse
Jeg kjenner AMI godt; på et tidspunkt implementerte jeg sporing av tap i samtaler med divisjon etter eksterne kontorer, samtaleadministrasjon, etc. Med Telnet er alt også veldig tydelig: åpne tilkoblingen, send kommandoene og les svaret. Det var det jeg gjorde, men resultatet skuffet meg.
Telnet i Zabbix er ikke det samme som i Linux-konsollen, det er litt enklere og skreddersydd for standard autorisasjon som pålogging/passord. Hvis autorisasjonslogikken er forskjellig, og det ikke er noen forespørsel om et pålogging/passord-par, oppstår det en feil. Etter fåfengte forsøk på å omgå autorisasjonskravet, var det nyttig å se på kildekoden til Telnet-modulen.
Jeg innså at før det er en tradisjonell forespørsel om pålogging og passord, vil jeg ikke gå videre. Bare for moro skyld fjernet jeg alt relatert til autorisasjon fra koden og satte alt sammen igjen. Virker! Men den oppfyller ikke kravene. Gå videre…
La oss gå tilbake til søket
Jeg leste ARI-dokumentasjonen på nytt, kjørte ytterligere tester - det er ingen sip-registreringer her. Det er fester, det er samtaler, det er knebukser, men det er ingen påmeldinger. På et tidspunkt tenkte jeg til og med, trenger vi virkelig gribbregistrering?
Ved en morsom tilfeldighet kommer det i dette øyeblikk en ny forespørsel fra brukeren, med et problem med utgående anrop. Problemet var at slurkregistreringen fryser og ble løst ved å starte modulen på nytt.
asterisk -rx "sip reload"
Det ville være flott å få tilgang til AMI over nettet: det ville løse alle problemene, tenkte jeg. Jeg begynner å grave i denne retningen, og bokstavelig talt fører den første søkelinjen til den offisielle Asterisk-dokumentasjonen, som sier at det er et alternativ for oppgavene mine webaktivert i fil /etc/asterisk/manager.conf, som må settes til JA, i delen [generell]
Etter dette, gjennom en vanlig nettforespørsel av skjemaet
Når du bruker FreePBX-grensesnittet, kan du ikke aktivere dette alternativet via nettet, du må aktivere det via konsollen ved å gjøre endringer i manager.conf-filen. FreePBX sletter den ikke når konfigurasjonsendringer gjøres via nettet.
Jeg har jobbet med ulike typer Asterisk-integrasjoner i lang tid, men jeg har aldri sett denne funksjonen nevnt noe sted. Jeg ble overrasket over at ingen beskriver denne metoden for samhandling med PBX. Det var til og med spesielt nyttig å se etter informasjon om dette emnet: det er praktisk talt ingenting, eller det ble brukt til helt andre oppgaver.
WEB AMI - hva slags beist?
Legger til et alternativ webaktivert å lagre manager.conf gitt full tilgang til ATS-administrasjon via nettet. Alle kommandoer tilgjengelig gjennom en vanlig AMI er nå på nettet, du kan lytte til hendelser fra PBX via en stikkontakt. Driftsprinsippet er ikke forskjellig fra konsollen AMI. Etter å ha aktivert dette alternativet, kan du kontakte hussentralen på følgende adresser:
Da tenkte jeg: «Dette er løsningen! Nå skal alt være klart! Lett-peezy sitronskvis,” men det var for tidlig å glede seg. For å få den informasjonen vi trenger, er det nok å bruke en GET-forespørsel med nødvendig handling handling, som som svar returnerer xml med en liste over alle registreringer og deres status. Alt dette er bra, men du trenger autorisasjon for å huske økten fra informasjonskapselen. Når du tester i nettleseren, tenker du ikke på denne prosessen.
Autorisasjonsprosess
Først adresserer vi adressen
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: 1
Svar:
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 å jobbe der trenger du mansession_id="6f5de42c", dvs. selve autorisasjonsinformasjonskapselen.
Innhold du bare trenger å se etter svaret "Autentisering akseptert" Deretter, for alle anrop til PBX-serveren, må vi legge til en autorisasjonsinformasjonskapsel i forespørselen.
https://ats:8089/mxml?action=SIPpeers
Host: ats:8089
Connection: close
Cookie: mansession_id="6f5de42c"
Les hvordan du får en autorisasjonsinformasjonskapsel og bruker den i andre forespørsler her: "
For å lage sporingselementer i Zabbix vil jeg bruke automatisk deteksjon.
Automatisk deteksjon
For automatisk å oppdage registreringer og spore peer-statuser, må du kontakte følgende adresse:
Som svar returnerer PBX oss 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>
Det er mye søppel i svaret, så i forbehandling filtrerer vi det etter mal XPath: //respons/generisk[@vert]
Så begynner moroa. For å jobbe med deteksjon og dynamisk lage elementer, må svaret være i JSON-format. XML støttes ikke for automatisk deteksjon.
For å konvertere XML til JSON måtte jeg leke litt med automatisk erstatning, som jeg laget et script til i JS
Et interessant poeng: i ATS-svaret er alle parametere omgitt av enkle anførselstegn, og etter bruk av malen //respons/generisk[@vert] de erstattes med doble.
For å lage elementer bruker vi variabler fra XML-svaret (nå JSON).
SIP-registeret
For slurkregistreringer bruker vi tre variabler: brukernavn, vert, havn. Jeg var fornøyd med navnet på elementet [e-postbeskyttet]: 5060, Jeg har ikke funnet noen situasjoner der du trenger å bruke alle fem variablene.
Hovedelementet som mottar informasjon om alle registreringer, Asterisk - AMI SIPshowregistry. En gang i minuttet sender den en GET-forespørsel til
Ved testing av opptil 100 avhengige elementer la jeg ikke merke til belastningen, men med 1700 elementer ga dette en merkbar 15 sekunders belastning på prosessoren. Husk dette hvis du har et stort antall avhengige elementer.
Som et alternativ for å "spre ut" lasten eller angi forskjellige pollingfrekvenser for et element, kan du flytte behandlingslogikken til hvert element separat.
Jeg lagrer ikke den mottatte informasjonen i hovedelementet. For det første ser jeg ikke behovet for dette, og for det andre, hvis svaret er mer enn 64K, avskjærer Zabbix det.
Siden vi bruker et fullstendig XML-svar for det avhengige elementet, må vi få verdien av dette elementet i forbehandling. Gjennom XPath det er gjort slik:
string(//response/generic[@event="RegistryEntry"][@username="{#SIP_REGISTRY_USERNAME}"][@host="{#SIP_REGISTRY_HOST}"][@port="{#SIP_REGISTRY_PORT}"]/@ stat)
For registreringsstatuser brukte jeg ikke tekststatuser, men konverterte dem til numerisk form ved å bruke JavaScript:
switch(value) {
case 'Registered':
return 1;
case 'Unregistered':
return 0;
default:
return -1;
}
SIP Peers
I analogi med SIP-registreringer er det et hovedelement i Asterisk - AMI SIPshowregistry, som avhengige legges til.
Dette skaper to avhengige elementer:
- Peer-status i tekstform
- Enhetens responstid - hvis statusen er OK, skrives enhetens responstid, ellers "-1"
Veien til selve elementet er litt enklere XPath:
string(//response/generic[@objectname="{#SIP_PEER_OBEJECTNAME}"]/@status)
For det andre elementet brukte jeg JavaScript for å skille responstid fra peer-statusen, siden de er lagret sammen:
if(value.substring(0,2) == 'OK'){
return value.match(/(d+)/gm);
}
else {
return -1;
}
Konklusjon
En klar løsning kan være kompleks og ikke umiddelbart oversiktlig. Øker fleksibilitet og portabilitet mellom ulike systemer
Glad og enkel integrering alle sammen! Mal og instruksjoner for oppsett
Kilde: www.habr.com