Monitoreo de servicios: migrando de Nagios a Zabbix
En el ámbito de las operaciones en TI no es extraño encontrarse con clientes que cuentan con un sistema de monitoreo basado en Nagios y un plan de migración a Zabbix.
El monitoreo básico de sistemas informáticos está integrado tanto en Nagios como en Zabbix y transformarlo no requiere mayor esfuerzo. Sin embargo, desde el punto de vista de las operaciones en TI, el valor agregado se encuentra en el monitoreo de los procesos específicos del negocio y de los servicios al usuario final.
Las empresas suelen tener una colección de scripts personalizados para monitorear estos servicios. De hecho, los scripts ya están pensados para integrarse con su herramienta de monitoreo.
En este artículo se plantearán algunos elementos a tener en cuenta a la hora de adaptar dichos scripts y hacerlos compatibles con Zabbix.
Punto de partida: Nagios
En la documentación oficial de Nagios, se presentan las condiciones que deben cumplir los scripts personalizados de monitoreo -los cuales pueden estar escritos en cualquier lenguaje-. Las condiciones son:
- Según el nivel de severidad de la alerta a generar, el script devuelve uno de los siguientes códigos:
. Código 0 / Significado Ok
. Código 1 / Significado Warning
. Código 2 / Significado Critical
. Código 3 / Significado Unknown
Ejemplo: <TEXTO_SIMPLE> [|<DATOS_DE_PERFORMANCE>] [<TEXTO_COMPLETO>]
Donde los componentes entre [] son opcionales, el detalle es el siguiente:
| Parámetro | Descripción | Ejemplo |
| <TEXTO_SIMPLE> | Mensaje conciso de una línea indicando el resultado del chequeo. | DISK OK – free space: / 3326 MB (56%)
|
| <DATOS_DE_PERFORMANCE> | Listado de variables, con sus valores numéricos y opcionalmente umbrales, unidades de medida, mínimo y máximo. | /=2643MB;5948;5958;0;5968 /boot=68MB;88;93;0;98 /home=69357MB;253404;253409;0;253414 /var/log=818MB;970;975;0;980
|
| <TEXTO_COMPLETO> | Información adicional sobre el resultado del chequeo. Puede ser multi-línea. | / 15272 MB (77%) /boot 68 MB (69%) /home 69357 MB (27%) /var/log 819 MB (84%) |
- Cada elemento de los <DATOS_DE_PERFORMANCE> lleva el formato: VARIABLE>=<VALOR>[<UNIDAD>];[<WARN>];[<CRIT>];[<MIN>];[<MAX>]
Donde los componentes entre [] son opcionales, el detalle es el siguiente:
. Parámetro <VARIABLE> / Descripción: Nombre de la variable
. Parámetro <VALOR> / Descripción: Valor numérico
. Parámetro <UNIDAD> / Descripción: Unidad de medida
. Parámetro <WARN> / Descripción: Umbral de WARNING
. Parámetro <CRIT> / Descripción: Umbral de CRITICAL
. Parámetro <MIN> / Descripción: Valor mínimo que puede tomar la variable
. Parámetro <MAX> / Descripción: Valor máximo que puede tomar la variable
Punto de llegada: Zabbix
Los scripts personalizados simplemente deben imprimir en pantalla el valor del resultado del chequeo. Resulta indiferente si se trata de un texto, número entero, decimal, fecha/hora, etc. Zabbix no tiene en cuenta el código de salida del script ($?).
La interpretación del resultado se realiza por medio de configuraciones desde el frontend web de Zabbix.
Se debe destacar que, a diferencia de Nagios, en Zabbix se espera que un script devuelva un único indicador, por lo que si en Nagios se tiene un script con varios “datos de performance”, para portarlo a Zabbix se debe separar en varios scripts -cada uno devolviendo un único indicador-.
Zabbix utiliza una construcción llamada “UserParameter” que se trata de una correspondencia entre una palabra clave -llamada “item key”- y una línea de comando a ejecutar -ruta completa al script y argumentos-. Los UserParameters son una de las formas más usadas para integrar scripts personalizados a Zabbix y se incluyen en archivos de configuración del agente -normalmente en /etc/zabbix/zabbix_agent.d/-.
Existen dos variantes:
- Sin argumentos: UserParameter=<ITEM_KEY>,<COMANDO>
- Con argumentos: UserParameter=<ITEM_KEY>[*],<COMANDO> $1 $2 $3 …
En el primer caso ejecutará el comando tal como se envía el UserParameter siempre que Zabbix encuentre <ITEM_KEY>.
En el segundo caso, Zabbix espera que la definición del ítem tenga la forma <ITEM_KEY>[$arg1,$arg2,$arg3,…] y enviará los argumentos en el orden que aparecen al comando definido por el UserParameter, como $1, $2, $3…
Para usar el UserParameter se necesita crear un ítem desde el frontend: Configuration > Hosts > Items > Create item
- Name: nombre descriptivo del ítem
- Type: Zabbix agent
- Key: nombre del UserParameter -debe coincidir exactamente con la configuración del UserParameter en el host-
- Host interface: seleccionar la tarjeta de red que se quiere llegar al host a monitorear
- Type of information: etapa en la que Zabbix interpreta el resultado del script -número entero, decimal, texto, etc.-
- Units: unidades de medida, tienen correspondencia directa con las unidades estipuladas en los datos de performance en Nagios
- Update interval: frecuencia de ejecución del chequeo
En Nagios los chequeos están intrínsecamente ligados al disparo de alertas, pero en Zabbix estos dos conceptos se separan en ítems y triggers. De esta manera es posible contar con indicadores de análisis separados de los indicadores principales del servicio asociados a sus alertas.
Por lo tanto, para completar la migración se necesita crear los triggers correspondientes: Configuration > Hosts > Triggers > Create trigge
- Name: nombre descriptivo de la alerta
- Severity: nivel de severidad. En Zabbix hay 6 niveles (Not classified, Information, Warning, Average, High y Disaster), por lo que es necesario evaluar qué severidad se asigna a los originales WARNING y CRITICAL en Nagios -generalmente Warning y High-
- Expression: expresión lógica que dispara el trigger. Zabbix tiene una gama de posibilidades muy extensa y una sintaxis bien documentada [4][5], pero asimismo cuenta con dos asistentes gráficos para crear este tipo de expresiones (Add y Expression constructor)
Estrategias de conversión de scripts
Existen dos métodos de conversión de scripts para Nagios que devuelven valores en scripts para Zabbix.
La estrategia rápida es separar el script original en varios y agregar un UserParameter para cada script resultante. Esto tiene la ventaja de que el procedimiento de integración a Zabbix se resume en continuar los pasos anteriores pero la desventaja de que, muy posiblemente, se requiera repetir bloques enteros de código entre los scripts, calculando una y otra vez los mismos resultados intermedios para mostrar una única variable al final del script -lo que produce resultados extraídos en distintos momentos que no siempre tienen una correlación directa-.
Una alternativa para atacar dicha desventaja es contar con un script principal que guarde toda la información en un archivo de texto y contar con un script auxiliar que extraiga de ese archivo el indicador que se le pida.
Zabbix va más allá y utiliza un mecanismo que le permite enviar todos los indicadores juntos al servidor con una utilidad de línea de comando llamada “zabbix_sender”.
El zabbix_sender espera un archivo de texto, con un resultado por línea, con el siguiente formato: <hostname> <key> <timestamp> <value>
. Parámetro <hostname> / Descripción: Nombre del host que reporta el indicador. Debe coincidir con el nombre como está catalogado el host en Zabbix, no necesariamente con el hostname del equipo.
. Parámetro <key> / Descripción: Item key asociado al indicador. Debe existir un ítem del tipo “Zabbix trapper” con la misma item key (puede llevar argumentos).
. Parámetro <timestamp> / Descripción: Timestamp del indicador (en segundos desde el 01/01/1970). En un sistema Linux/UNIX puede obtenerse con date +%s.
. Parámetro <value> / Descripción: Valor del indicador. Puede ser numérico o texto.
Para enviar los resultados a Zabbix, se utiliza el comando zabbix_sender: $ zabbix_sender -z <ZABBIX_SERVER> [-T] -i <ARCHIVO_DATOS>
. Parámetro <ZABBIX_SERVER> / Descripción: Nombre o dirección IP del servidor de Zabbix (o proxy de Zabbix).
. Parámetro -T / Descripción: Opcionalmente, se usa esta opción para indicar que el archivo va con timestamps. Si el campo <timestamp> no se incluye en el archivo, no se debe usar -T. En este caso, Zabbix registra el valor con la fecha/hora de recibido.
. Parámetro <ARCHIVO_DATOS> / Descripción: Nombre del archivo de datos con el formato anterior. Si el archivo va con timestamps, se debe usar la opción -T.
El zabbix_sender debe ser programado para que se ejecute periódicamente, por ejemplo, colocándolo en el crontab. Incluso se le puede pedir al Zabbix que lo ejecute a través de un ítem de tipo “Zabbix agent” con un UserParameter que lo invoque. De esta manera se simplifica la instalación del plugin de cara al cliente.
Autor: Juan Godoy System Admin Sr.
Existen dos métodos de conversión de scripts para Nagios que devuelven valores en scripts para Zabbix.
La estrategia rápida es separar el script original en varios y agregar un UserParameter para cada script resultante. Esto tiene la ventaja de que el procedimiento de integración a Zabbix se resume en continuar los pasos anteriores pero la desventaja de que, muy posiblemente, se requiera repetir bloques enteros de código entre los scripts, calculando una y otra vez los mismos resultados intermedios para mostrar una única variable al final del script -lo que produce resultados extraídos en distintos momentos que no siempre tienen una correlación directa-.
Una alternativa para atacar dicha desventaja es contar con un script principal que guarde toda la información en un archivo de texto y contar con un script auxiliar que extraiga de ese archivo el indicador que se le pida.
Zabbix va más allá y utiliza un mecanismo que le permite enviar todos los indicadores juntos al servidor con una utilidad de línea de comando llamada “zabbix_sender”.
El zabbix_sender espera un archivo de texto, con un resultado por línea, con el siguiente formato: <hostname> <key> <timestamp> <value>
. Parámetro <hostname> / Descripción: Nombre del host que reporta el indicador. Debe coincidir con el nombre como está catalogado el host en Zabbix, no necesariamente con el hostname del equipo.
. Parámetro <key> / Descripción: Item key asociado al indicador. Debe existir un ítem del tipo “Zabbix trapper” con la misma item key (puede llevar argumentos).
. Parámetro <timestamp> / Descripción: Timestamp del indicador (en segundos desde el 01/01/1970). En un sistema Linux/UNIX puede obtenerse con date +%s.
. Parámetro <value> / Descripción: Valor del indicador. Puede ser numérico o texto.
Para enviar los resultados a Zabbix, se utiliza el comando zabbix_sender: $ zabbix_sender -z <ZABBIX_SERVER> [-T] -i <ARCHIVO_DATOS>
. Parámetro <ZABBIX_SERVER> / Descripción: Nombre o dirección IP del servidor de Zabbix (o proxy de Zabbix).
. Parámetro -T / Descripción: Opcionalmente, se usa esta opción para indicar que el archivo va con timestamps. Si el campo <timestamp> no se incluye en el archivo, no se debe usar -T. En este caso, Zabbix registra el valor con la fecha/hora de recibido.
. Parámetro <ARCHIVO_DATOS> / Descripción: Nombre del archivo de datos con el formato anterior. Si el archivo va con timestamps, se debe usar la opción -T.
El zabbix_sender debe ser programado para que se ejecute periódicamente, por ejemplo, colocándolo en el crontab. Incluso se le puede pedir al Zabbix que lo ejecute a través de un ítem de tipo “Zabbix agent” con un UserParameter que lo invoque. De esta manera se simplifica la instalación del plugin de cara al cliente.
Autor: Juan Godoy System Admin Sr.
