Когато правя решение за клиент, възникнаха 2 задачи, които исках да реша красиво и с обикновена Zabbix функционалност.
Задача 1 Проследяване на текущата версия на фърмуера на рутери Mikrotik.
Задачата се решава лесно - чрез добавяне на агент към HTTP шаблона. Агентът получава текущата версия от сайта на Mikrotik, а тригерът сравнява текущата версия с текущата и издава предупреждение в случай на несъответствие.
Когато имате 10 рутера, такъв алгоритъм не е критичен, но какво да правите с 3000 рутера? Изпращане на 3000 заявки до сървъра? Разбира се, такава схема ще работи, но самата идея за 3000 заявки не ме устройваше, исках да намеря друго решение. Освен това все още имаше недостатък в такъв алгоритъм: другата страна може да преброи такъв брой заявки от един IP за DoS атака, те могат просто да го забранят.
Задача 2 Използване на сесия за оторизация в различни HTTP агенти.
Когато агент трябва да получи информация от "затворени" страници чрез HTTP, е необходима бисквитка за оторизация. За да направите това, обикновено има стандартен формуляр за оторизация с двойка „вход / парола“ и настройка на идентификатора на сесията в бисквитката.
Но има проблем, невъзможно е да се осъществи достъп до данните на друг елемент от един елемент на HTTP агент, за да се замени тази стойност в заглавката.
Има и "Уеб скрипт", той има друго ограничение, не ви позволява да получите съдържание за анализ и по-нататъшно запазване. Можете само да проверявате за наличието на необходимите променливи на страниците или да предавате предварително получени променливи между стъпките на уеб скрипта.
След като помислих малко за тези задачи, реших да използвам макроси, които са перфектно видими във всяка част на системата за наблюдение: в шаблони, хостове, тригери или елементи. И можете да актуализирате макроси чрез API на уеб интерфейса.
Zabbix има добра и подробна API документация. За обмен на данни чрез api се използва форматът на данните Json. Подробности можете да намерите в .
Последователността от действия за получаване на необходимите ни данни и записването им в макрос е показана на диаграмата по-долу.
Стъпка 1
Първата стъпка може да се състои от едно действие или множество действия. Цялата основна логика е заложена в първите стъпки, а последните 3 стъпки са основните.
В моя пример първата стъпка беше да получите бисквитки за оторизация на PBX за първата задача. За втората задача получих номера на текущата версия на фърмуера на Mikrotik.
URL на текущите версии на фърмуера на Mikrotik
- - URL адрес на текущата стабилна версия
- — URL адрес на текущата LTS версия
Тези адреси са достъпни от самото оборудване на Mikrotik, когато се получи последната налична версия на фърмуера.
Първата стъпка е напълно индивидуална за всеки случай и логиката на нейната работа може да е различна. Всичко зависи от вашата задача.
Когато работите с уеб скриптове, следете кой метод на отговор ви е необходим. Заглавия HTTP отговор или себе си тело отговор без заглавки?
Ако са необходими бисквитки за оторизация, задайте метода на отговор Заглавия както в случая със звездичка.Ако имате нужда от данни, както в случая с отговора на сървъра 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;
- метод - методът, който се извиква;
- params - параметри, които се предават от метода;
- id е произволен идентификатор на заявка;
- auth - ключ за удостоверяване на потребителя; тъй като все още го нямаме, нека го зададем на нула.
За да работя с API, създадох отделен акаунт с ограничени права. Първо, не е необходимо да давате достъп там, където не е необходимо. И второ, преди версия 5.0 паролата, зададена чрез макроса, можеше да бъде прочетена. Съответно, ако използвате администраторската парола на Zabbix, администраторският акаунт е лесен за кражба.
Това ще бъде особено вярно, когато работите с API чрез скриптове на трети страни и съхранявате идентификационни данни отстрани.
От версия 5.0 има опция за скриване на паролата, записана в макроса.
Когато създавате отделен акаунт за актуализиране на данни чрез API, не забравяйте да проверите дали данните, от които се нуждаете, са достъпни през уеб интерфейса и дали е възможно да ги актуализирате. Не проверих и след това дълго време не можех да разбера защо макросът, от който се нуждаех, не се виждаше в API.
След като получим разрешение в API, продължаваме да получаваме списък с макроси.
Стъпка 3
API не ви позволява да актуализирате макрос на хост по име, първо трябва да получите идентификатора на макроса. Освен това, за да получите списък с макроси за конкретен хост, трябва да знаете идентификатора на този хост и това е допълнителна заявка. Използвайте макроса по подразбиране {HOST ID} в искането не се допуска. Реших да заобиколя ограничението по следния начин:
Създадох локален макрос с ИД на този хост. Откриването на ID на хоста е много лесно от уеб интерфейса.
Отговор със списък на всички макроси на даден хост може да бъде филтриран по шаблон:
regex:{"hostmacroid":"([0-9]+)"[A-z0-9,":]+"{$MIKROTIK_VERSION}"
По този начин получаваме идентификатора на макроса, от който се нуждаем, където MIKROTIK_ВЕРСИЯ е името на макроса, който търсим. В моя случай макросът се търси MIKROTIK_ВЕРСИЯТози, който беше присвоен на хоста.
Самата заявка изглежда така:
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 СТЪПКА - актуализиране на макроса
Сега знаем идентификатора на макроса, който трябва да се актуализира, бисквитката за оторизация или версията на фърмуера на рутера. Можете да актуализирате самия макрос.
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