В предишна статия Казах ви как да получите сесия за оторизация и да я замените в макрос на локален хост. В тази статия ще ви кажа как да свържете Zabbix със Asterisk без външни скриптове и софтуер.
Идеята за „сприятеляване“ на тези две системи се роди отдавна, без инсталиране на допълнителен софтуер или скриптове. Бързото гугълване даде много възможни решения, всичко се свеждаше до факта, че качете скриптовете (на Pyha, Bash, Python и т.н.) на сървъра и ще бъдете щастливи. Исках да внедря мониторинг „извън кутията“ - без външни скриптове и инсталиране на допълнителен софтуер на сървъра с мониторинг и PBX.
Прекарах общо 4 работни дни с това, но резултатът си заслужаваше. Работата през AMI интерфейса, откриването на ниско ниво, тригерите и най-важното свързването на PBX и всички други настройки вече отнема около 15 минути.
Zabbix 4.4 е наличен, около 100 броя Asterisk версия 13. Някои телефонни централи идват с уеб интерфейс FreePBX, някои с чиста конзола, куп трикове и интеграция чрез диалплан.
Получаване на данни от телефонна централа
Първата и основна точка, която трябва да бъде решена, е получаването на данни за партньори и SIP регистрации. За тази цел телефонната централа има AGI, AMI, ARI и SSH конзолни интерфейси. По обясними причини не взех предвид допълнителни модули.
Първо трябва да разберем какво представляват тези agi, ami, ari...
- AGI - използване на скриптове в диалплана. Използва се главно за управление на разговори.
- AMI - може да предостави цялата необходима информация, работи през порт 5038, подобно на Telnet. Устройва ни!
- ARI - модерен, модерен, JSON. Има много възможности, форматът на данните е разбираем за Zabbix, но за мен няма основно нещо: не можете да контролирате регистрацията на sip. Друг недостатък е, че за пиърите има само две състояния онлайн/офлайн, въпреки че има повече състояния и е полезно да се вземат предвид при диагностициране.
- SSH може да прави всичко, но понякога не е позволено поради „съображения за сигурност“. Съображенията може да са различни, няма да навлизам в тях.
Въпреки това, с всичките си недостатъци, ARI покрива 90% от всички нужди за мониторинг.
Zabbix и Telnet - моето разочарование
Познавам AMI добре, по едно време внедрих проследяване на загуби в разговори с разделяне по отдалечени офиси, управление на разговори и т.н. С Telnet всичко също е много ясно: отворете връзката, изпратете командите и прочетете отговора. Така и направих, но резултатът ме разочарова.
Telnet в Zabbix не е същият като в конзолата на Linux, той е малко по-опростен и пригоден за стандартна авторизация като вход/парола. Ако логиката за оторизация е различна и няма заявка за двойка потребителско име/парола, възниква грешка. След безполезни опити да се заобиколи изискването за оторизация, беше полезно да се погледне изходният код на модула Telnet.
Разбрах, че докато няма традиционно искане за влизане и парола, няма да продължа напред. Просто за забавление премахнах всичко свързано с авторизацията от кода и сглобих всичко отново. Върши работа! Но не отговаря на изискванията. Продължавай…
Да се върнем към търсенето
Прочетох отново документацията на ARI, проведох допълнителни тестове - тук няма регистрации на глътка. Има пиршества, има разговори, има бричове, но няма регистрации. По някое време дори си помислих дали наистина имаме нужда от регистрация на лешояди?
По забавно съвпадение в този момент пристига друга заявка от потребителя, с проблем с изходящите повиквания. Проблемът беше, че sip регистрацията замръзваше и беше решен чрез просто рестартиране на модула.
asterisk -rx "sip reload"Би било страхотно да има достъп до AMI през мрежата: това ще реши всички проблеми, помислих си. Започвам да ровя в тази посока и буквално първият ред за търсене води до официалната документация на Asterisk, където пише, че има опция за моите задачи уеб активиран във файл /etc/asterisk/manager.conf, което трябва да бъде зададено на ДА в раздела [общ]
След това чрез обикновена уеб заявка на формата получаваме цялата необходима информация.
Когато използвате интерфейса FreePBX, не можете да активирате тази опция чрез уеб; трябва да я активирате през конзолата, като направите промени във файла manager.conf. FreePBX не го изтрива, когато се правят промени в конфигурацията през мрежата.
Работил съм с различни видове интеграции на Asterisk от дълго време, но никога не съм виждал тази функция да се споменава никъде. Бях изненадан, че никой не описва този метод за взаимодействие с телефонната централа. Дори беше особено полезно да се търси информация по тази тема: практически няма нищо или е използвана за съвсем други задачи.
WEB AMI - какъв звяр?
Добавяне на опция уеб активиран да подаде мениджър.конф осигури пълен достъп до управлението на ATS чрез уеб. Всички команди, достъпни чрез обикновен AMI, вече са в мрежата, можете да слушате събития от PBX чрез гнездо. Принципът на работа не се различава от конзолата AMI. След като активирате тази опция, можете да се свържете с телефонната централа на следните адреси:
— уеб страница с прост интерфейс за тестване и ръчно изпращане на заявки. Всички отговори са форматирани в четим HTML. Не е много подходящ за наблюдение.
— само текстов изход, формат, подобен на конзолния AMI
- само текстов изход, в XML формат. Устройва ни!
Тогава си помислих: „Това е решението! Сега всичко ще е готово! Easy-peezy lemon squeezey”, но беше твърде рано да се радваме. За да получим информацията, от която се нуждаем, е достатъчно да използваме GET заявка с необходимото действие действие, който в отговор връща xml със списък на всички регистрации и техния статус. Всичко това е страхотно, но имате нужда от разрешение, за да запомните сесията от бисквитката. Когато тествате в браузъра, не мислите за този процес.
Процес на оторизация
Първо адресираме адреса , в отговор сървърът ни изпраща бисквитка със сесията за оторизация. Ето как изглежда една 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: 1Отговор:
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>
За да работите там трябва mansession_id="6f5de42c“, т.е. самата бисквитка за оторизация.
Съдържание, което просто трябва да проверите за отговора "Удостоверяването е прието" След това за всички повиквания към PBX сървъра ще трябва да добавим бисквитка за оторизация към заявката.
https://ats:8089/mxml?action=SIPpeers
Host: ats:8089
Connection: close
Cookie: mansession_id="6f5de42c"Прочетете как да получите бисквитка за оторизация и да я използвате в други заявки тук: “»
За да създам проследяващи елементи в Zabbix, ще използвам автоматично откриване.
Автоматично откриване
За автоматично откриване на регистрации и проследяване на партньорски състояния, трябва да се свържете със следния адрес: или
В отговор PBX ни връща XML отговор:
<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>
Има много боклук в отговора, така че при предварителната обработка го филтрираме по шаблон XPath: //отговор/генеричен[@host]
Тогава започва забавлението. За да работи с откриване и динамично създаване на елементи, отговорът трябва да бъде във формат JSON. XML не се поддържа за автоматично откриване.
За да конвертирам XML в JSON, трябваше да си поиграя малко с автоматичната замяна, за което направих скрипт в JS
Интересен момент: в ATS отговора всички параметри са заобиколени от единични кавички и след прилагане на шаблона //отговор/генеричен[@host] те се заменят с двойни.
За да създадем елементи, използваме променливи от XML отговора (сега JSON).
SIP регистър
За sip регистрации използваме три променливи: потребителско име, домакин, порт. Зарадвах се от името на елемента [имейл защитен]: 5060, не открих ситуации, в които трябва да използвате всичките пет променливи.
Основният елемент, който получава информация за всички регистрации, Звездичка - AMI SIPshowregistry. Веднъж в минута прави GET заявка до , след което отговорните XML данни се предават на всички зависими елементи за анализ. За всяка регистрация създавам зависим от нея елемент. Това е удобно, защото получаваме актуална информация в една заявка, а не за всяка заявка поотделно. Това изпълнение има значителен недостатък - натоварването на процесора.
При тестване на до 100 зависими елемента не забелязах натоварването, но при 1700 елемента това даде забележимо 15 секундно натоварване на процесора. Имайте това предвид, ако имате голям брой зависими елементи.
Като опция за „разпределяне“ на натоварването или задаване на различни честоти на запитване за даден елемент, можете да преместите логиката на обработка към всеки елемент поотделно.
Не съхранявам получената информация в основния елемент. Първо, не виждам нужда от това, и второ, ако отговорът е повече от 64K, тогава Zabbix го прекъсва.
Тъй като използваме пълен XML отговор за зависимия елемент, трябва да получим стойността на този елемент в предварителната обработка. През XPath прави се така:
низ(//response/generic[@event="RegistryEntry"][@username="{#SIP_REGISTRY_USERNAME}"][@host="{#SIP_REGISTRY_HOST}"][@port="{#SIP_REGISTRY_PORT}"]/@ състояние)
За статуси на регистрация не използвах текстови статуси, а ги преобразувах в цифрова форма с помощта на JavaScript:
switch(value) {
case 'Registered':
return 1;
case 'Unregistered':
return 0;
default:
return -1;
}
SIP Peers
По аналогия с SIP регистрациите, има основен елемент на Asterisk - AMI SIPshowregistry, към който се добавят зависими.
Това създава два зависими елемента:
- Състояние на партньор в текстова форма
- Време за реакция на устройството - ако състоянието е ОК, тогава се изписва времето за реакция на устройството, в противен случай “-1”
Пътят до самия елемент е малко по-прост XPath:
низ (//response/generic[@objectname="{#SIP_PEER_OBEJECTNAME}"]/@status)
За втория елемент използвах JavaScript за разделяне време за реакция от статуса на партньор, тъй като те се съхраняват заедно:
if(value.substring(0,2) == 'OK'){
return value.match(/(d+)/gm);
}
else {
return -1;
}Заключение
Едно готово решение може да бъде сложно и неясно веднага. Увеличава гъвкавостта и преносимостта между различни системи
Честита и лесна интеграция на всички! Шаблон и инструкции за настройка .
Източник: www.habr.com