Quan vaig fer una solució per a un client, van sorgir 2 tasques que volia resoldre de manera bella i amb la funcionalitat habitual de Zabbix.
Objectiu 1. Seguiment de la versió actual del firmware als encaminadors Mikrotik.
La tasca es resol fàcilment, afegint un agent a la plantilla HTTP. L'agent rep la versió actual del lloc web de Mikrotik i el disparador compara la versió actual amb l'actual i emet una alerta en cas de discrepància.
Quan teniu 10 encaminadors, aquest algorisme no és crític, però què fer amb 3000 encaminadors? Enviar 3000 peticions al servidor? Per descomptat, aquest esquema funcionarà, però la idea mateixa de 3000 sol·licituds no em va bé, volia trobar una altra solució. A més, encara hi havia un inconvenient en aquest algorisme: l'altre costat pot comptar un nombre tan gran de sol·licituds d'una IP per a un atac DoS, simplement poden prohibir-lo.
Objectiu 2. Ús d'una sessió d'autorització en diferents agents HTTP.
Quan un agent necessita rebre informació de pàgines "tancades" mitjançant HTTP, cal una galeta d'autorització. Per fer-ho, sol haver-hi un formulari d'autorització estàndard amb un parell "inici de sessió / contrasenya" i establint l'ID de sessió a la galeta.
Però hi ha un problema, és impossible accedir a les dades d'un altre element des d'un element de l'agent HTTP per substituir aquest valor a la capçalera.
També hi ha un "script web", té una altra limitació, no permet obtenir continguts per analitzar-los i guardar-los més. Només podeu comprovar la presència de les variables necessàries a les pàgines o passar variables obtingudes prèviament entre passos de guió web.
Després de pensar una mica en aquestes tasques, vaig decidir utilitzar macros perfectament visibles en qualsevol part del sistema de monitorització: en plantilles, hosts, activadors o elements. I podeu actualitzar macros mitjançant l'API de la interfície web.
Zabbix té una bona i detallada documentació de l'API. Per a l'intercanvi de dades mitjançant API, s'utilitza el format de dades Json. Els detalls es poden trobar a .
A l'esquema següent es mostra la seqüència d'accions per obtenir les dades que necessitem i registrar-les en una macro.
Pas 1
El primer pas pot consistir en una única acció o múltiples accions. Tota la lògica principal es troba en els primers passos, i els darrers 3 passos són els principals.
En el meu exemple, el primer pas va ser obtenir galetes d'autorització a la central per a la primera tasca. Per a la segona tasca, vaig obtenir el número de la versió actual del microprogramari Mikrotik.
URL de les versions actuals del microprogramari Mikrotik
- - Adreça URL de la versió estable actual
- — Adreça URL de la versió actual de LTS
El propi equip Mikrotik accedeix a aquestes adreces quan es rep l'última versió de microprogramari disponible.
El primer pas és completament individual per a cada cas i la lògica del seu treball pot ser diferent. Tot depèn de la teva tasca.
Quan treballeu amb scripts web, feu un seguiment del mètode de resposta que necessiteu. Encapçalaments Resposta HTTP o pròpia тело resposta sense capçaleres?
Si calen galetes d'autorització, configureu el mètode de resposta Encapçalaments com en el cas d'Asterisk.Si necessiteu dades, com en el cas de la resposta del servidor mikrotik, poseu El cos resposta sense capçaleres.
Pas 2
Passem al segon pas. Obtenció d'una sessió d'autorització:
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 és la versió del protocol JSON-RPC que s'està utilitzant;
Zabbix implementa JSON-RPC versió 2.0;
- mètode - el mètode que s'anomena;
- params - paràmetres que es transmeten pel mètode;
- id és un identificador de sol·licitud arbitrari;
- auth - clau d'autenticació de l'usuari; com que encara no el tenim, posem-lo a null.
Per treballar amb l'API, vaig crear un compte independent amb drets limitats. En primer lloc, no cal que doneu accés on no ho necessiteu. I en segon lloc, abans de la versió 5.0, es podia llegir la contrasenya establerta a través de la macro. En conseqüència, si utilitzeu la contrasenya d'administrador de Zabbix, el compte d'administrador és fàcil de robar.
Això serà especialment cert quan es treballa amb API mitjançant scripts de tercers i emmagatzemar credencials al costat.
Des de la versió 5.0 hi ha una opció per ocultar la contrasenya desada a la macro.
Quan creeu un compte independent per actualitzar dades mitjançant l'API, assegureu-vos de comprovar si les dades que necessiteu estan disponibles a través de la interfície web i si és possible actualitzar-les. No vaig comprovar, i durant molt de temps no vaig poder entendre per què la macro que necessitava no era visible a l'API.
Després d'haver rebut l'autorització a l'API, procedim a obtenir una llista de macros.
Pas 3
L'API no us permet actualitzar una macro de l'amfitrió pel nom, primer heu d'obtenir l'ID de la macro. A més, per obtenir una llista de macros per a un amfitrió específic, heu de conèixer l'ID d'aquest amfitrió, i aquesta és una sol·licitud addicional. Utilitza la macro predeterminada {ID HOST} en la sol·licitud no està permès. Vaig decidir saltar la restricció com aquesta:
Vaig crear una macro local amb l'identificador d'aquest amfitrió. Esbrinar l'identificador de l'amfitrió és molt fàcil des de la interfície web.
Una resposta amb una llista de totes les macros d'un host determinat es pot filtrar mitjançant un patró:
regex:{"hostmacroid":"([0-9]+)"[A-z0-9,":]+"{$MIKROTIK_VERSION}"
Així, obtenim l'ID de la macro que necessitem, on MIKROTIK_VERSION és el nom de la macro que busquem. En el meu cas, es cerca la macro MIKROTIK_VERSIONEl que va ser assignat a l'amfitrió.
La sol·licitud en si és així:
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
}
Variable {sid} obtingut en el segon pas i s'utilitzarà constantment, on cal treballar amb la interfície API.
Pas final 4 - actualització de la macro
Ara sabem l'ID de la macro que cal actualitzar, la galeta d'autorització o la versió del firmware de l'encaminador. Podeu actualitzar la macro mateixa.
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} és el valor obtingut en el primer pas. En el meu exemple, la versió del firmware actual del mikrotik
{hostmacroid} - el valor s'ha obtingut en el tercer pas - l'identificador de la macro que estem actualitzant.
Troballes
L'enfocament per resoldre el problema amb la funcionalitat estàndard és molt més complicat i més llarg. Sobretot si coneixeu programació i podeu afegir ràpidament la lògica necessària a l'script.
L'avantatge evident d'aquest enfocament és la "portabilitat" de la solució entre diferents servidors.
Per a mi personalment, és estrany que l'agent HTTP no pugui accedir a les dades d'un altre element i substituir-les al cos o a les capçaleres de la sol·licitud [ ].
La plantilla acabada pot .
Font: www.habr.com