Делая решение для клиента, возникло 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.
URL актуальных версий прошивок Mikrotik
- — URL адрес актуальной Stable версии
- — URL адрес актуальной LTS версии
К данным адресам обращается само оборудование 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 агенте к данным другого айтема и подстановка их в тело запроса или заголовки [ ].
Готовый шаблон можно .
Источник: habr.com