Ved at lave en løsning til en klient opstod der 2 opgaver, som jeg ville løse smukt og med almindelig Zabbix funktionalitet.
Opgave 1. Sporing af den aktuelle firmwareversion på Mikrotik-routere.
Opgaven løses nemt - ved at tilføje en agent til HTTP-skabelonen. Agenten modtager den aktuelle version fra Mikrotik-webstedet, og udløseren sammenligner den aktuelle version med den nuværende og udsender en advarsel i tilfælde af uoverensstemmelse.
Når man har 10 routere, er sådan en algoritme ikke kritisk, men hvad skal man gøre med 3000 routere? Sende 3000 anmodninger til serveren? Selvfølgelig vil sådan en ordning fungere, men selve ideen med 3000 anmodninger passede ikke mig, jeg ville finde en anden løsning. Derudover var der stadig en ulempe ved sådan en algoritme: den anden side kan tælle så mange anmodninger fra én IP til et DoS-angreb, de kan simpelthen forbyde det.
Opgave 2. Brug af en godkendelsessession i forskellige HTTP-agenter.
Når en agent skal modtage information fra "lukkede" sider via HTTP, er en autorisationscookie nødvendig. For at gøre dette er der normalt en standard autorisationsformular med et "login / password"-par og indstilling af sessions-id'et i cookien.
Men der er et problem, det er umuligt at få adgang til data for et andet element fra et HTTP-agentelement for at erstatte denne værdi i Headeren.
Der er også et "Web script", det har en anden begrænsning, det giver dig ikke mulighed for at få indhold til analyse og yderligere lagring. Du kan kun kontrollere tilstedeværelsen af de nødvendige variabler på siderne eller sende tidligere modtagne variabler mellem webscript-trin.
Efter at have tænkt lidt over disse opgaver besluttede jeg at bruge makroer, der er perfekt synlige i enhver del af overvågningssystemet: i skabeloner, værter, triggere eller elementer. Og du kan opdatere makroer via webinterface-API'en.
Zabbix har god og detaljeret API dokumentation. Til dataudveksling via api bruges Json-dataformatet. Detaljer kan findes i .
Rækkefølgen af handlinger for at opnå de data, vi har brug for, og optage dem i en makro, er vist i diagrammet nedenfor.
Trin 1
Det allerførste trin kan bestå af en enkelt handling eller flere handlinger. Al hovedlogikken er lagt i de første trin, og de sidste 3 trin er de vigtigste.
I mit eksempel var det første skridt at få autorisationscookies på PBX'en til den første opgave. Til den anden opgave fik jeg nummeret på den aktuelle version af Mikrotik-firmwaren.
URL til aktuelle versioner af Mikrotik-firmware
- - URL-adresse på den aktuelle stabile version
- — URL-adresse for den aktuelle LTS-version
Disse adresser tilgås af Mikrotik-udstyret selv, når den seneste tilgængelige firmwareversion modtages.
Det første trin er helt individuelt for hver sag, og logikken i dets arbejde kan være anderledes. Det hele afhænger af din opgave.
Når du arbejder med webscripting, skal du holde styr på, hvilken responsmetode du har brug for. Titler HTTP-svar eller selv тело svar uden overskrifter?
Hvis autorisationscookies er nødvendige, skal du indstille svarmetoden Titler som i tilfældet med Asterisk.Hvis du har brug for data, som i tilfældet med mikrotik-serversvaret, læg krop svar uden overskrifter.
Trin 2
Lad os gå videre til andet trin. Sådan får du en godkendelsessession:
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 er den version af JSON-RPC-protokollen, der bliver brugt;
Zabbix implementerer JSON-RPC version 2.0;
- metode - metoden der kaldes;
- params - parametre, der overføres af metoden;
- id er en vilkårlig anmodnings-id;
- auth - brugergodkendelsesnøgle; da vi ikke har det endnu, lad os sætte det til null.
For at arbejde med API'en oprettede jeg en separat konto med begrænsede rettigheder. For det første behøver du ikke give adgang til, hvor du ikke skal. Og for det andet, før version 5.0, kunne adgangskoden, der var sat gennem makroen, læses. Hvis du bruger Zabbix-administratoradgangskoden, er administratorkontoen derfor let at stjæle.
Dette vil især være tilfældet, når du arbejder med API gennem tredjepartsscripts og gemmer legitimationsoplysninger på siden.
Siden version 5.0 er der mulighed for at skjule adgangskoden, der er gemt i makroen.
Når du opretter en separat konto til opdatering af data via API'et, skal du sørge for at tjekke, om de data, du har brug for, er tilgængelige via webgrænsefladen, og om det er muligt at opdatere dem. Jeg tjekkede ikke, og så kunne jeg i lang tid ikke forstå, hvorfor den makro, jeg havde brug for, ikke var synlig i API'et.
Efter at vi har modtaget autorisation i API'et, fortsætter vi med at få en liste over makroer.
Trin 3
API'en tillader dig ikke at opdatere en værtsmakro ved navn, du skal først hente makro-id'et. Desuden, for at få en liste over makroer for en bestemt vært, skal du kende denne værts ID, og dette er en ekstra anmodning. Brug standard makro {HOST ID} i anmodningen er ikke tilladt. Jeg besluttede at omgå begrænsningen sådan her:
Jeg oprettede en lokal makro med denne værts ID. Det er meget nemt at finde ud af værts-id'et fra webgrænsefladen.
Et svar med en liste over alle makroer på en given vært kan filtreres efter et mønster:
regex:{"hostmacroid":"([0-9]+)"[A-z0-9,":]+"{$MIKROTIK_VERSION}"
Således får vi ID'et for den makro, vi skal bruge, hvor MIKROTIK_VERSION er navnet på den makro, vi leder efter. I mit tilfælde søges makroen MIKROTIK_VERSIONDet, der blev tildelt værten.
Selve anmodningen ser således ud:
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
}
Variabel {sid} opnået i andet trin og vil blive brugt konstant, hvor du skal arbejde med API-grænsefladen.
Sidste 4 TRIN - opdatering af makroen
Nu kender vi makro-id'et, der skal opdateres, autorisationscookien eller firmwareversionen af routeren. Du kan opdatere selve makroen.
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} er værdien opnået i det første trin. I mit eksempel versionen af den aktuelle mikrotik-firmware
{hostmacroid} - værdien blev opnået i det tredje trin - id'et for den makro, som vi opdaterer.
Fund
Tilgangen til at løse problemet med standardfunktionalitet er meget mere kompliceret og længere. Især hvis du kan programmering og hurtigt kan tilføje den nødvendige logik i scriptet.
Den åbenlyse fordel ved denne tilgang er løsningens "portabilitet" mellem forskellige servere.
For mig personligt er det mærkeligt, at HTTP-agenten ikke kan få adgang til dataene for et andet element og erstatte dem i anmodningens brødtekst eller overskrifter [ ].
Den færdige skabelon kan .
Kilde: www.habr.com