Делая решение для клиента, возникло 2 задачи, которые хотелось решить красиво и штатным функционалом Zabbix.
אַרבעט 1. Отслеживание актуальной версии прошивки на роутерах Mikrotik.
Задача решается легко — добавлением в шаблон HTTP агента. Агент получает актуальную версию с сайта Mikrotik, а триггер сравнивает актуальную версию с текущей и в случае расхождения выдает алерт.
Когда у вас 10 роутеров, такой алгоритм не критичен, а что делать с 3000 роутеров? Слать 3000 запросов на сервер? Работать, конечно, такая схема будет, но сама идея 3000 запросов меня не устраивала, хотелось найти другое решение. К тому же, недостаток в подобном алгоритме все-таки был: другая сторона может посчитать такое количество запросов с одного IP за DoS атаку, могут просто забанить.
אַרבעט 2. Использование сессии авторизации в разных HTTP агентах.
Когда через HTTP агент нужно получать информацию с «закрытых» страниц, нужна кука авторизации. Для этого обычно существует стандартная форма авторизации с парой «логин/пароль» и установкой ID сессии в куку.
Но есть проблема, нельзя из одного айтема HTTP агента обратиться к данным другого айтема для подстановки этого значение в Header.
Существует еще «Веб сценарий», у него другое ограничение, он не дает получить контент для анализа и дальнейшего сохранения. Можно только проверить наличие необходимых переменных на страницах или передавать ранее полученные переменные между шагами веб сценария.
Немного поразмыслив над этими задачами, решил использовать макросы, которые отлично видны в любой части системы мониторинга: в шаблонах, хостах, триггерах или айтемах. А обновлять макросы можно через API веб интерфейса.
У Zabbix есть хорошая и подробная документация по API. Для обмена данными по api используется формат данных Json. Подробно можно прочитать в .
Последовательность действий получения нужных нам данных и запись их в макрос представлена на схеме ниже.
שריט קסנומקס
Самый первый шаг может состоять из одного действия или множества действий. В первые шаги закладывается вся основная логика, а главными являются последние 3 шага.
В моем примере, на первом шаге выполнялось получение куки авторизации на АТС для первой задачи. Для второй задачи я получал номер текущей версии прошивки Mikrotik.
URL актуальных версий прошивок Mikrotik
- — URL адрес актуальной Stable версии
- — URL адрес актуальной LTS версии
К данным адресам обращается само оборудование Mikrotik, при получении последней доступной версии прошивки.
Первый шаг полностью индивидуален для каждого случая и логика его работы может быть разной. Все зависит от вашей задачи.
При работе с веб сценариями отслеживайте какой метод получение ответа вам нужен. טיטלען HTTP ответа или само тело ответа без заголовков?
Если нужны куки авторизации, то метод ответа ставьте טיטלען как в случае с Asterisk.Если нужны данные, как в случае с ответом сервера mikrotik, ставьте גוף ответа без заголовков.
שריט קסנומקס
Переходим ко второму шагу. Получение сессии авторизации:
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 переходим к получению списка макросов.
שריט קסנומקס
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 агенте к данным другого айтема и подстановка их в тело запроса или заголовки [ ].
Готовый шаблон можно .
מקור: www.habr.com