🥇Zabbix — разширете макро границите

При разработка на решение за клиента възникнаха две задачи, които искахме да решим по красив начин с функции на Zabbix.

Задача 1. Проследяване на актуалната версия на фърмуера на рутерите Mikrotik.

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

Когато имате 10 рутера, този алгоритъм не е критичен, но какво да правим с 3000 рутера? Да изпращаме 3000 заявки на сървъра? Работи, разбира се, но самата идея за 3000 заявки не ми харесваше и исках да намеря друго решение. Освен това, недостатък на подобен алгоритъм е, че другата страна може да прецени такова количество заявки от един IP за атака DoS и просто да блокира.

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

Когато чрез HTTP агента трябва да получим информация от „затворени“ страници, е необходима бисквитка за авторизация. За това обикновено съществува стандартна форма за авторизация с двойка „логин/парола“ и настройка на ID на сесията в бисквитката.

Но има проблем, не може от един артикул на HTTP агента да се обърне към данните на друг артикул, за да се замести тази стойност в Header.

Съществува и „Веб сценарий“, който има друго ограничение — той не предоставя съдържание за анализ и по-нататъшно запазване. Можете само да проверите наличието на необходимите променливи на страниците или да предавате вече получени променливи между стъпките на уеб сценария.

След като малко помислих за тези задачи, реших да използвам макроси, които са отлично видими във всяка част на системата за мониторинг: в шаблони, хостове, тригери или артикули. А обновяването на макроси може да се извършва чрез API на уеб интерфейса.

Zabbix разполага с добра и подробна документация по API. За обмен на данни по API се използва формат на данни JSON. Подробно можете да прочетете в официалната документация.

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

Стъпка 1

Първата стъпка може да се състои от едно действие или от множество действия. В първите стъпки се заковава всичката основна логика, а основни са последните три стъпки.

В моя пример, на първата стъпка се извърши получаването на бисквитка за авторизация на АТС за първата задача. За втората задача получавам номера на текущата версия на фърмуера на Mikrotik.

URL на актуалните версии на фърмуера на 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.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, сметката на администратора лесно може да бъде открадната.

Това ще бъде особено актуално, когато работите с 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.

Източник: habr.com