Pandora FMS: ¿Qué sabes sobre el envío de información adicional en alertas de email?

Cuando estamos realizando una monitorización sobre los componentes de software de un servidor, a veces podemos necesitar saber algo más sobre el comportamiento de las métricas que supervisamos. 

Envío de información adicional en alertas de email

Se trata de poner los datos en contexto, porque no es lo mismo un 25, que un 25% de una CPU, que el 25% de una CPU con otras tres CPU más, todas ellas al 100%, o el 25% de una CPU de un equipo a punto de bloquearse por exceso de transacciones de E/S que lleva horas aguantando una carga, que ha puesto la temperatura del sistema al máximo. 

¿Verdad que un “25” puede significar muchas cosas? Profundicemos un poco más en ello

Siguiendo con el caso anterior, supongamos que queremos medir el uso de CPU en uno de los servidores que gestionamos, y donde tenemos definidos unos umbrales que fuerzan la notificación por email al equipo de responsables de administración del equipo. 

Este umbral (CRIT para CPU > 80) se reflejaría en la configuración del módulo de una manera como la que sigue:

La alerta se define utilizando la plantilla “Critical condition” y utilizo la acción de enviar email personalizada para enviar a un buzón concreto.

Bien, hasta aquí es algo básico. 

Pero me gustaría poder enviar cierta información adicional sobre el problema, algo que tenga que recoger solo cuando necesito, información en tiempo real que me sea útil para buscar una solución de manera automática.

Pero…. ¿Pandora FMS puede hacerlo? 

Podríamos incluir información de otros módulos en el correo utilizando las macros de alerta que hacen referencia a otros módulos. 

Puedes consultar la lista completa de macros en la documentación, pero te hago un resumen rápido de algunas macros interesantes:

moduledata_X_: Mostrará el dato del módulo “X” del mismo agente que el módulo que dispara la alerta. 

De esta forma si tenemos un módulo llamado LoadAVG, llamando a la macro _moduledata_LoadAVG_ podremos volcar el valor de la carga del sistema. 

De igual manera, para mostrar una gráfica de las últimas 24 hr de dicho módulo, deberíamos usar la macro _modulegraph_LoadAVG_24_ 

*Esto último de la gráfica todavía es experimental, hasta la versión 772 no estará disponible para todo el mundo.

Mostrando procedimientos

Quizás quisiéramos incluir información textual de qué hacer en caso de que se ponga en CRITICAL nuestro módulo, a modo de instrucciones o procedimiento, para ello la macro _alert_critical_instructions_ devolverá el texto que hayamos configurado en dicho módulo para este caso.

Mostrando el dato anterior

Igual me interesa mostrar el dato anterior en este monitor antes de que disparara la alerta, para ello podremos usar la macro  _prevdata_

Mostrando campos personalizados informativos del agente

Imaginemos que tenemos un campo en el agente que recolecta los datos, que nos indica el nombre del responsable del sistema y su teléfono, como campos personalizados de agente con ID 7 e ID 9. 

Para ello usaríamos la macro_agentcustomfield_n_ como macro_agentcustomfield_7_ y macro_agentcustomfield_9_ y así poder poner en el email el nombre y teléfono del responsable del sistema.

Un ejemplo completo, usando macros en un email

Veamos un ejemplo. 

Si quisiera enviar un email algo más completo, editaría la acción de correo que estoy usando para añadir macros nuevas:

Utilizando información dinámica

¿Y si queremos ir más allá? 

¿Y si queremos ejecutar un comando cada vez que pase algo y recoger el valor para enviarlo en el email? 

De esta manera, no tenemos la  necesidad de tener una métrica adicional constante en nuestra monitorización para no llenar la base de datos con información que solo nos es útil en casos de criticidad.

Para poder realizar este envío de información adicional, será necesario crear un módulo previo en nuestro agente software para que recopile la información únicamente cuando sea necesario. 

Para ello, introduciremos la siguiente estructura dentro de nuestro módulo:

module_begin 

module_name NOMBRE_DEL_MODULO

module_type async_string 

module_precondition > X COMANDO_A_EJECUTAR_COMO_CONDICION

module_exec COMANDO_FINAL_A_EJECUTAR

module_end

• El módulo tendrá que ser de tipo asíncrono y con el tipo de dato que vamos a recopilar. 

Esto se debe a la necesidad de que este módulo no pase a estado desconocido, dando así una falsa sensación de fallo, cuando no cumple la precondición del módulo.

• Se tendrá que incorporar una expresión de condición para que podamos ejecutar el módulo con normalidad. 

Para ello tendremos que realizar un comando previo del cual obtener la información numérica para la obtención del dato. Siguiendo el ejemplo de la CPU descrito anteriormente ( que sea mayor del 80%) sería algo como:

• module_precondition > 80 uptime | awk -F “,” ‘{print $3}’ | awk ‘{print $3}’ | tr ­d “\n”
• Por último utilizaremos el comando de obtención de dicha información adicional que adjuntaremos en nuestro email.

En el caso anterior, nos convendría saber los procesos que están consumiendo más CPU (top 5 procesos) , por lo que podríamos poner el siguiente caso:

• module_exec top -n1 | head -12

Por lo que en el ejemplo anterior quedaría un módulo de la siguiente manera:

module_begin 

module_name TOP5_CPU_Proc_Usage

module_type async_string 

module_precondition > 80 uptime | awk -F “,” ‘{print $3}’ | awk ‘{print $3}’ | tr ­d “\n”

module_exec top -n1 | head -12

module_end

Una vez tenemos creado el módulo que solo será ejecutado cuando sea necesario, tenemos que introducir esta información en nuestro email.

 Para ello debemos usar la siguiente macro dentro del mail:

_moduledata_TOP5_CPU_Proc_Usage_ 

Este es solo un uso para enviar la información adicional, podemos utilizarlo para otros casos como por ejemplo, si el uso de disco de un servidor está llegando al límite, podemos mostrar los cinco archivos más pesados guardados en el servidor, usando el  deberemos usar el comando “du -Sah / | sort -rh | head -5”