Задача 1. Отслеживание актуальной версии прошивки на роутерах Mikrotik.
Задача решается легко добавлением в шаблон HTTP агента. Агент получает актуальную версию с сайта Mikrotik, а триггер сравнивает актуальную версию с текущей и в случае расхождения выдает алерт.
Когда у вас 10 роутеров, такой алгоритм не критичен, а что делать с 3000 роутеров? Слать 3000 запросов на сервер? Работать, конечно, такая схема будет, но сама идея 3000 запросов меня не устраивала, хотелось найти другое решение. К тому же, недостаток в подобном алгоритме все-таки был: другая сторона может посчитать такое количество запросов с одного IP за DoS атаку, могут просто забанить.
Задача 2. Использование сессии авторизации в разных HTTP агентах.
Когда через HTTP агент нужно получать информацию с закрытых страниц, нужна кука авторизации. Для этого обычно существует стандартная форма авторизации с парой логин/пароль и установкой ID сессии в куку.
Но есть проблема, нельзя из одного айтема HTTP агента обратиться к данным другого айтема для подстановки этого значение в Header.
Существует еще Веб сценарий, у него другое ограничение, он не дает получить контент для анализа и дальнейшего сохранения. Можно только проверить наличие необходимых переменных на страницах или передавать ранее полученные переменные между шагами веб сценария.
Немного поразмыслив над этими задачами, решил использовать макросы, которые отлично видны в любой части системы мониторинга: в шаблонах, хостах, триггерах или айтемах. А обновлять макросы можно через API веб интерфейса.
У Zabbix есть хорошая и подробная документация по API. Для обмена данными по api используется формат данных Json. Подробно можно прочитать в официальной документации.
Последовательность действий получения нужных нам данных и запись их в макрос представлена на схеме ниже.
Шаг 1
Самый первый шаг может состоять из одного действия или множества действий. В первые шаги закладывается вся основная логика, а главными являются последние 3 шага.
В моем примере, на первом шаге выполнялось получение куки авторизации на АТС для первой задачи. Для второй задачи я получал номер текущей версии прошивки Mikrotik.
- upgrade.mikrotik.com/routeros/LATEST.6 URL адрес актуальной Stable версии
- upgrade.mikrotik.com/routeros/LATEST.6fix URL адрес актуальной LTS версии
К данным адресам обращается само оборудование Mikrotik, при получении последней доступной версии прошивки.
Первый шаг полностью индивидуален для каждого случая и логика его работы может быть разной. Все зависит от вашей задачи.
При работе с веб сценариями отслеживайте какой метод получение ответа вам нужен. Заголовки HTTP ответа или само тело ответа без заголовков?
Если нужны куки авторизации, то метод ответа ставьте Заголовки как в случае с Asterisk.
Если нужны данные, как в случае с ответом сервера mikrotik, ставьте Тело ответа без заголовков.
Шаг 2
Переходим ко второму шагу. Получение сессии авторизации:
POST http://company.com/zabbix/api_jsonrpc.php HTTP/1.1Content-Type: application/json-rpc{ "jsonrpc": "2.0", "method": "user.login", "params": { "user": "Admin" "password": "zabbix" }, "id": 1, "auth": null}
jsonrpc версия протокола JSON-RPC, которая используется;
Zabbix реализует JSON-RPC версии 2.0;
- method метод, который вызывается;
- params параметры, которые передаются методом;
- id произвольный идентификатор запроса;
- auth ключ аутентификации пользователя; та как у нас его еще не имеется, укажем его равным null.
Для работы с API я создал отдельную учетную запись, с ограниченными правами. Во первых не нужно давать доступ туда, куда не нужно. А во вторых до версии 5.0, заданный через макрос пароль, можно было прочитать. Соответственно, если использовать пароль администратора Zabbix, учетку админа легко украсть.
Это особенно будет актуально, когда работаете c API через сторонние скрипты и храните учетные данные на стороне.
С версии 5.0 появилась опция скрыть пароль сохраненный в макросе.
Когда создаете отдельную учетную запись для обновления данных через API, обязательно проверяйте, доступны ли через веб интерфейс нужные вам данные, и возможно ли их обновление. Я не проверил, а потом долго не мог понять, почему по API не виден нужный мне макрос.
После того, как получили авторизацию в API переходим к получению списка макросов.
Шаг 3
API интерфейс не позволяет обновлять макрос хоста по имени, для этого нужно сначала получить ID макроса. Более того, чтобы получить список макросов конкретного хоста, нужно узнать ID этого хоста, а это лишний запрос. Использовать штатный макрос {HOST.ID} в запросе нельзя. Ограничение решил обойти так:
Я создал локальный макрос с ID этого хоста. Узнать ID хоста очень легко из веб интерфейса.
Ответ со списком всех макросов данного хоста можно отфильтровать по шаблону:
regex:{"hostmacroid":"([0-9]+)"[A-z0-9,":]+"{\$MIKROTIK_VERSION}"
Таким образом, мы получаем ID нужного нам макроса, где MIKROTIK_VERSION имя макроса который мы ищем. В моем случае ищется макрос MIKROTIK_VERSION, который был назначен на хост.
Сам запрос выглядит так:
POST http://company.com/zabbix/api_jsonrpc.php HTTP/1.1Content-Type: application/json-rpc{ "jsonrpc":"2.0", "method":"usermacro.get", "params":{ "output":"extend", "hostids":"{$HOST_ID}" }, "auth":"{sid}", "id":1}
Переменная {sid} получена на втором шаге и будет использоваться постоянно, где нужно работать с API интерфейсом.
Финальный 4 ШАГ обновление макроса
Теперь мы знаем ID макроса который нужно обновить, куку авторизации или версию прошивки роутера. Можно обновлять сам макрос.
POST http://company.com/zabbix/api_jsonrpc.php HTTP/1.1Content-Type: application/json-rpc{ "jsonrpc":"2.0", "method":"usermacro.update", "params":{ "hostmacroid":"{hostmacroid}", "value":"{mikrotik_version}" }, "auth":"{sid}", "id":1}
{mikrotik_version} значение полученное на первом шаге. В моем примере версия актуальной прошивки mikrotik
{hostmacroid} значение получили в третьем шаге id макроса, который обновляем.
Выводы
Подход к решению задачи штатным функционалом в разы сложнее и дольше. Особенно если знаешь программирование и можешь быстро накидать нужную логику в скрипте.
Очевидным плюсом данного подхода является переносимость решения между разными серверами.
Лично для меня является странным отсутствие возможности обращаться в HTTP агенте к данным другого айтема и подстановка их в тело запроса или заголовки [ ZBXNEXT-5993].
Готовый шаблон можно скачать на GitHub.