Ao facer unha solución para un cliente, xurdiron 2 tarefas que quería resolver moi ben e coa funcionalidade habitual de Zabbix.
Desafío 1 Seguimento da versión actual do firmware nos enrutadores Mikrotik.
A tarefa resólvese facilmente, engadindo un axente ao modelo HTTP. O axente recibe a versión actual do sitio web de Mikrotik e o disparador compara a versión actual coa actual e emite unha alerta en caso de discrepancia.
Cando tes 10 enrutadores, tal algoritmo non é crítico, pero que facer con 3000 enrutadores? Enviar 3000 solicitudes ao servidor? Por suposto, tal esquema funcionará, pero a idea de 3000 solicitudes non me convenía, quería atopar outra solución. Ademais, aínda había un inconveniente en tal algoritmo: o outro lado pode contar tantas solicitudes dunha IP para un ataque DoS, simplemente pode prohibilo.
Desafío 2 Usando unha sesión de autorización en diferentes axentes HTTP.
Cando un axente necesita recibir información de páxinas "pechadas" a través de HTTP, é necesaria unha cookie de autorización. Para iso, adoita existir un formulario de autorización estándar cun par "inicio de sesión/contrasinal" e configurando o ID de sesión na cookie.
Pero hai un problema, é imposible acceder aos datos doutro elemento desde un elemento do axente HTTP para substituír este valor na cabeceira.
Tamén hai un "Guión web", ten outra limitación, non permite obter contido para análise e posterior aforro. Só pode comprobar a presenza das variables necesarias nas páxinas ou pasar variables recibidas previamente entre os pasos de guión web.
Despois de pensar un pouco nestas tarefas, decidín utilizar macros perfectamente visibles en calquera parte do sistema de seguimento: en modelos, hosts, disparadores ou elementos. E pode actualizar as macros a través da API da interface web.
Zabbix ten unha boa e detallada documentación da API. Para o intercambio de datos mediante API, utilízase o formato de datos Json. Os detalles pódense atopar en .
A secuencia de accións para obter os datos que necesitamos e rexistralos nunha macro móstrase no seguinte esquema.
Paso 1
O primeiro paso pode consistir nunha única acción ou varias accións. Toda a lóxica principal está establecida nos primeiros pasos, e os últimos 3 pasos son os principais.
No meu exemplo, o primeiro paso foi obter cookies de autorización na PBX para a primeira tarefa. Para a segunda tarefa, obtiven o número da versión actual do firmware Mikrotik.
URL das versións actuais do firmware Mikrotik
- - Enderezo URL da versión Stable actual
- — Enderezo URL da versión actual de LTS
A estes enderezos accede o propio equipo Mikrotik cando se recibe a última versión de firmware dispoñible.
O primeiro paso é completamente individual para cada caso e a lóxica do seu traballo pode ser diferente. Todo depende da túa tarefa.
Cando traballes con scripts web, fai un seguimento do método de resposta que necesitas. Títulos Resposta HTTP ou auto тело resposta sen cabeceiras?
Se se necesitan cookies de autorización, configure o método de resposta Títulos como no caso de Asterisk.Se necesitas datos, como no caso da resposta do servidor mikrotik, pon O corpo resposta sen cabeceiras.
Paso 2
Pasemos ao segundo paso. Obtención dunha sesión de autorización:
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 é a versión do protocolo JSON-RPC que se está a utilizar;
Zabbix implementa a versión 2.0 de JSON-RPC;
- método - o método que se chama;
- params - parámetros que se pasan polo método;
- id é un identificador de solicitude arbitrario;
- auth - clave de autenticación do usuario; xa que aínda non o temos, poñémolo como nulo.
Para traballar coa API, creei unha conta separada con dereitos limitados. En primeiro lugar, non precisa dar acceso a onde non o precisa. E en segundo lugar, antes da versión 5.0, podíase ler o contrasinal definido a través da macro. En consecuencia, se usa o contrasinal de administrador de Zabbix, a conta de administrador é fácil de roubar.
Isto será especialmente certo cando se traballa con API a través de scripts de terceiros e se almacenan credenciais ao lado.
Desde a versión 5.0 hai unha opción para ocultar o contrasinal gardado na macro.
Cando crees unha conta separada para actualizar datos a través da API, asegúrate de comprobar se os datos que necesitas están dispoñibles a través da interface web e se é posible actualizalos. Non comprobei e, durante moito tempo, non puiden entender por que a macro que necesitaba non estaba visible na API.
Despois de recibir a autorización na API, procedemos a obter unha lista de macros.
Paso 3
A API non che permite actualizar unha macro de host polo nome, primeiro debes obter o ID de macro. Ademais, para obter unha lista de macros para un host específico, cómpre coñecer o ID deste host, e esta é unha solicitude adicional. Usa a macro predeterminada {ID HOST} na solicitude non está permitido. Decidín ignorar a restrición así:
Creei unha macro local co ID deste host. Descubrir o ID do host é moi sinxelo desde a interface web.
Unha resposta cunha lista de todas as macros dun host determinado pódese filtrar mediante un patrón:
regex:{"hostmacroid":"([0-9]+)"[A-z0-9,":]+"{$MIKROTIK_VERSION}"
Así, obtemos o ID da macro que necesitamos, onde MIKROTIK_VERSION é o nome da macro que buscamos. No meu caso, búscase a macro MIKROTIK_VERSIONO que foi asignado ao anfitrión.
A propia solicitude ten o seguinte aspecto:
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} obtido no segundo paso e será usado constantemente, onde ten que traballar coa interface API.
Paso final 4: actualización da macro
Agora sabemos o ID de macro que hai que actualizar, a cookie de autorización ou a versión de firmware do router. Podes actualizar a propia macro.
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
}
{versión_mikrotik} é o valor obtido no primeiro paso. No meu exemplo, a versión do firmware mikrotik actual
{hostmacroid} - o valor obtívose no terceiro paso - o id da macro que estamos actualizando.
Descubrimentos
O enfoque para resolver o problema coa funcionalidade estándar é moito máis complicado e máis longo. Especialmente se coñeces programación e podes engadir rapidamente a lóxica necesaria no guión.
A vantaxe obvia deste enfoque é a "portabilidade" da solución entre distintos servidores.
Para min, persoalmente, é estraño que o axente HTTP non poida acceder aos datos doutro elemento e substituílos no corpo ou cabeceiras da solicitude [ ].
O modelo rematado pode .
Fonte: www.habr.com