Al desarrollar una solución para el cliente, surgieron 2 tareas que queríamos resolver de manera elegante y con la funcionalidad estándar de Zabbix.
Tarea 1. Seguimiento de la versión de firmware actual en los enrutadores Mikrotik.
La tarea se resuelve fácilmente al agregarlo en la plantilla del agente HTTP. El agente obtiene la versión actual del sitio de Mikrotik, y el disparador compara la versión actual con la vigente y, en caso de discrepancia, emite una alerta.
Cuando tienes 10 enrutadores, tal algoritmo no es crítico, pero ¿qué hacer con 3000 enrutadores? ¿Enviar 3000 solicitudes al servidor? Funcionará, por supuesto, pero la idea de 3000 solicitudes no me convencía, quería encontrar otra solución. Además, había una desventaja en este algoritmo: el otro lado podría considerar tal cantidad de solicitudes desde una IP como un ataque DoS y simplemente podrían bloquearlo.
Tarea 2. Uso de la sesión de autorización en diferentes agentes HTTP.
Cuando se necesita obtener información de páginas "cerradas" a través del agente HTTP, se requiere una cookie de autorización. Para ello, generalmente existe un formulario de autorización estándar con un par de "usuario / contraseña" y la instalación del ID de sesión en la cookie.
Pero hay un problema, no se puede hacer que un elemento del agente HTTP acceda a los datos de otro elemento para insertar ese valor en el Header.
También existe el "Guion Web", que tiene otra limitación, no permite obtener contenido para análisis y almacenamiento posterior. Solo se puede verificar la existencia de las variables necesarias en las páginas o transferir las variables obtenidas previamente entre pasos del guion web.
Después de reflexionar un poco sobre estas tareas, decidí utilizar macros que son claramente visibles en cualquier parte del sistema de monitoreo: en plantillas, hosts, disparadores o elementos. Y se pueden actualizar las macros a través de la API de la interfaz web.
Zabbix tiene una buena y detallada documentación sobre la API. El intercambio de datos a través de la API utiliza el formato de datos JSON. Se puede leer más en .
La secuencia de acciones para obtener los datos que necesitamos y grabarlos en la macro se presenta en el esquema a continuación.
Compra una suscripción
El primer paso puede consistir en una sola acción o en múltiples acciones. En los primeros pasos se establece toda la lógica principal, y los últimos 3 pasos son los más importantes.
En mi ejemplo, en el primer paso se obtuvo la cookie de autorización en la central telefónica 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
- — URL de la versión estable actual
- — URL de la versión LTS actual
Estos direcciones son consultadas por el propio equipo Mikrotik al obtener la última versión disponible del firmware.
El primer paso es completamente individual para cada caso y la lógica de su funcionamiento puede variar. Todo depende de tu tarea.
Al trabajar con scripts web, asegúrate de qué método de obtención de respuesta necesitas. Encabezados respuesta HTTP o el cuerpo de la respuesta sin encabezados?
Si necesitas cookies de autorización, establece el método de respuesta Encabezados como con Asterisk.Si necesitas datos, como en el caso de la respuesta del servidor Mikrotik, establece Cuerpo la respuesta sin encabezados.
Paso 2
Pasamos al segundo paso. Obtención de la 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 — versión del protocolo JSON-RPC que se utiliza;
Zabbix implementa JSON-RPC versión 2.0;
- method — método que se invoca;
- params — parámetros que se pasan al método;
- id — identificador arbitrario de la solicitud;
- auth — clave de autenticación del usuario; como aún no la tenemos, la estableceremos como nula.
Para trabajar con la API creé una cuenta separada con derechos limitados. Primero, no es necesario dar acceso a lo que no se necesita. Y en segundo lugar, hasta la versión 5.0, la contraseña asignada a través de un macro podía ser leída. Por lo tanto, si usas la contraseña del administrador de Zabbix, la cuenta del admin es fácil de robar.
Esto será especialmente relevante cuando trabajes con la API a través de scripts externos y almacenes las credenciales del lado del cliente.
Desde la versión 5.0, apareció la opción de ocultar la contraseña guardada en el macro.
Cuando crees una cuenta separada para actualizar datos a través de la API, asegúrate de que los datos que necesitas estén disponibles a través de la interfaz web y de que sea posible actualizarlos. No lo verifiqué, y luego no pude entender por qué no podía ver el macro que necesitaba a través de la API.
Después de haber obtenido la autorización en la API, pasamos a obtener la lista de macros.
Paso 3
La interfaz API no permite actualizar el macro del host por nombre; primero se necesita obtener el ID del macro. Además, para obtener la lista de macros de un host específico, es necesario conocer el ID de ese host, lo que implica una solicitud adicional. Usar el macro estándar. {HOST.ID} no se puede en la solicitud. Decidí eludir la limitación de esta manera:
Creé un macro local con el ID de este host. Conocer el ID del host es muy fácil desde la interfaz web.
La respuesta con la lista de todos los macros de este host se puede filtrar por patrón:
regex:{"hostmacroid":"([0-9]+)"[A-z0-9,":]+"{$MIKROTIK_VERSION}" 
Así, obtenemos el ID del macro que necesitamos, donde MIKROTIK_VERSION es el nombre del macro que estamos buscando. En mi caso, se busca el macro MIKROTIK_VERSION, que fue asignado al host.
La solicitud 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 utilizará constantemente donde sea necesario trabajar con la interfaz API.
El paso final 4 — actualización del macro.
Ahora sabemos el ID del macro que necesitamos actualizar, la cookie de autorización o la versión del firmware del router. Se puede actualizar el macro mismo.
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} es el valor obtenido en el primer paso. En mi ejemplo, es la versión actual del firmware de Mikrotik.
{hostmacroid} es el valor obtenido en el tercer paso: el ID del macro que estamos actualizando.
Conclusiones
El enfoque para resolver la tarea con la funcionalidad estándar es mucho más complicado y lleva más tiempo. Especialmente si sabes programación y puedes rápidamente esbozar la lógica necesaria en un script.
Una ventaja obvia de este enfoque es la "portabilidad" de la solución entre diferentes servidores.
Personalmente, me resulta extraño que no exista la posibilidad de acceder en el agente HTTP a los datos de otro ítem y de insertarlos en el cuerpo de la solicitud o en los encabezados [ ].
El template listo se puede .
Fuente: habr.com
