Hvordan koble Zabbix med Asterisk ut av esken

I forrige artikkel "Zabbix - utvider makrogrenser" Jeg fortalte deg hvordan du mottar en autorisasjonsøkt og erstatter den med en lokal vertsmakro. I denne artikkelen vil jeg fortelle deg hvordan du kobler Zabbix med Asterisk uten eksterne skript og programvare.

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 http://ats:8089/mxml?action=SIPshowregistry vi får all nødvendig informasjon.

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:

https://ats:8089/manager — en nettside med et enkelt grensesnitt for testing og manuell sending av forespørsler. Alle svar er formatert til lesbar HTML. Ikke særlig egnet for overvåking.
https://ats:8089/rawman — Kun tekstutgang, format som ligner på konsoll AMI
https://ats:8089/mxml - Kun tekstutgang, i XML-format. Passer oss!

Hvordan koble Zabbix med Asterisk ut av esken

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 http://ats:8089/mxml?action=login&username=zabbix&secret=zabbix, som svar sender serveren oss en informasjonskapsel med autorisasjonsøkten. Slik ser en HTTP-forespørsel 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: 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: "Zabbix - utvidende makrogrenser»

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: https://ats:8089/mxml?action=SIPshowregistry eller https://ats:8089/mxml?action=SIPpeers

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

Hvordan koble Zabbix med Asterisk ut av esken

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)​.

Hvordan koble Zabbix med Asterisk ut av esken

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 https://ats:8089/mxml?action=SIPshowregistry, hvoretter responsen XML-data sendes til alle avhengige elementer for parsing. For hver registrering lager jeg et element avhengig av det. Dette er praktisk fordi vi mottar oppdatert informasjon i én forespørsel, og ikke for hver forespørsel separat. Denne implementeringen har en betydelig ulempe - belastningen på prosessoren.

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 GitHub.

Kilde: www.habr.com

Legg til en kommentar