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

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

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

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

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

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

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

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

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

У Zabbix есть хорошая и подробная документация по API. Для обмена данными по api используется формат данных Json. Подробно можно прочитать в официальной документации.

Последовательность действий получения нужных нам данных и запись их в макрос представлена на схеме ниже.

Шаг 1

Самый первый шаг может состоять из одного действия или множества действий. В первые шаги закладывается вся основная логика, а главными являются последние 3 шага.

В моем примере, на первом шаге выполнялось получение куки авторизации на АТС для первой задачи. Для второй задачи я получал номер текущей версии прошивки Mikrotik.


Первый шаг полностью индивидуален для каждого случая и логика его работы может быть разной. Все зависит от вашей задачи.

При работе с веб сценариями отслеживайте какой метод получение ответа вам нужен. Заголовки HTTP ответа или само тело ответа без заголовков?
Если нужны куки авторизации, то метод ответа ставьте Заголовки как в случае с Asterisk.

Если нужны данные, как в случае с ответом сервера mikrotik, ставьте Тело ответа без заголовков.

Шаг 2

Переходим ко второму шагу. Получение сессии авторизации:

POST http://company.com/zabbix/api_jsonrpc.php HTTP/1.1
Content-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.1
Content-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.1
Content-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.