Pandora: QuickGuides ES: Configuracion de alertas

From Pandora FMS Wiki
Jump to: navigation, search

Volver a Índice de Guías Rápidas de Pandora FMS

1 Guía rápida de configuración de alertas para Pandora FMS

1.1 Estructura de una alerta


Esquema-alert-structure.png


Las alertas se componen de:

  • Comandos
  • Acciones
  • Plantillas

El comando define la operación o acción final a ejecutar cuando se dispara la alerta. Ejemplos de comandos pueden ser: escribir en un log, envíar un email o SMS, ejecutar un script o programa, etc.

Una acción relaciona un comando con una plantilla y permite personalizar la ejecución del comando usando tres parámetros genéricos Field 1, Field 2 y Field 3. Estos parámetros permiten personalizar la ejecución del comando ya que son los que se pasarán en el momento de la ejecución como parámetros de entrada.

En la plantilla se definen las condiciones de disparado de la alerta, si habrá también acción de recuperación, y la acción por defecto a ejecutar.

  • Condiciones de disparo: son las condiciones bajo las que se disparará la alerta, por ejemplo: superar cierto umbral, estar en estado crítico, etc. Se encuentran en la plantilla.
  • Acciones de disparo: siempre van asociadas a un comando, permiten parametrizar su ejecución y pasarle argumentos al comando mediantes sus campos Field 1, Field 2, etc.
  • Recuperación de alerta: es la configuración de las acciones que se realizarán cuando el sistema se recupere de la alerta y vuelva a estado normal.

1.1.1 Flujo de información en el sistema de alertas

Al definir las acciones y las plantillas disponemos de unos campos genéricos llamados Field1, Field2 y Field3 que son los que se pasarán como parámetros de entrada en la ejecución del comando. Los valores de estos parámetros se propagan de la plantilla a la acción y por último al comando. La propagación de la plantilla a la acción sólo se realiza si el campo correspondiente de la acción no tiene un valor asignado, si la acción tiene un valor asignado se conserva, prevaleciendo sobre el campo que heredaría de la plantilla si estuviese vacío. Ejemplo 1: los campos Field 1 y Field 2 tienen contenido en la plantilla, pero NO tienen contenido en la acción. La acción hereda el contenido para sus propios campos Field 1 y Field 2, que serán pasados como parámetros al comando. Ejemplo 2: los campos Field 1 y Field 2 tienen contenido en la plantilla, pero TAMBIÉN tienen contenido en la acción. La acción NO heredará el contenido de los campos Field 1 y Field 2 de la plantilla al disponer ya de su propio contenido.


Esquema-parameters-carrying.png


Este seria un ejemplo de como se sobreescriben los valores de la plantilla usando los de la acción.

Alertas esquema6.png


Por ejemplo creamos una plantilla que dispara la alerta y envía un email con los siguientes campos:

  • Plantilla:
    • Field1: [email protected]
    • Field2: [Alert] The alert was fired
    • Field3: The alert was fired!!! SOS!!!

Los valores que llegarían al comando serían:

  • Comando:
    • Field1: [email protected]
    • Field2: [Alert] The alert was fired
    • Field3: The alert was fired!!! SOS!!!

Para los campos Field2 y Field3 se conservan los valores definidos en la plantilla, pero para el campo Field1 usa el valor definido en la acción.

1.2 Definiendo una Alerta

Tenemos una necesidad: monitorizar un módulo que contiene valores numéricos, en nuestro caso, se trata de un modulo que mide la CPU del sistema. Veamos primero que nuestro módulo recibe datos correctamente:


Qgcpu1.png

En la captura anterior vemos que tenemos un modulo llamado cpu_user con un valor actual de 7. En nuestro caso queremos que salte una alerta cuando supere los 20. Para ello vamos a configurar el módulo para que se ponga en estado CRITICAL cuando supere los 20. Para ello hacemos click en la llave inglesa para configurar el comportamiento del monitor:


Qgcpu2.png

Para ello, modificamos el valor marcado en rojo en la captura siguiente:


Threshold.JPG

Aceptamos y grabamos la modificación. Ahora cuando el valor del módulo CPU sea 20 o mayor, cambiará su estado a CRITICAL y se verá en color rojo, tal y como vemos aquí.


Qgcpu4.png

Ya hemos hecho que el sistema sepa discriminar cuando algo está bien (OK, color VERDE) y cuando está mal (CRITICAL, color rojo). Ahora lo que debemos hacer es que nos envíe un email cuando el modulo se ponga en este estado. Para ello utilizaremos el sistema de alertas de Pandora FMS.

Para esto, lo primero que debemos hacer es asegurarnos de que existe un comando que hace lo que necesitamos (enviar un email). Este ejemplo es fácil porque existe un comando predefinido en Pandora FMS para enviar mails, pero podríamos crear cualquier comando que necesitásemos, como ejecutar un script o abrir un ticket en una plataforma externa.

1.3 Configurando la acción

Ahora tenemos que crear una acción que sea "Enviar un email al operador". Vamos a ello: Vamos al menu de Alerts > Actions y le damos al botón para crear una nueva acción:


Qgcpu5.png

Esta acción utiliza el comando "Enviar email", y es realmente sencillo, ya que sólo relleno un campo (Field 1) dejando los otros dos vacíos. Esta es una de las partes más confusas del sistema de alertas de Pandora FMS: ¿Qué son los campos field1, field2, y field3?.

Esos campos son los que se usan para "pasar" la información de la plantilla de alerta al comando, y a su vez, de éste al comando. De forma que tanto Plantilla como Comando puedan aportar diferente información al comando. En este caso el comando sólo establece el campo 1, y dejaremos el campo 2 y el campo 3 a la plantilla, como veremos a continuación.

El campo 1 es el que usamos para definir el email del operador, en este caso un supuesto mail a "[email protected]".

1.4 Configurando la plantilla (Alert template)

Ahora tenemos que crear una plantilla de alerta lo más genérica posible (para poderla reutilizar más adelante, como veremos) que sea "Esto está mal, porque tengo un módulo en estado Crítico" y que por defecto, envíe un email al operador. Vamos al menu de Alerts > Templates y le damos al botón para crear una nueva plantilla (template) de alerta:


Qgcpu6.png

El primer paso define ciertos aspectos descriptivos. La prioridad definida aquí "Critical" es la prioridad de la alerta, que no tiene que ver con el estado "Critico" del módulo. Esta prioridad de las alertas se define para que se visualicen en un color determinado en el visor de eventos, pero a nivel funcional no variará el funcionamiento de nuestra alerta. En el paso 2 se encontrarán algunos de los parámetros más importantes para el correcto funcionamiento de nuestra alerta:


Qgcpu7.png

El campo "Condition type" definirá las condiciones de disparado, en este caso está marcado a "Estado crítico", de forma que esta plantilla, cuando se asocie a un módulo, se disparará cuando el modulo asociado esté en estado crítico. Antes hemos configurado el modulo "cpu_user" para que entre en estado crítico cuando alcance un valor de 20 o superior.

El paso 2, además de las condiciones de disparado, define el rango de actuación temporal de la alerta, pudiendo restringir por franjas horarias o días de la semana.

Algunos de los parámetros clave:

  • Time threshold: Por defecto es un día. Si un módulo permanece caído durante todo un día, y tenemos aquí un valor de 5 minutos, significa que nos estaría mandando alertas cada 5 minutos. Si lo dejamos en un día (24 horas), sólo nos enviará la alerta una vez, en el momento que se produzca el fallo. Si el modulo se recupera (vuelve a estado norma), y luego se vuelve a caer, nos enviará una alerta de nuevo, pero si permanece en estado crítico sin llegar a recuperarse, no enviará mas alertas hasta dentro de 24 horas.
  • Min. Número de alertas: El nº mínimo de veces que se tendrá que dar la condición (en este caso, que el modulo esté en estado CRITICAL) antes de que Pandora FMS dispare la alerta. Es una forma de protegerse ante falsos positivos, o que un comportamiento errático (ahora bien, ahora mal) haga que se disparen muchas alertas. Si ponemos aquí 1, significa que hasta que no ocurra al menos una vez, no lo tendré en cuenta. Si pongo 0, la primera vez que el modulo esté mal, disparará la alerta.
  • Max. Numero de alertas: 1 significa que sólo ejecutará la acción una vez. Si tenemos aquí 10, ejecutará 10 veces la acción. Es una forma de limitar el número de veces que una alerta se puede ejecutar.

De nuevo volvemos a ver los campos: "campo1, campo2 y campo3". Ahora podemos ver que el campo1 está en blanco, que es justamente el que hemos definido al configurar la acción. El campo2 y el campo3 se usan en la acción de enviar un mail para definir el subject y el texto del mensaje, mientras que el campo1 se usa para definir el o los destinatarios (separados por comas). Asi que la plantilla, usando algunas macros, está definiendo el subject y el mensaje de alerta de forma que en nuestro caso nos llegaría un mensaje como el que sigue (suponiendo que el agente donde está el modulo se llama "Farscape":

To: [email protected]
Subject: [PANDORA] Farscape cpu_sys is in CRITICAL status with value 20
Texto email:
This is an automated alert generated by Pandora FMS
Please contact your Pandora FMS for more information. *DO NOT* reply this email.

Dado que la acción por defecto es la que he definido previamente, todas las alertas que usen esta plantilla, usarán esa acción predeterminada por defecto.

En el caso 3, veremos que se puede configurar el sistema de alertas para que notifique cuando la alerta ha cesado.


Qgcpu8.png Qgcpu8 1.png

Puede utilizar HTML o texto plano para definir el cuerpo del Email (Field 3) en las Palantillas de alerta.

Es casi igual, pero el campo1 no está definido, porque se usará el mismo que venga definido en la acción ejecutada previamente (al disparar la alerta). En este caso solo enviará un mail con un subject que informa que la condición en el modulo cpu_user se ha recuperado.

La recuperación de alertas es opcional. Es importante destacar que si en los datos de recuperación de la alerta, hay campos (field2 y field3) definidos, estos ignoran y sobreescriben los campos de la acción, es decir, tienen preferencia sobre ellos. El único campo válido que no se puede modificar es el campo1.

1.5 Asociando la alerta al módulo

Ya tenemos todo lo que necesitábamos, ahora sólo tenemos que asociar la plantilla de alerta al módulo. Para ello vamos a la solapa de alertas dentro del agente donde está el módulo:


Qgcpu9.png

Es sencillo, en esta captura vemos una alerta ya configurada para un módulo llamado "Last_Backup_Unixtime" asociado al mismo template que hemos definido antes "Module critical". Ahora en los controles que hay debajo, vamos a crear una asociación entre el modulo "cpu_sys" y la plantilla de alerta "Module critical". Por defecto mostrará la acción que tenemos definida en esa pantilla "Enviar email a Sancho Lerena".

1.6 Escalado de alertas

Los valores que hay en la opcion de "Number of alerts match from" son para definir el escalado de alertas. Esto permite "redefinir" un poco más el comportamiento de la alerta, de forma que si hemos definido un máximo de 5 veces las veces que se puede disparar una alerta, y sólo queremos que nos envie un email, pondremos aquí un 0 y un 1, para decirle que sólo nos envie un email desde la vez 0 a la 1 (osea, una vez).

Ahora veremos que podemos añadir más acciones a la misma alerta, definiendo con estos campos "Number of alerts match from" el comportamiento de la alerta en función de cuantas veces se dispare.

Por ejemplo, podemos querer que mande un email a XXXXX la primera vez que ocurra, y si sigue caído el monitor, envíe un email a ZZZZ. Para ello, despues de asociar la alerta, en la tabla de alertas asignadas, puedo añadir mas acciones a una alerta ya definida, tal y como podemos ver en la siguiente captura:


Qgcpu9.png


Qgcpu10.png

1.7 Alertas en Standby

Las alertas pueden estar activadas, desactivadas o en standby. La diferencia entra las alertas desactivadas y las que están en standby es que las desactivadas simplemente no funcionarán y por lo tanto no se mostrarán en la vista de alertas. En cambio, las alertas en standby se mostrarán en la vista de alertas y funcionarán pero solamente a nivel de visualización. Esto es, se mostrará si están o no disparadas pero no realizarán las acciones que tengan programadas ni generarán eventos.

Las alertas en standby son útiles para poder visualizarlas sin que molesten en otros aspectos.

1.8 Utilizando comandos de alertas distintos del email

El email, como comando es interno a Pandora FMS y no se puede configurar, es decir, field1, field2 y field3 son campos que están definidos que se usan como destinatario, subject y texto del mensaje. Pero, ¿que ocurre si yo quiero ejecutar una acción diferente, definida por mi?.

Vamos a definir un nuevo comando, algo totalmente definido por nosotros. Imaginemos que queremos generar un fichero log con cada alerta que encontremos. El formato de ese fichero log tiene que ser algo como:

FECHA_HORA - NOMBRE_AGENTE - NOMBRE_MODULO - VALOR - DESCRIPCION DEL PROBLEMA

Donde VALOR es el valor del modulo en ese momento. Habrá varios ficheros log, dependiendo de la acción que llame al comando. La acción definirá la descripcion y el fichero al que van los eventos.

Para ello, primero vamos a crear un comando como sigue:


Qgcpu11.png


Y vamos a definir una acción:


Qgcpu12.png

Si vemos el fichero de log que hemos creado:

2010-05-25 18:17:10 - farscape - cpu_sys - 23.00 - Custom alert for LOG#1

La alerta se disparó a las 18:17:10 en el agente "farscape", en el modulo "cpu_sys" con un dato de "23.00" y con la descripcion que pusimos al definir la acción.

Dado que la ejecución del comando, el orden de los campos y otros asuntos pueden hacer que no entendamos bien cómo se ejecuta al final el comando, lo más sencillo es activar las trazas de debug del servidor de pandora (verbose 10) en el fichero de configuracion de pandora server en /etc/pandora/pandora_server.conf, reiniciemos el servidor (/etc/init.d/pandora_server restart) y que miremos el fichero /var/log/pandora/pandora_server.log buscando la línea exacta con la ejecución del comando de la alerta que hemos definido, para ver como el servidor de Pandora FMS está lanzando el comando.