Zabbix: expansión de los límites de las macros

Al hacer una solución para un cliente, surgieron 2 tareas que quería resolver de manera hermosa y con la funcionalidad regular de Zabbix.

Desafío 1. Seguimiento de la versión de firmware actual en los enrutadores Mikrotik.

La tarea se resuelve fácilmente agregando un agente a la plantilla HTTP. El agente recibe la versión actual del sitio web de Mikrotik y el activador compara la versión actual con la actual y emite una alerta en caso de discrepancia.

Cuando tiene 10 enrutadores, dicho algoritmo no es crítico, pero ¿qué hacer con 3000 enrutadores? ¿Enviar 3000 solicitudes al servidor? Por supuesto, tal esquema funcionará, pero la idea misma de 3000 solicitudes no me convenía, quería encontrar otra solución. Además, todavía había un inconveniente en dicho algoritmo: el otro lado puede contar tal cantidad de solicitudes de una IP para un ataque DoS, simplemente pueden prohibirlo.

Desafío 2. Usando una sesión de autorización en diferentes agentes HTTP.

Cuando un agente necesita recibir información de páginas "cerradas" a través de HTTP, se necesita una cookie de autorización. Para ello, suele haber un formulario de autorización estándar con un par de "inicio de sesión/contraseña" y el establecimiento del ID de sesión en la cookie.

Pero hay un problema, es imposible acceder a los datos de otro elemento desde un elemento del agente HTTP para sustituir este valor en el encabezado.

También hay un "script web", tiene otra limitación, no le permite obtener contenido para analizar y guardar más. Solo puede verificar la presencia de las variables necesarias en las páginas o pasar las variables recibidas previamente entre los pasos del script web.

Después de pensar un poco en estas tareas, decidí usar macros que son perfectamente visibles en cualquier parte del sistema de monitoreo: en plantillas, hosts, disparadores o elementos. Y puede actualizar macros a través de la API de la interfaz web.

Zabbix tiene una documentación API buena y detallada. Para el intercambio de datos a través de API, se utiliza el formato de datos Json. Los detalles se pueden encontrar en documentación oficial.

La secuencia de acciones para obtener los datos que necesitamos y grabarlos en una macro se muestra en el siguiente diagrama.

Zabbix: expansión de los límites de las macros

Paso 1

El primer paso puede consistir en una sola acción o múltiples acciones. Toda la lógica principal se establece en los primeros pasos, y los últimos 3 pasos son los principales.

En mi ejemplo, el primer paso fue obtener cookies de autorización en el PBX para la primera tarea. Para la segunda tarea, obtuve el número de la versión actual del firmware de Mikrotik.

URL de las versiones actuales del firmware de Mikrotik

El propio equipo Mikrotik accede a estas direcciones cuando se recibe la última versión de firmware disponible.

El primer paso es completamente individual para cada caso y la lógica de su trabajo puede ser diferente. Todo depende de tu tarea.

Cuando trabaje con secuencias de comandos web, realice un seguimiento del método de respuesta que necesita. Titulares Respuesta HTTP o auto тело respuesta sin encabezados?
Si se necesitan cookies de autorización, configure el método de respuesta Titulares como en el caso de Asterisk.

Si necesita datos, como en el caso de la respuesta del servidor mikrotik, ponga Cuerpo respuesta sin encabezados.

Paso 2

Pasemos al segundo paso. Obtener una 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 es la versión del protocolo JSON-RPC que se está utilizando;
Zabbix implementa JSON-RPC versión 2.0;

  • método - el método que se llama;
  • params: parámetros que pasa el método;
  • id es un identificador de solicitud arbitrario;
  • aut - clave de autenticación del usuario; como aún no lo tenemos, vamos a establecerlo en nulo.

Para trabajar con la API, creé una cuenta separada con derechos limitados. En primer lugar, no necesita dar acceso a donde no lo necesita. Y en segundo lugar, antes de la versión 5.0, se podía leer la contraseña establecida a través de la macro. En consecuencia, si usa la contraseña de administrador de Zabbix, la cuenta de administrador es fácil de robar.

Esto será especialmente cierto cuando se trabaje con API a través de scripts de terceros y se almacenen credenciales al margen.

Desde la versión 5.0 hay una opción para ocultar la contraseña guardada en la macro.

Zabbix: expansión de los límites de las macros

Al crear una cuenta separada para actualizar datos a través de la API, asegúrese de verificar si los datos que necesita están disponibles a través de la interfaz web y si es posible actualizarlos. No verifiqué y luego, durante mucho tiempo, no pude entender por qué la macro que necesitaba no estaba visible en la API.

Zabbix: expansión de los límites de las macros

Después de haber recibido la autorización en la API, procedemos a obtener una lista de macros.

Paso 3

La API no le permite actualizar una macro de host por nombre, primero debe obtener la ID de la macro. Además, para obtener una lista de macros para un host específico, debe conocer la ID de este host, y esta es una solicitud adicional. Usar macro predeterminada {ID DE ANFITRIÓN} en la solicitud no está permitido. Decidí eludir la restricción de esta manera:

Zabbix: expansión de los límites de las macros

Creé una macro local con la ID de este host. Averiguar la ID del host es muy fácil desde la interfaz web.

Una respuesta con una lista de todas las macros en un host determinado se puede filtrar por un patrón:

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

Zabbix: expansión de los límites de las macros

Por lo tanto, obtenemos la ID de la macro que necesitamos, donde MIKROTIK_VERSIÓN es el nombre de la macro que estamos buscando. En mi caso se busca la macro MIKROTIK_VERSIÓNEl que se asignó al host.

La solicitud en sí se ve así:

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} obtenido en el segundo paso y se usará constantemente, donde necesita trabajar con la interfaz API.

Último 4 PASO - actualizar la macro

Ahora conocemos el ID de macro que debe actualizarse, la cookie de autorización o la versión de firmware del enrutador. Puede actualizar la macro en sí.

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_versión} es el valor obtenido en el primer paso. En mi ejemplo, la versión del firmware mikrotik actual
{hostmacroid} - el valor se obtuvo en el tercer paso - el id de la macro que estamos actualizando.

Hallazgos

El enfoque para resolver el problema con la funcionalidad estándar es mucho más complicado y más largo. Especialmente si sabe programar y puede agregar rápidamente la lógica necesaria en el script.

La ventaja obvia de este enfoque es la "portabilidad" de la solución entre diferentes servidores.

Para mí, personalmente, es extraño que el agente HTTP no pueda acceder a los datos de otro elemento y sustituirlos en el cuerpo de la solicitud o en los encabezados [ ZBXNEXT-5993].

La plantilla terminada puede descargar en GitHub.

Fuente: habr.com

Añadir un comentario