В предыдущей статье «Zabbix — расширяем макро границы» я рассказал как получать сессию авторизации и подставлять ее в локальный макрос хоста. В этой статье я расскажу как подружить Zabbix с Asterisk без внешних скриптов и ПО.

Идея «подружить» эти две системы родилась давно, причем без установки дополнительного софта и скриптов. Быстрое гугление выдавало множество вариантов решений, все сводилось к тому, что закиньте скрипты (на пыхе, баше, питоне и т. п.) на сервер, и будет вам счастье. Мне же хотелось реализовать мониторинг «из коробки» — без внешних скриптов и установки дополнительного софта на сервер с мониторингом и АТС.

Провозился я с этим в сумме 4 рабочих дня, но результат стоил того. Работа через интерфейс AMI, низкоуровневое обнаружение, триггеры, а главное, на подключение АТС и все остальные настройки теперь уходит минут 15.

В наличии заббикс 4.4, около 100 штук Астерисков 13 версии. Какие-то АТС идут с веб интерфейсом FreePBX, какие-то с голой консолью, кучей хитростей и интеграцией через диалплан.

Делая решение для клиента, возникло 2 задачи, которые хотелось решить красиво и штатным функционалом Zabbix.

Задача 1. Отслеживание актуальной версии прошивки на роутерах Mikrotik.

Задача решается легко — добавлением в шаблон HTTP агента. Агент получает актуальную версию с сайта Mikrotik, а триггер сравнивает актуальную версию с текущей и в случае расхождения выдает алерт.

Когда у вас 10 роутеров, такой алгоритм не критичен, а что делать с 3000 роутеров? Слать 3000 запросов на сервер? Работать, конечно, такая схема будет, но сама идея 3000 запросов меня не устраивала, хотелось найти другое решение. К тому же, недостаток в подобном алгоритме все-таки был: другая сторона может посчитать такое количество запросов с одного IP за DoS атаку, могут просто забанить.

Задача 2. Использование сессии авторизации в разных HTTP агентах.

Когда через HTTP агент нужно получать информацию с «закрытых» страниц, нужна кука авторизации. Для этого обычно существует стандартная форма авторизации с парой «логин/пароль» и установкой ID сессии в куку.

Но есть проблема, нельзя из одного айтема HTTP агента обратиться к данным другого айтема для подстановки этого значение в Header.

Существует еще «Веб сценарий», у него другое ограничение, он не дает получить контент для анализа и дальнейшего сохранения. Можно только проверить наличие необходимых переменных на страницах или передавать ранее полученные переменные между шагами веб сценария.

Немного поразмыслив над этими задачами, решил использовать макросы, которые отлично видны в любой части системы мониторинга: в шаблонах, хостах, триггерах или айтемах. А обновлять макросы можно через API веб интерфейса.