Zabbix - die uitbreiding van makro-grense

Terwyl ek 'n oplossing vir 'n kliënt gemaak het, het 2 probleme ontstaan ​​wat ek pragtig en met die standaard Zabbix-funksionaliteit wou oplos.

Doelwit 1. Monitering van die huidige firmware weergawe op Mikrotik routers.

Die probleem kan maklik opgelos word deur 'n HTTP-agent by die sjabloon te voeg. Die agent ontvang die huidige weergawe van die Mikrotik-webwerf, en die sneller vergelyk die huidige weergawe met die huidige en, as daar 'n teenstrydigheid is, reik 'n waarskuwing uit.

As jy 10 routers het, is so 'n algoritme nie krities nie, maar wat om te doen met 3000 routers? Stuur 3000 versoeke na die bediener? Natuurlik sou so 'n skema werk, maar die idee van 3000 versoeke het my nie gepas nie, ek wou 'n ander oplossing vind. Daarbenewens was daar steeds 'n nadeel in so 'n algoritme: die ander kant kon so 'n aantal versoeke van een IP as 'n DoS-aanval tel, en hulle kon jou eenvoudig verbied.

Doelwit 2. Gebruik magtigingsessies in verskillende HTTP-agente.

Wanneer jy inligting van "geslote" bladsye via 'n HTTP-agent moet ontvang, benodig jy 'n magtigingskoekie. Om dit te doen, is daar gewoonlik 'n standaard magtigingsvorm met 'n "login/wagwoord"-paar en die sessie-ID in 'n koekie.

Maar daar is 'n probleem: jy kan nie toegang tot die data van 'n ander item vanaf een HTTP-agentitem kry om hierdie waarde in die Kopskrif te vervang nie.

Daar is ook 'n "Web script", dit het 'n ander beperking; dit laat jou nie toe om inhoud te ontvang vir ontleding en verdere stoor nie. U kan slegs die teenwoordigheid van die nodige veranderlikes op die bladsye nagaan of voorheen verkryde veranderlikes tussen die stappe van die webskrif deurgee.

Nadat ek 'n bietjie oor hierdie take gedink het, het ek besluit om makro's te gebruik wat duidelik sigbaar is in enige deel van die moniteringstelsel: in sjablone, gashere, snellers of items. En jy kan makro's opdateer via die webkoppelvlak-API.

Zabbix het goeie en gedetailleerde API-dokumentasie. Om data via API uit te ruil, word die Json-dataformaat gebruik. Jy kan in detail lees in amptelike dokumentasie.

Die volgorde van aksies vir die verkryging van die data wat ons benodig en dit in 'n makro op te teken, word in die diagram hieronder aangebied.

Zabbix - die uitbreiding van makro-grense

Stap 1

Die heel eerste stap kan uit een aksie of baie aksies bestaan. Die eerste stappe bevat al die basiese logika, en die laaste 3 stappe is die belangrikste.

In my voorbeeld het die eerste stap behels die verkryging van 'n magtigingskoekie op die PBX vir die eerste taak. Vir die tweede taak het ek die huidige Mikrotik-firmwareweergawenommer ontvang.

URL van huidige Mikrotik-firmwareweergawes

Hierdie adresse word deur die Mikrotik-toerusting self verkry wanneer dit die nuutste beskikbare firmwareweergawe ontvang.

Die eerste stap is heeltemal individueel vir elke geval en die logika van die werking daarvan kan anders wees. Dit hang alles af van jou taak.

Wanneer jy met webskrifte werk, hou tred met watter metode jy nodig het om 'n antwoord te ontvang. Opskrifte HTTP-reaksie of homself тело antwoord sonder opskrifte?
As jy magtigingskoekies benodig, stel dan die antwoordmetode in Opskrifte soos die geval is met Asterisk.

As jy data benodig, soos die geval is met die reaksie van die mikrotik-bediener, sit Die liggaam reaksie sonder opskrifte.

Stap 2

Kom ons gaan aan na die tweede stap. Ontvangs van 'n magtigingsessie:

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 — weergawe van die JSON-RPC-protokol wat gebruik word;
Zabbix implementeer JSON-RPC weergawe 2.0;

  • metode — die metode wat genoem word;
  • params — parameters wat deur die metode deurgegee word;
  • id - arbitrêre versoek identifiseerder;
  • auth - gebruiker stawing sleutel; Aangesien ons dit nog nie het nie, stel ons dit gelyk aan nul.

Om met die API te werk, het ek 'n aparte rekening met beperkte regte geskep. Eerstens is dit nie nodig om toegang te gee aan plekke waar dit nie nodig is nie. En tweedens, voor weergawe 5.0, kon die wagwoord wat deur 'n makro gespesifiseer is, gelees word. Gevolglik, as u die Zabbix-administrateurwagwoord gebruik, kan die administrasierekening maklik gesteel word.

Dit sal veral waar wees wanneer u met die API werk deur derdeparty-skrifte en geloofsbriewe aan die kant stoor.

Sedert weergawe 5.0 het die opsie verskyn om die wagwoord wat in 'n makro gestoor is, te versteek.

Zabbix - die uitbreiding van makro-grense

Wanneer jy 'n aparte rekening skep om data via die API op te dateer, maak seker dat jy kyk of die data wat jy benodig deur die webkoppelvlak beskikbaar is en of dit opgedateer kan word. Ek het nie nagegaan nie, en toe kon ek vir 'n lang tyd nie verstaan ​​hoekom die makro wat ek nodig gehad het nie deur die API sigbaar was nie.

Zabbix - die uitbreiding van makro-grense

Nadat ons magtiging in die API ontvang het, gaan ons voort om 'n lys makro's te verkry.

Stap 3

Die API-koppelvlak laat nie toe dat 'n gasheermakro op naam opgedateer word nie; om dit te doen, moet jy eers die makro-ID kry. Verder, om 'n lys makro's vir 'n spesifieke gasheer te kry, moet u die ID van hierdie gasheer uitvind, en dit is 'n ekstra versoek. Gebruik standaard makro {HOST.ID} dit is nie moontlik in 'n versoek nie. Ek het besluit om die beperking so te omseil:

Zabbix - die uitbreiding van makro-grense

Ek het 'n plaaslike makro geskep met die ID van hierdie gasheer. Dit is baie maklik om die gasheer-ID van die webkoppelvlak uit te vind.

Die antwoord met 'n lys van alle makro's vir 'n gegewe gasheer kan deur die sjabloon gefiltreer word:

regex:{"hostmacroid":"([0-9]+)"[A-z0-9,":]+"{$MIKROTIK_VERSION}"

Zabbix - die uitbreiding van makro-grense

So, ons kry die ID van die makro wat ons nodig het, waar MIKROTIK_VERSION — die naam van die makro waarna ons soek. In my geval word die makro gesoek MIKROTIK_VERSION, wat aan die gasheer toegewys is.

Die versoek self lyk soos volg:

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
}

veranderlike {sid} verkry in die tweede stap en sal voortdurend gebruik word waar jy met die API-koppelvlak moet werk.

Finale 4 STAP - opdatering van die makro

Nou weet ons die makro-ID wat opgedateer moet word, die magtigingskoekie of die router-firmware-weergawe. Jy kan die makro self opdateer.

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} — die waarde wat in die eerste stap verkry is. In my voorbeeld, die weergawe van die huidige mikrotik-firmware
{hostmacroid} — die waarde is in die derde stap verkry — die ID van die makro wat ons opdateer.

Bevindinge

Die benadering om 'n probleem op te los deur gebruik te maak van standaardfunksies is baie keer moeiliker en neem langer. Veral as jy programmering ken en vinnig die nodige logika in 'n skrif kan sit.

Die ooglopende voordeel van hierdie benadering is die "oordraagbaarheid" van die oplossing tussen verskillende bedieners.

Vir my persoonlik is dit vreemd dat die HTTP-agent nie die vermoë het om toegang tot data van 'n ander item te verkry en dit in die versoekliggaam of opskrifte te vervang nie [ ZBXNEXT-5993].

'N klaargemaakte sjabloon kan wees aflaai op GitHub.

Bron: will.com

Voeg 'n opmerking