Når jeg lavede en løsning til kunden, opstod der to opgaver, som jeg gerne ville løse elegant med standardfunktionaliteten i Zabbix.
Opgave 1. Sporing af den aktuelle firmwareversion på Mikrotik-routere.
Opgaven løses nemt ved at tilføje til HTTP-agentens skabelon. Agenten henter den aktuelle version fra Mikrotik's hjemmeside, og triggeren sammenligner den aktuelle version med den nuværende og giver en alert i tilfælde af uoverensstemmelse.
Når du har 10 routere, er sådan en algoritme ikke kritisk, men hvad med 3000 routere? Skal man sende 3000 forespørgsler til serveren? Det kan selvfølgelig fungere, men selve ideen om 3000 forespørgsler tilfredsstiller mig ikke, så jeg ville finde en anden løsning. Desuden var der en ulempe ved den slags algoritme: den anden side kan opfatte et så stort antal forespørgsler fra én IP som en DoS-attack, og de kan simpelthen blokere det.
Opgave 2. Brug af autentificeringssessionen i forskellige HTTP-agenter.
Når der gennem HTTP-agenten skal hentes information fra 'lukkede' sider, er en autentificeringscookie nødvendig. Normalt findes der en standardformular til autentificering med parret 'login/password' og opsætning af session ID i cookien.
Men der er et problem: man kan ikke fra én HTTP-agent element tilgå data fra et andet element for at indsætte denne værdi i Header.
Der er også 'Web-script', som har en anden begrænsning; det tillader ikke at få indhold til analyse og efterfølgende opbevaring. Man kan kun kontrollere tilstedeværelsen af de nødvendige variable på siderne eller overføre tidligere indsamlede variable mellem trinene i web-scriptet.
Efter lidt overvejelse over disse opgaver besluttede jeg at bruge makroer, som er tydeligt synlige i enhver del af overvågningssystemet: i skabeloner, værter, triggere eller elementer. Og makroer kan opdateres via API-webgrænsefladen.
Zabbix har god og detaljeret dokumentation om API. Dataudveksling via API bruger JSON dataformatet. Læs mere detaljeret i .
Sekvensen af handlinger for at få de data, vi har brug for, og gemme dem i makroen, vises i diagrammet nedenfor.
Trin 1
Det første skridt kan bestå af én handling eller mange handlinger. I de første skridt lægges al den grundlæggende logik, og de sidste 3 skridt er de mest centrale.
I mit eksempel, blev autentificeringscookien hentet fra PBX i det første skridt for den første opgave. For den anden opgave fik jeg nummeret på den aktuelle firmwareversion af Mikrotik.
URL for the latest Mikrotik firmware versions
- — URL for the latest Stable version
- — URL for the latest LTS version
These addresses are accessed by Mikrotik devices to retrieve the latest available firmware version.
The first step is entirely individual for each case, and its logic may vary. It all depends on your task.
When working with web scripts, track which response retrieval method you need. Overskrifter HTTP response or the body of the response without headers?
If authentication cookies are needed, then set the response method Overskrifter as in the case with Asterisk.If data is needed, as in the case of the Mikrotik server response, set Krop the response without headers.
Trin 2
Moving on to the second step. Obtaining an authorization session:
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 — the version of the JSON-RPC protocol being used;
Zabbix implements JSON-RPC version 2.0;
- method — the method being called;
- params — parameters passed by the method;
- id — an arbitrary request identifier;
- auth — the user authentication key; since we do not have it yet, we will set it to null.
To work with the API, I created a separate account with limited permissions. Firstly, there's no need to give access where it's not needed. Secondly, before version 5.0, the password set via the macro could be read. Therefore, using the Zabbix administrator password makes it easy to steal the admin account.
This will be especially relevant when working with the API through third-party scripts and storing credentials on the client side.
Since version 5.0, there is an option to hide the password saved in the macro.
When creating a separate account for updating data via the API, always check if the data you need is accessible through the web interface and if it can be updated. I did not check this and then could not understand for a long time why the needed macro was not visible through the API.
After obtaining authorization in the API, we move on to retrieving the list of macros.
Trin 3
API-grænsefladen tillader ikke at opdatere værtsmakroen efter navn; for dette skal du først få makroens ID. Desuden, for at få en liste over makroer for en bestemt vært, skal du kende ID'en for denne vært, og det er en ekstra anmodning. Brug den indbyggede makro. {HOST.ID} i anmodningen er ikke tilladt. Jeg omgår denne begrænsning på følgende måde:
Jeg har oprettet en lokal makro med ID'en for denne vært. At finde værts-ID'en er meget nemt via webgrænsefladen.
Svaret med en liste over alle makroer for denne vært kan filtreres efter mønster:
regex:{"hostmacroid":"([0-9]+)"[A-z0-9,":]+"{$MIKROTIK_VERSION}" 
På den måde får vi ID'en for den makro, vi har brug for, hvor MIKROTIK_VERSION — navnet på den makro, vi søger. I mit tilfælde er det makroen MIKROTIK_VERSION, som var tildelt vært.
Selve anmodningen ser sådan 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} fået i andet trin og vil blive brugt konstant, hvor der skal arbejdes med API-grænsefladen.
Det endelige TRIN 4 — opdatering af makroen
Nu kender vi ID'en for den makro, der skal opdateres, autorisations-cookie eller routerens firmwareversion. Vi 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} — værdien fået i første trin. I mit eksempel — versionen af den aktuelle Mikrotik firmware.
{hostmacroid} — værdien, vi fik i tredje trin — ID'en for makroen, som vi opdaterer.
Konklusioner
Tilgangen til løsning af opgaven med standardfunktionaliteten er langt mere kompleks og tidskrævende. Især hvis du kender til programmering og hurtigt kan skrive den nødvendige logik i et script.
En åbenlys fordel ved denne tilgang er "portabiliteten" af løsningen mellem forskellige servere.
Personligt finder jeg det mærkeligt, at det ikke er muligt at få adgang til data fra et andet element i HTTP-agenten og indsætte dem i anmodningens krop eller overskrifter [ ].
Den færdige skabelon kan .
Kilde: habr.com
