Yn yr erthygl flaenorol Dywedais wrthych sut i dderbyn sesiwn awdurdodi a'i amnewid yn macro gwesteiwr lleol. Yn yr erthygl hon byddaf yn dweud wrthych sut i gysylltu Zabbix â Asterisk heb sgriptiau a meddalwedd allanol.
Ganed y syniad i “wneud ffrindiau” o’r ddwy system hyn amser maith yn ôl, heb osod meddalwedd na sgriptiau ychwanegol. Fe wnaeth googling cyflym esgor ar lawer o atebion posibl, roedd y cyfan yn dibynnu ar y ffaith bod y sgriptiau (yn Pyha, Bash, Python, ac ati) yn llwytho i fyny i'r gweinydd, a byddwch yn hapus. Roeddwn i eisiau gweithredu monitro “allan o'r bocs” - heb sgriptiau allanol a gosod meddalwedd ychwanegol ar y gweinydd gyda monitro a PBX.
Treuliais gyfanswm o 4 diwrnod gwaith gyda hyn, ond roedd y canlyniad yn werth chweil. Mae gweithio trwy'r rhyngwyneb AMI, canfod lefel isel, sbardunau, ac yn bwysicaf oll, mae cysylltu'r PBX a'r holl leoliadau eraill bellach yn cymryd tua 15 munud.
Mae Zabbix 4.4 ar gael, tua 100 darn o fersiwn seren 13. Daw rhai PBXs gyda rhyngwyneb gwe FreePBX, rhai gyda chonsol noeth, criw o driciau ac integreiddio trwy gynllun deialu.
Derbyn data o'r PBX
Y pwynt cyntaf a phrif y mae angen ei ddatrys yw cael data am gofrestriadau cymheiriaid a SIP. At y diben hwn, mae gan y PBX ryngwynebau consol AGI, AMI, ARI a SSH. Am resymau amlwg, ni wnes i ystyried modiwlau ychwanegol.
Yn gyntaf mae angen i ni ddarganfod beth yw'r rhain agi, ami, ari...
- AGI - defnyddio sgriptiau yn y cynllun deialu. Defnyddir yn bennaf ar gyfer rheoli galwadau.
- AMI - yn gallu darparu'r holl wybodaeth angenrheidiol, yn gweithio trwy borthladd 5038, yn debyg i Telnet. Siwtio ni!
- ARI - modern, ffasiynol, JSON. Mae yna lawer o bosibiliadau, mae'r fformat data yn ddealladwy ar gyfer Zabbix, ond i mi nid oes prif beth: ni allwch reoli'r cofrestriad sipian. Anfantais arall yw mai dim ond dwy dalaith sydd ar-lein/all-lein i gyfoedion, er bod mwy o daleithiau ac mae'n ddefnyddiol eu cymryd i ystyriaeth wrth wneud diagnosis.
- Gall SSH wneud popeth, ond weithiau ni chaiff ei ganiatáu oherwydd "rhesymau diogelwch". Gall ystyriaethau fod yn wahanol, nid af i mewn iddynt.
Fodd bynnag, gyda'i holl ddiffygion, mae ARI yn cwmpasu 90% o'r holl anghenion monitro.
Zabbix a Telnet - fy siom
Rwy'n adnabod AMI yn dda; ar un adeg gweithredais olrhain colledion mewn sgyrsiau ag is-adran gan swyddfeydd anghysbell, rheoli galwadau, ac ati. Gyda Telnet, mae popeth hefyd yn glir iawn: agorwch y cysylltiad, anfonwch y gorchmynion a darllenwch yr ymateb. Dyna beth wnes i, ond roedd y canlyniad yn fy siomi.
Nid yw Telnet yn Zabbix yr un peth ag yn y consol Linux, mae ychydig yn symlach ac wedi'i deilwra ar gyfer awdurdodiad safonol fel mewngofnodi / cyfrinair. Os yw'r rhesymeg awdurdodi yn wahanol, ac nad oes cais am bâr mewngofnodi/cyfrinair, bydd gwall yn digwydd. Ar ôl ymdrechion ofer i osgoi'r gofyniad awdurdodi, roedd yn ddefnyddiol edrych ar god ffynhonnell modiwl Telnet.
Sylweddolais, nes bod cais mewngofnodi a chyfrinair traddodiadol, na fyddaf yn symud ymlaen. Er mwyn cael hwyl, tynnais bopeth sy'n ymwneud ag awdurdodiad o'r cod ac ailgynullais bopeth. Yn gweithio! Ond nid yw'n bodloni'r gofynion. Cer ymlaen…
Gadewch i ni ddychwelyd i'r chwiliad
Ailddarllenais ddogfennaeth ARI eto, cynhaliais brofion ychwanegol - nid oes unrhyw gofrestriadau sipian yma. Mae yna wleddoedd, mae sgyrsiau, mae llodrau, ond nid oes unrhyw gofrestriadau. Ar ryw adeg roeddwn i hyd yn oed yn meddwl, a oes gwir angen cofrestru fwlturiaid?
Trwy gyd-ddigwyddiad doniol, ar hyn o bryd mae cais arall yn cyrraedd gan y defnyddiwr, gyda phroblem gyda galwadau sy'n mynd allan. Y broblem oedd bod y cofrestriad sipian yn rhewi ac fe'i datryswyd trwy ailgychwyn y modiwl yn unig.
asterisk -rx "sip reload"Byddai’n wych cael mynediad i AMI dros y we: byddai hynny’n datrys yr holl broblemau, meddyliais. Dechreuaf gloddio i'r cyfeiriad hwn, ac yn llythrennol mae'r llinell chwilio gyntaf yn arwain at y ddogfennaeth seren swyddogol, sy'n dweud bod opsiwn ar gyfer fy nhasgau gwealluog mewn ffeil /etc/asterisk/manager.conf, sydd angen ei osod i OES, yn yr adran [cyffredinol]
Ar ôl hyn, trwy gais gwe rheolaidd o'r ffurflen rydym yn cael yr holl wybodaeth angenrheidiol.
Wrth ddefnyddio'r rhyngwyneb FreePBX, ni allwch alluogi'r opsiwn hwn trwy'r we; mae angen i chi ei alluogi trwy'r consol trwy wneud newidiadau i'r ffeil manager.conf. Nid yw FreePBX yn ei ddileu pan wneir newidiadau cyfluniad trwy'r we.
Rwyf wedi gweithio gyda gwahanol fathau o integreiddiadau seren ers amser maith, ond nid wyf erioed wedi gweld y nodwedd hon yn cael ei chrybwyll yn unman. Cefais fy synnu nad oes neb yn disgrifio'r dull hwn o ryngweithio â'r PBX. Roedd hyd yn oed yn arbennig o ddefnyddiol chwilio am wybodaeth ar y pwnc hwn: nid oes bron unrhyw beth neu fe'i defnyddiwyd ar gyfer tasgau hollol wahanol.
WE AMI - pa fath o fwystfil?
Ychwanegu opsiwn gwealluog i ffeilio rheolwr.conf darparu mynediad llawn i reolaeth ATS drwy'r we. Mae'r holl orchmynion sydd ar gael trwy AMI rheolaidd bellach ar y we, gallwch wrando ar ddigwyddiadau o'r PBX trwy soced. Nid yw'r egwyddor o weithredu yn wahanol i'r consol AMI. Ar ôl actifadu'r opsiwn hwn, gallwch gysylltu â'r PBX yn y cyfeiriadau canlynol:
— tudalen we gyda rhyngwyneb syml ar gyfer profi ac anfon ceisiadau â llaw. Mae pob ymateb yn cael ei fformatio i HTML darllenadwy. Ddim yn addas iawn ar gyfer monitro.
— allbwn testun yn unig, fformat tebyg i consol AMI
- allbwn testun yn unig, mewn fformat XML. Siwtio ni!
Yna meddyliais: “Dyma’r ateb! Nawr bydd popeth yn barod! Lemwn hawdd ei wasgu,” ond roedd yn rhy gynnar i lawenhau. I gael y wybodaeth sydd ei hangen arnom, mae'n ddigon defnyddio cais GET gyda'r camau angenrheidiol gweithredu, sydd mewn ymateb yn dychwelyd xml gyda rhestr o'r holl gofrestriadau a'u statws. Mae hyn i gyd yn wych, ond mae angen awdurdodiad i gofio'r sesiwn o'r cwci. Pan fyddwch chi'n profi yn y porwr, nid ydych chi'n meddwl am y broses hon.
Proses awdurdodi
Yn gyntaf rhoddwn sylw i'r cyfeiriad , mewn ymateb, mae'r gweinydd yn anfon cwci atom gyda'r sesiwn awdurdodi. Dyma sut olwg sydd ar gais 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: 1Ateb:
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>
I weithio yno mae angen mansession_id="6f5de42c", h.y. y cwci awdurdodi ei hun.
Cynnwys does ond angen i chi wirio am yr ateb"Derbyniwyd y dilysiad" Nesaf, ar gyfer pob galwad i'r gweinydd PBX, bydd angen i ni ychwanegu cwci awdurdodi at y cais.
https://ats:8089/mxml?action=SIPpeers
Host: ats:8089
Connection: close
Cookie: mansession_id="6f5de42c"Darllenwch sut i gael cwci awdurdodi a'i ddefnyddio mewn ceisiadau eraill yma: “»
I greu elfennau olrhain yn Zabbix byddaf yn defnyddio canfod ceir.
Canfod awto
I ganfod cofrestriadau yn awtomatig ac olrhain gwladwriaethau cyfoedion, mae angen i chi gysylltu â'r cyfeiriad canlynol: neu
Mewn ymateb, mae'r PBX yn dychwelyd ymateb XML atom:
<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>
Mae llawer o sbwriel yn yr ymateb, felly wrth ragbrosesu rydym yn ei hidlo yn ôl templed XPath: //response/generic[@host]
Yna mae'r hwyl yn dechrau. Er mwyn gweithio gyda chanfod a chreu elfennau'n ddeinamig, rhaid i'r ymateb fod ar ffurf JSON. Nid yw XML yn cael ei gefnogi ar gyfer darganfyddiadau awtomatig.
I drosi XML i JSON, roedd yn rhaid i mi chwarae ychydig gydag ailosod ceir, a gwnes sgript ar ei gyfer yn JS
Pwynt diddorol: yn yr ymateb ATS, mae'r holl baramedrau wedi'u hamgylchynu gan ddyfyniadau sengl, ac ar ôl cymhwyso'r templed //response/generic[@host] cânt eu disodli gan rai dwbl.
I greu elfennau, rydym yn defnyddio newidynnau o'r ymateb XML (JSON bellach).
Cofrestrfa SIP
Ar gyfer cofrestriadau sipian rydym yn defnyddio tri newidyn: enw defnyddiwr, llu, porthladd. Roeddwn yn hapus gydag enw'r elfen [e-bost wedi'i warchod]: 5060, Nid wyf wedi dod o hyd i unrhyw sefyllfaoedd lle mae angen i chi ddefnyddio pob un o'r pum newidyn.
Y brif elfen sy'n derbyn gwybodaeth am bob cofrestriad, Seren - AMI SIPshowregistry. Unwaith y funud mae'n gwneud cais GET i , ac ar ôl hynny mae'r data ymateb XML yn cael ei drosglwyddo i'r holl elfennau dibynnol i'w dosrannu. Ar gyfer pob cofrestriad dwi'n creu elfen sy'n ddibynnol arno. Mae hyn yn gyfleus oherwydd ein bod yn derbyn y wybodaeth ddiweddaraf mewn un cais, ac nid ar gyfer pob cais ar wahân. Mae gan y gweithrediad hwn anfantais sylweddol - y llwyth ar y prosesydd.
Wrth brofi hyd at 100 o elfennau dibynnol, ni sylwais ar y llwyth, ond gyda 1700 o elfennau, rhoddodd hyn lwyth amlwg o 15 eiliad ar y prosesydd. Cadwch hyn mewn cof os oes gennych chi nifer fawr o elfennau dibynnol.
Fel opsiwn i “ledaenu” y llwyth neu osod gwahanol amleddau pleidleisio ar gyfer elfen, gallwch symud y rhesymeg prosesu i bob elfen ar wahân.
Nid wyf yn storio'r wybodaeth a dderbyniwyd yn y brif elfen. Yn gyntaf, nid wyf yn gweld yr angen am hyn, ac yn ail, os yw'r ymateb yn fwy na 64K, yna mae Zabbix yn ei dorri i ffwrdd.
Gan ein bod yn defnyddio ymateb XML llawn ar gyfer yr elfen ddibynnol, mae angen i ni gael gwerth yr elfen hon wrth ragbrosesu. Trwy XPath mae'n cael ei wneud fel hyn:
string(//response/generic[@event="RegistryEntry"][@username="{#SIP_REGISTRY_USERNAME}"][@host="{#SIP_REGISTRY_HOST}"][@port="{#SIP_REGISTRY_PORT}"]/@ cyflwr)
Ar gyfer statws cofrestru, ni ddefnyddiais statws testun, ond fe'u trosglwyddais yn ffurf rifol gan ddefnyddio JavaScript:
switch(value) {
case 'Registered':
return 1;
case 'Unregistered':
return 0;
default:
return -1;
}
Cyfoedion SIP
Trwy gydweddiad â chofrestriadau SIP, mae prif elfen o gofrestrfa Asterisk - AMI SIPshow, y mae rhai dibynnol yn cael eu hychwanegu ati.
Mae hyn yn creu dwy elfen ddibynnol:
- Statws cyfoedion ar ffurf testun
- Amser ymateb dyfais - os yw'r statws yn iawn, yna ysgrifennir amser ymateb y ddyfais, fel arall "-1"
Mae'r llwybr i'r elfen ei hun ychydig yn symlach XPath:
llinyn (//response/generic[@objectname="{#SIP_PEER_OBEJECTNAME}"]/@status)
Ar gyfer yr ail elfen defnyddiais JavaScript i wahanu amser ymateb o'r statws cyfoedion, gan eu bod yn cael eu storio gyda'i gilydd:
if(value.substring(0,2) == 'OK'){
return value.match(/(d+)/gm);
}
else {
return -1;
}Casgliad
Gall datrysiad tu allan i'r bocs fod yn gymhleth ac nid yw'n glir ar unwaith. Cynyddu hyblygrwydd a hygludedd rhwng systemau gwahanol
Integreiddiad hapus a hawdd pawb! Templed a chyfarwyddiadau ar gyfer sefydlu .
Ffynhonnell: hab.com