Кога правев решение за клиент, се појавија 2 задачи кои сакав да ги решам убаво и со редовна функционалност на Zabbix.
Цел 1. Следење на тековната верзија на фирмверот на рутерите на Mikrotik.
Задачата се решава лесно - со додавање агент во шаблонот HTTP. Агентот ја добива тековната верзија од веб-страницата на Микротик, а активирањето ја споредува тековната верзија со тековната и издава предупредување во случај на несовпаѓање.
Кога имате 10 рутери, таков алгоритам не е критичен, но што да правите со 3000 рутери? Испрати 3000 барања до серверот? Се разбира, таквата шема ќе функционира, но самата идеја за 3000 барања не ми одговараше, сакав да најдам друго решение. Покрај тоа, сè уште имаше недостаток во таков алгоритам: другата страна може да брои таков број на барања од една IP за DoS напад, тие едноставно можат да го забранат.
Цел 2. Користење на сесија за авторизација во различни HTTP агенти.
Кога агентот треба да прима информации од „затворени“ страници преку HTTP, потребно е колаче за авторизација. За да го направите ова, обично постои стандарден формулар за овластување со пар „најава / лозинка“ и поставување на ID на сесијата во колачето.
Но, има проблем, невозможно е да се пристапи до податоците на друга ставка од една ставка на агент на 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;
- метод - методот што се нарекува;
- параметри - параметри кои се пренесуваат со методот;
- id е произволен идентификатор на барање;
- автентикација - клуч за автентикација на корисникот; бидејќи сè уште го немаме, да го поставиме на null.
За да работам со API, создадов посебна сметка со ограничени права. Прво, не треба да давате пристап до таму каде што не треба. И второ, пред верзијата 5.0, лозинката поставена преку макрото можеше да се прочита. Според тоа, ако ја користите администраторската лозинка на Zabbix, администраторската сметка е лесно да се украде.
Ова ќе биде особено точно кога работите со API преку скрипти од трети страни и складирање на ингеренциите на страна.
Од верзијата 5.0 постои опција да се скрие лозинката зачувана во макрото.
Кога креирате посебна сметка за ажурирање податоци преку API, проверете дали податоците што ви се потребни се достапни преку веб-интерфејсот и дали е можно да се ажурираат. Не проверив, а потоа долго време не можев да разберам зошто макрото што ми требаше не беше видливо во API.
Откако добивме овластување во API, продолжуваме да добиваме листа на макроа.
Чекор 3
API не ви дозволува да ажурирате макро на домаќинот по име, прво мора да го добиете макро ID. Покрај тоа, за да добиете листа на макроа за одреден хост, треба да го знаете ID на овој домаќин, а ова е дополнително барање. Користете стандардно макро {ХОСТ 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
{хостмакроид} - вредноста е добиена во третиот чекор - id на макрото што го ажурираме.
Наоди
Пристапот за решавање на проблемот со стандардна функционалност е многу покомплициран и подолг. Особено ако знаете програмирање и можете брзо да ја додадете потребната логика во скриптата.
Очигледната предност на овој пристап е „преносливоста“ на решението помеѓу различни сервери.
За мене лично, чудно е што агентот HTTP не може да пристапи до податоците на друга ставка и да ги замени во телото на барањето или заглавијата [ ].
Готовиот шаблон може .
Извор: www.habr.com