Робячы рашэнне для кліента, узнікла 2 задачы, якія хацелася вырашыць прыгожа і штатным функцыяналам Zabbix.
Задача 1. Адсочванне актуальнай версіі прашыўкі на роўтэрах Mikrotik.
Задача вырашаецца лёгка - даданнем у шаблон HTTP агента. Агент атрымлівае актуальную версію з сайта Mikrotik, а трыгер параўноўвае актуальную версію з бягучай і ў выпадку разыходжання выдае алерт.
Калі ў вас 10 роўтэраў, такі алгарытм не крытычны, а што рабіць з 3000 роўтэраў? Адправіць 3000 запытаў на сервер? Працаваць, вядома, такая схема будзе, але сама ідэя 3000 запытаў мяне не задавальняла, хацелася знайсці іншае рашэнне. Да таго ж, недахоп у падобным алгарытме ўсёткі быў: іншы бок можа палічыць такую колькасць запытаў з аднаго IP за DoS напад, могуць проста забаніць.
Задача 2. Выкарыстанне сесіі аўтарызацыі ў розных HTTP агентах.
Калі праз HTTP агент трэба атрымліваць інфармацыю з "закрытых" старонак, патрэбна кука аўтарызацыі. Для гэтага звычайна існуе стандартная форма аўтарызацыі з парай «лагін/пароль» і ўсталёўкай ID сесіі ў куку.
Але ёсць праблема, нельга з аднаго HTMA агента айцему звярнуцца да дадзеных іншага АЙТЭМ для падстаноўкі гэтага значэнне ў 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, улік адміністратара лёгка выкрасці.
Гэта асабліва будзе актуальна, калі працуеце з 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