Pandora: Documentation es: Alertas

From Pandora FMS Wiki
Jump to: navigation, search

Volver a Indice de Documentacion Pandora FMS

Contents

1 Configuración de alertas en Pandora FMS

1.1 Introducción

Una alerta es la reacción de Pandora FMS a un valor «fuera de rango» de un módulo. Dicha reacción es configurable y puede consistir en enviar un correo electrónico o un SMS al administrador, enviar un trap SNMP, redactar el incidente en el registro del sistema, etc. Una alerta es, básicamente, cualquier acción que pueda ser desencadenada por un script configurado en el Sistema Operativo donde corre el servidor de Pandora FMS que procesa el módulo.

Existen varios tipos de alertas: las alertas simples, las alertas sobre eventos, y las alertas sobre traps SNMP. En este capítulo vamos a tratar el sistema de alerta en conjunto, y hablar en detalle de las primeras.

1.2 Introducción al sistema de alertas actual

Uno de los problemas más frecuentes y que ocasiona mayor número de quejas por parte de los usuarios es la complejidad de definir alertas en Pandora FMS. Antes, hasta la version 2.0, las alertas eran bastante más sencillas de configurar.Para cada alerta, se definía la condición y lo que hacía cuando la acción no se cumplía, para cada caso. Era más intuitivo (aun así habia campos como el alert "threshold" que daban dolores de cabeza a más de uno). Era sencillo, pero ¿merecía la pena?.

Uno de nuestros mejores usuarios (cuando digo mejor, es porque tenía muchísimos agentes instalados, y además conocía muy bien el funcionamiento de Pandora FMS), nos comentó que crear una alerta en 2000 modulos, era enormemente complicado, especialmente cuando habia que modificar algo en todas ellas. Debido principalmente a este y otros problemas, modificamos el sistema de alertas para que fuera modular, para que se pudiera separar la definición de la condición de disparo de la alerta (Alert template), de la acción a ejecutar cuando esta se dispara (Alert action) y del comando que se ejecuta dentro de la acción (Alert comnmand). La combinación de una plantilla de alerta (Alert template) con un módulo desencadena la alerta en sí.

De esta forma, si yo tengo 1000 máquinas con un modulo llamado "Host alive" y todos ellas tienen asociada una plantilla de alerta llamada "Host down" que ejecuta por defecto una acción llamada "Avisar al operador", y quiero cambiar el número mínimo de alertas que se deben disparar antes de avisar al operador, sólo tengo que hacer un cambio en la definicion de la plantilla, no ir una por una, en las 1000 alertas para modificar esa condición.

Muchos usuarios sólo gestionan algunas decenas de máquinas, pero existen usuarios con cientos, incluso miles de sistemas monitorizados con Pandora FMS, y tenemos que intentar hacer posible que con Pandora FMS se puedan gestionar todo tipo de entornos.

1.2.1 Estructura de una alerta


Esquema-alert-structure.png


Las alertas se componen de:

  • Comandos
  • Acciones
  • Plantillas

Un comando defined la operación a realizar 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 parámetros genéricos de la alertas que son: las condiciones de disparo, acciones de disparo y recuperación de la alerta.

  • Condiciones de disparo: son las condiciones bajos las que se disparará la alerta, por ejemplo: superar cierto umbral, estar en estado crítico, etc.
  • Acciones de disparo: es la configuración de las acciones que se realizarán al disparar la alerta.
  • Recuperación de alerta: es la configuración de las acciones que se realizarán cuando el sistema se recupere de la alerta.

1.2.2 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 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.


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!!!
  • Acción:
    • Field1: [email protected]
    • Field2:
    • Field3:

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.3 Comando (>=5.0)

La reacción de Pandora FMS ante un valor “fuera de rango” puede ser de diverso índole, escritura en un syslog, envío de un mail o SMS, o bien la ejecución de cualquier script que este alojado en la máquina de Pandora FMS y pueda ser procesado. Las diferentes reacciones que puede tomar Pandora se configuran en la opción Command del menú Alerts.



Susi2.png



En esta sección es posible modificar o añadir sus propios comandos para las Alertas.

1.3.1 Creación de un comando para una alerta

Los comandos de alertas nuevos se crean pinchando en el botón Create dentro de Commands en el menú Alerts.

Una vez se ha pinchado en Create aparece una pantalla como la siguiente.



Susi3 5.png



A continuación se detallan los campos:


Name

El nombre del Comando. Es importante que describa bien su función pero de forma breve, por ejemplo: «Log. Comunicaciones»..

Command

Comando que se ejecuta como reacción aun módulo “fuera de Rango”. Es posible utilizar macros para reemplazar los parámetros configurados en la declaración de las alertas. Las macros que se pueden utilizar son:

  • _field1_: Diez campos para personalizar el comando
  • _agent_: Nombre del agente completo.
  • _agentcustomfield_n_: El campo personalizado número n del agente (eg. _agentcustomfield_9_).
  • _agentcustomid_: El ID personalizado del agente.
  • _agentdescription_: Descripción del agente que disparó la alerta.
  • _agentgroup_: Nombre del grupo del agente.
  • _agentstatus_ : Estado actual del agente.
  • _agentos_ : Sistema operativo del agente.
  • _address_: Dirección del agente que disparó la alerta.
  • _all_address_: Todas las direcciones del agente que disparó la alerta. (pandora7)
  • _address_n_: La dirección del agente que corresponde a la posición indicada en "n" ejemplo: address_1_ , address_2_ (pandora7)
  • _timestamp_: Una representación estándar de fecha y tiempo (yy-mm-dd hh:mm:ss). Reemplazada automáticamente al ejecutar la alerta.
  • _timezone_: Area Nombre _timestamp_ que representa en (>=5.0SP1).
  • _data_: El valor de los datos que lanzaron la alerta.
  • _alert_description_: Descripción de la alerta.
  • _alert_threshold_: Umbral de la alerta.
  • _alert_times_fired_: Número de veces que la alerta se ha disparado.
  • _module_: Nombre del módulo que disparó la alerta.
  • _modulecustomid_: El ID personalizado del módulo.
  • _modulegroup_: Nombre del grupo del módulo
  • _moduledescription_: Descripción del módulo que disparó la alerta.
  • _modulestatus_: Estado del módulo.
  • _moduletags_: Tags asociados al módulo.
  • _alert_name_: Nombre de la alerta.
  • _alert_priority_: Prioridad numérica de la alerta.
  • _eventt_text_severity_: (Sólo en alertas de evento) Prioridad en texto de el evento que dispara la alerta. (Maintenance, Informational, Normal Minor, Warning, Major, Critical)
  • _event_id_: (Sólo en alertas de evento) el ID numérico del evento de Pandora, útil para correlaciones posteriores o validaciones externas via API/CLI.
  • _event_description_: (Sólo en alertas de evento) la descripción textual del evento de Pandora.
  • _id_agent_: ID del agente, util para construir directamente la URL o redireccionar a la consola de Pandora FMS.
  • _id_alert_: ID numérico de la alerta (único), usado con software de terceros.
  • _policy_: Nombre de la política a la que pertenece el módulo (si se da el caso).
  • _interval_: Intervalo de ejecución del módulo (segundos).
  • _plugin_param1_ - _plugin_param10_ (podria ser mas): El valor de campo de los parametros de plug-in correspondiente.
  • _plugin_param1_desc_ - _plugin_param10_desc_ (podria ser mas): La descripcion del campo de los parametros de plug-in correspondiente.
  • _groupcontact_: Información de contacto del grupo. Se configura al crear el grupo.
  • _groupcustomid_: El ID personalizado del grupo.
  • _groupother_: Otra información sobre el grupo. Se configura al crear el grupo.
  • _email_tag_: Emails asociado a tags de módulos.
  • _phone_tag_: Telefono asociado a tags de módulos.
  • _alert_critical_instructions_: Instrucciones contenidas en el módulo para un estado CRITICAL.
  • _alert_warning_instructions_: Instrucciones contenidas en el módulo para un estado WARNING.
  • _alert_unknown_instructions_: Instrucciones contenidas en el módulo para un estado UNKNOWN.


A la hora de crear los comandos para las alertas hay que tener en cuenta que dichos comandos son ejecutadas por el servidor de Pandora FMS que procesa el módulo del agente procesado. Sea este un servidor de datos o un servidor de red. Las alertas también se ejecutan con los privilegios del usuario que ejecuta el servidor de Pandora FMS. A la hora de definir un comando, conviene probar, desde la línea de comandos, que la ejecución del comando tiene éxito y que produce el resultado deseado (enviar un correo electrónico, generar una entrada en un fichero de registro, etc).

Description

Descripción larga del comando de alerta a título informativo.

Descripción de los campos y posibles valores

Para cada campo, es posible configurar:

  • Descripción: Será la etiqueta junto a la caja de texto en el formulario de configuración de la acción que use este comando.
  • Valores posibles: Una colección de posibles valores para ese campo.

Si este campo está configurado (no está vacío), el campo será un combo de selección en lugar de una caja de texto. El combo necesita para cada posible valor una etiqueta (la opción visible) y un valor (la opción enviada).

La sintaxis es la siguiente:

valor1,etiqueta1;valor2,etiqueta2;valor3,etiqueta3

Por ejemplo:

Un campo sencillo donde será posible elegir entre los cuatro primeros números:

1,Numero uno;2,Numero dos;3,Numero tres;4,Numero cuatro



Possible values 1.png





Possible values 2.png



Info.png

A partir de la versión 6.0, será posible mostrar un editor HTML en un campo del comando en la creación o edición de una acción de una alerta si ese campo del comando tiene como valor el token especial _html_editor_

 


Una vez creado se pincha en el botón Create.



Susi4 5.png



1.3.2 Edición de un comando para una alerta

Desde Command en el menú Alerts, es posible editar los comandos de alertas que se han creado.



Susi5.jpg


Para editar el comando de una alerta bastará con pulsar sobre el nombre del comando.



Susi6 5.png



Una vez se ha modificado la alerta elegida se pincha en botón de Update.

Las Alertas ”eMail”, “Internal Audit” y “Pandora FMS Event” no se pueden modificar.

1.3.3 Borrado de un comando para una alerta

Para borrar una alerta se pincha en la papelera gris situada a la derecha de la alerta.



Susi7.png



Las alertas ”eMail”, “Internal Audit” and “Pandora FMS Event” no pueden ser borradas.

1.3.4 Comandos predefinidos

Existen algunas Comandos predefinidos, los cuales es posible que se deban ajustar, si el sistema no dispone de los comandos internos para ejecutar dichas alertas. El equipo de desarrollo ha probado estas alertas con sistemas Red Hat Linux, CentOS, Debian y Ubuntu Server.

eMail

Envía un correo electrónico desde el servidor de Pandora FMS. Usa el sendmail de Perl. Pandora FMS funciona con herramientas propias del sistema para ejecutar casi todas las alertas, será necesario que valide que el paquete libmail-sendmail-perl xprobe2 está instalado en su sistema.

A partir de la versión 6.0, esta acción envía los email en formato HTML, lo cual permite crear plantillas muy atractivas visualmente. Hay que tener en cuenta que el receptor debe poder acceder a los recursos utilizados en la plantilla, como las imágenes.

Internal audit

Esta es sólo una alerta «interna» que genera una pequeña entrada en el sistema de auditoría interno de Pandora FMS. Este se almacena en la base de datos de Pandora FMS y puede revisarse con el visor de eventos desde la consola.

Pandora FMS Event

Esta alerta crea un evento especial en el gesto de eventos de Pandora FMS.

Pandora FMS Alertlog

Es una alerta predefinida que escribe las alertas en ASCII plano en el fichero de log /var/log/pandora/pandora_alert.log

SNMP Trap

Envía un trap SNMP.

Syslog

Envía una alerta al registro del sistema, usa el comando del sistema «logger».

Sound Alert

Reproduce un sonido cuando ocurre una alerta.

Jabber Alert

Envía una alerta jabber a una sala de chat en un servidor predefinido (configurar primero el fichero .sendxmpprc). En field3 va el mensaje de texto, en field1 el alias de usuario, y en field2 el nombre de la sala de chat.

SMS Text

Envía un SMS a un teléfono móvil determinado, por supuesto, necesita definir una alerta antes de hacer esto posible y una puerta de enlace (gateway) de envío de SMS configurado y accesible desde el servidor de Pandora FMS. También se puede instalar uno utilizando Gnokii para envío de SMS, directamente usando un teléfono Nokia con un cable USB. Se describe el proceso más adelante.

Validate Event

Valida todos los eventos relacionados con un módulo. Se le pasará el nombre del agente y el nombre del módulo.

1.3.5 Ejemplos de Comandos

1.3.5.1 Envío de alertas con Jabber

Es muy útil configurar Pandora FMS para que envíe alertas a un servidor Jabber. Jabber puede ser un sistema para tener alertas en tiempo real que permanezca como histórico y que permita recibirlas a un grupo simultáneo de gente.

1.3.5.1.1 Instalación de los servicios Jabber

En el lado cliente:

  1. Instalar un cliente Jabber, por ejemplo Gaim (ahora Pidgin).
  2. Registrar una cuenta (en Pidgin: configurar una cuenta, pulsando en el botón de registro de cuenta).
  3. Iniciar sesión con la cuenta.

En la parte del servidor de Pandora FMS:

  1. Instalar sendxmpp. Con esta herramienta se pueden enviar mensajes Jabber.
  2. Crear un fichero en el directorio /home con el nombre .sendxmpprc.
  3. Editar el fichero e introduzca lo siguiente:
  [email protected] password
  1. Darle permisos al fichero:
  chmod 0600 .sendxmpprc

Ahora se pueden enviar mensaje privados a través de línea de comandos, por ejemplo:

  $ echo "Hello" | sendxmpp -s pandora [email protected] 

Para dar de alta la alerta en la consola de Pandora FMS, se añade una nuevo comando, y se configuran las variables del comando de la manera que más convenga. Es buena idea hacerlo como sigue:

  • Field_1: Direccion de jabber.
  • Field_2: Texto de envío.

De forma que a alerta se definiría como:

  echo _field2_ | sendxmpp -s pandora _field1_
1.3.5.1.2 Más ejemplos de uso con Jabber

Enviar a una sala de chat:

  $ echo "Dinner Time" | sendxmpp -r TheCook --chatroom [email protected]

Enviar las líneas del registro según aparecen a un destino Jabber:

  $ tail -f /var/log/syslog | sendxmpp -i [email protected]

NOTA: Tenga cuidado de no sobrecargar servidores Jabber públicos o le cortarán el acceso.

1.3.5.2 Envío de correo electrónico con expect

A veces se necesita usar un SMTP autenticado para enviar correos electrónicos. Seguramente sea más fácil y versátil usar un sencillo script EXPECT en lugar de configurar sendmail para usar un SMTP autenticado. Este es un ejemplo usando EXPECT para enviar correos electrónicos usando un servidor Exchange.

Se crea un archivo llamado /etc/snmp con el siguiente contenido:

#!/usr/bin/expect -f
set arg1 [lindex $argv 0] 
set arg2 [lindex $argv 1]
set arg3 [lindex $argv 2]
set timeout 1 
spawn telnet myserver.com 25 
expect "220"
send "ehlo mymachine.mydomain.com\r"
expect "250"
send "AUTH login\r"
expect "334"
send "2342348werhkwjernsdf78sdf3w4rwe32wer=\r"
expect "334"
send "YRejewrhneruT==\r"
expect "235"
send "MAIL FROM: [email protected]\r"
expect "Sender OK"
send "RCPT TO: $arg1\r"
expect "250"
send "data\r"
expect "354"
send "Subject: $arg2\r"
send "$arg3 \r\r"
send ".\r"
expect "delivery"
send "quit"
quit

Se cambian los permisos del fichero, para permitir la ejecución

chmod 700 /root/smtp 

Antes de intentar usarlo, asegúrese de que /usr/bin/expect funcione correctamente.

Para usar esto con Pandora FMS, necesitará crear una comando nuevo (o modificar el existente de envío de alertas por correo electrónico) y especificar los siguientes campos en la definición de comandos de Alerta de Pandora FMS, en el campo “Command” se escribirá:

/root/smtp _field1_ _field2_ _field3_

Por supuesto el script puede estar ubicado en cualquier sitio del sistema. Sólo debe tener en cuenta que el script de alerta es lanzado por el servidor que procesa el dato: si es un dato de red será el servidor de red, si es un dato que viene desde un agente, a través de un fichero de datos XML, entonces será el servidor de datos quién lo lance.

Si tiene diferentes servidores físicos, puede que necesite copiar el mismo script en la misma ubicación, con los mismos permisos y el mismo propietario de usuario en todos los sistemas donde tenga un servidor Pandora FMS que quiera que ejecute esa alerta. Tenga también en cuenta que los servidores de red de Pandora FMS necesitan ejecutarse como root (para poder hacer pruebas de latencia ICMP) y los servidores de datos pueden ejecutarse con un usuario sin privilegios.

La alerta será ejecutada por el usuario que esté ejecutando el proceso del servidor de Pandora FMS.

1.3.5.3 Envío de SMS con Gnokii

Para poder utilizar Gnokii es necesario usar un móvil Nokia o compatible con Gnokii (revise el hardware compatible en la página del proyecto Gnokii. También necesitará un cable de datos USB al que tendrá que conectar el teléfono móvil y el servidor de Pandora FMS que quiera que envíe alertas SMS.

Gnokii soporta una gran variedad de teléfonos Nokia (y alguno de otros fabricantes).

Con Gnokii, básicamente puede enviar SMS desde la línea de comandos. De esta forma es muy fácil y rápido enviar SMS directamente desde un servidor de Pandora FMS, evitando el uso de puertas de enlace de envío de SMS por internet (no muy útiles si se cae la red) o soluciones hardware GSM muy caras para envío de mensajes.

Otra alternativa al uso de Gnokii es el proyecto Gammu.

Ejemplo de envío de un SMS con Gnokii desde línea de comandos:

echo "PANDORA: Server XXXX is down at XXXXX" | gnokii --sendsms 555123123

Gnokii no puede enviar MMS con imágenes adjuntas, pero sí puede enviar un URL HTTP/WAP para que se visualice al recibir un mensaje, por ejemplo:

echo "Image capture sample" | gnokii --sendsms 555123123 -w http://artica.homelinux.com/capture.jpg

Puede enviar una URL de una imagen, o una URL que lleve a una versión ligera de la consola para acceder a la consola desde el dispositivo móvil y analizar los datos.

El equipo de desarrollo ha probado el envío de SMS desde un teléfono Nokia 6030, enviando alertas SMS cuando la conexión a internet estaba inaccesible. El Nokia 6030 utiliza la definición del módulo 6510 en el fichero gnokiirc, y tarda más o menos cuatro segundos en enviar un SMS.

Se puede implementar una pasarela de envío más potente utilizando Gammu.

1.3.5.4 Ejecución de un comando remoto en otro sistema (UNIX)

En algunas ocasiones es interesante ejecutar un comando en otro sistema, para ello se usa el comando ssh. El sistema en el que se ejecutará el comando debe de ser UNIX y tener el demonio ssh instalado, levantado y accesible.

Para evitar tener que el password de acceso a la maquina que ejecutara el comando en Pandora Console, lo primero que se debe hacer es copiar la clave publica del servidor donde se quiere ejecutar el comando remoto en el servidor de Pandora.

Una vez se ha hecho esto tenemos que poner como comando:

ssh [email protected] [_field1_]

Al poner _field1_copmo variable se puede usar el comando que se quiera.

1.4 Acción (>=5.0)

Las acciones son los componentes de las alertas en los que se relaciona un comando, descrito en el apartado anterior, con las variables genéricas Field 1, Field 2, ..., Field 10. Dichas acciones se usaran más adelante en las plantillas de alertas que son las que asocian una condición sobre un dato a una acción concreta.

1.4.1 Creación de una Acción

Las Acciones nuevas se crean pinchando en el botón Create dentro de Action en el menu Alerts.



Accion1.jpg



Una vez se ha pinchado en Create aparece una pantalla como la siguiente:



Accion2.jpg



A continuación se detallan los campos que hay que rellenar:

  • Name: El nombre de la acción.
  • Group: El grupo de la acción.
  • Command: En este campo se define el comando que se usará en el caso de que se ejecute la alerta. Se puede elegir entre los difeerntes Comandos que hay definidos en Pandora.
  • Threshold: El umbral de ejecución de la acción.
  • Command Preview: En este campo, no editable, aparecerá automáticamente el comando que se va a ejecutar en el sistema.
  • Field 1-10: En estos campos se define el valor de las macros _field1_ a _field10_, que se usarán en el comando, en caso de ser necesario. Estos campos pueden ser un campo de texto o un combo de selección si se configura

Una vez se han rellenado los campos se pincha en el Botón Create



Boton1.jpg



Desde Actions en el menú Alerts, es posible editar las acciones que se han creado.

1.4.2 Editar una Acción



Caca1.png



Para editar la acción, sólo tiene que hacer click en el nombre de la Acción.



Sugus.png



Una vez se hayan hecho estos cambios, actualízelos haciendo click en el botón "Actualizar".

1.4.3 Borrar una acción

Para borrar una Acción, haga click en el icono gris que es un cubo de basura situado a la derecha de Acción.




Sipo.jpg



1.5 Plantilla de alerta

Las plantillas son alertas con todos los parámetros definidos en las que sólo falta por asignar el agente al que se le asignan y el módulo que se usa para hacer saltar el comando o reacción ante un valor “fuera de rango”. Las plantillas sirven para facilitar la gestión de los administradores ya que una vez hechas se pueden asignar de forma sencilla a los agentes necesarios.

1.5.1 Creación de una Plantilla

Las Plantillas nuevas se crean pinchando en el botón Create dentro de Templates, en el menu Manage Alerts, en el menú de Administración.
Desde la 6.0: Las Plantillas nuevas se crean pinchando en el botón Create dentro de Templates, en el menu Alerts.



Planti.jpg



Una vez se ha pinchado en Create, aparece una pantalla como la siguiente.



Sabo.jpg



A continuación se detallan los campos que hay que rellenar:

  • Name: El nombre del template.
  • Description: Describe la función de la plantilla, y resulta útil para identificar la plantilla entre otras en la vista general de alertas..
  • Priority: Campo informativo acerca de la alerta. Sirve para filtrar a la hora de buscar alertas. Se puede elegir entre las siguientes prioridades:
    • Maintenance
    • Informational
    • Normal
    • Warning
    • Critical

Damos a Next y encontramos una nueva ventana:

Sabo800.jpg

A continuación se detallan los campos que hay que rellenar:

  • Condicion Type: Campo donde se define el tipo de condición que se aplicará a la alerta. Se añadirán los combos necesarios según el tipo elegido, existen los siguientes tipos:
  • Regular Expresion: Se usa una expresión regular. La alerta saltara cuando el valor del módulo cumpla una condición establecida.



Regular.jpg



Al elegir la condición regular aparece la posibilidad de marcar la casilla Trigger when matches the value. En caso de marcar, la la alerta se lanzará cuando coincida el valor y, en caso de no marcarla, la alerta se lanzará cuando no coincida el valor.

  • Max and Min: Se usa un valor máximo y otro mínimo.



Maximo.jpg



Al alegir la condición regular aparece la posibilidad de marcar la casilla Trigger when matches the value. En caso de marcarla, la alerta se lanzará cuando el valor este fuera del rango marcado entre el máximo y el mínimo y, en caso de no marcarla, la alerta se lanzará cuando el valor este dentro del rango marcado entre el máximo y el mínimo.

  • Max: Se usa un valor máximo. La alerta saltara cuando el valor del módulo sea mayor que el valor máximo marcado.



Minimo.jpg



  • Min: Se usa un valor mínimo. La alerta saltara cuando el valor del módulo sea menor que el valor mínimo marcado.



Minimo1.jpg



  • Equal to: Usado para disparar la alerta cuando se proporciona un valor de debe ser igual al dato recibido. Esta condición, igual que las de max/min se usa sólo para valores numéricos, p.e: 234 o 124.35.



Equal.jpg



  • Not Equal to: Igual que el anterior pero negando la condición (operador lógico NOT).



Notequal.jpg



  • Warning Status: Se usa el estado del módulo. La alerta saltará cuando dicho estado sea Warning.



Estupido.jpg



  • Critical Status: Se usa el estado del módulo. La alerta saltará cuando dicho estado sea Critical.



Critical.jpg




Days of Week

Establece los días en los que la alerta podrá dispararse.

Use special days list

Habilitar/deshabilitar el uso de la lista de días especiales (festivos y días laborables especiales).

Time From

Hora a partir de la cual se ejecuta la acción de la alerta.

Time To

Hora hasta la que se ejecuta la acción de la alerta.

Time Threshold

Define el intervalo de tiempo en el cual se garantiza que una alerta no se va a disparar más veces del número establecido en Numero máximo de alertas. Pasado el intervalo definido, una alerta se recupera si llega un valor correcto, salvo que esté activado el valor Recuperación de alerta, en cuyo caso se recupera inmediatamente después de recibir un valor correcto independientemente del umbral.

Min number of alerts

Número mínimo de veces que tiene que llegar un valor fuera de rango (contando siempre a partir del número definido en el parámetro FlipFlop del módulo) para empezar a disparar una alerta. El valor por defecto es 0, lo que significa que la alerta se disparará cuando llegue el primer valor que cumpla la condición. Funciona como un filtro, necesario para eliminar falsos positivos.

Max number of alerts

Máximo número de alertas que se pueden enviar consecutivamente en el mismo intervalo de tiempo (Time Threshold).

Field 1

Define el valor para la variable "_field1_". Aqui se pueden utilizar una serie de macros que se describen a continuación.

Field 2

Define el valor para la variable "_field2_".

Field 3

Define el valor para la variable "_field3_".

Default Action En este combo se define la acción por defecto que va a tener el template. Esta es la accion que se creará automáticamente cuando asigne la plantilla al módulo. Puede no poner ninguna o poner una, pero no se pueden poner varias acciones por defecto

Una vez se han rellenado los campos se pincha en el botón “Next” y se accede a la siguiente pantalla .



Combo.jpg



A continuación se detallan los campos que hay que rellenar:

Alert Recovery

Combo donde se puede definir si esta habilitado o no la recuperación de alertas. En el caso de que esté habilitada la recuperación de alertas, cuando el módulo vuelve a tener valores fuera del rango de alerta, se ejecutará la acción correspondiente con el campo Field 1 que se ha definido en la alerta y los campos desde Field 2 hasta Field 10 que se definen a continuación.

Field 2

Define el valor para la variable "_field2_". en la recuperación de la alerta.

Field 3

Define el valor para la variable "_field3_". en la recuperación de la alerta.

Una vez se han rellenado los campos se pincha en el botón “Finish”.

1.5.2 Macros sustituibles en los campos Field1, Field2, Field3... Field10

En todas las instancias de los campos field1, field2... field10' (tanto en la plantilla de alerta, como en el comando y en la acción) se pueden emplear las siguientes macros, que son "palabras" que son reemplazadas en el momento de ejecución por un valor, que varía en función del momento, valor, agente que dispara la alerta, etc.

  • _field1_: Campo 1 definido por el usuario.
  • _field2_: Campo 2 definido por el usuario.
  • _field3_: Campo 3 definido por el usuario.
  • _field4_: Campo 4 definido por el usuario.
  • _field5_: Campo 5 definido por el usuario.
  • _field6_: Campo 6 definido por el usuario.
  • _field7_: Campo 7 definido por el usuario.
  • _field8_: Campo 8 definido por el usuario.
  • _field9_: Campo 9 definido por el usuario.
  • _field10_: Campo 10 definido por el usuario.
  • _agent_: Nombre del agente que disparó la alerta.
  • _agentcustomfield_n_: Campo personalizado número n del agente (eg. _agentcustomfield_9_).
  • _agentcustomid_: ID personalizado del agente.
  • _agentdescription_: Descripción del agente que disparó la alerta.
  • _agentgroup_: Nombre del grupo del agente.
  • _agentstatus_: Estado actual del agente.
  • _agentos_: Sistema operativo del agente.
  • _address_: Dirección del agente que disparó la alerta.
  • _agentgroup_: Nombre del grupo del agente.
  • _timestamp_: Hora y fecha en que se disparó la alerta.
  • _timezone_: Nombre de zona horaria que el servidor de supervision se ejecuta en (>=5.0SP1).
  • _data_: Dato que hizo que la alerta se disparase.
  • _alert_description_: Descripción de la alerta.
  • _alert_threshold_: Umbral de la alerta.
  • _alert_times_fired_: Número de veces que se ha disparado la alerta.
  • _module_: Nombre del módulo.
  • _modulecustomid_: ID personalizado del módulo.
  • _modulegroup_: Nombre del grupo del módulo.
  • _moduledescription_: Descripcion del modulo.
  • _modulestatus_: Estado del módulo.
  • _alert_name_: Nombre de la alerta.
  • _alert_priority_: Prioridad numérica de la alerta.
  • _alert_text_severity_: Prioridad en texto de la alerta (Maintenance, Informational, Normal Minor, Warning, Major, Critical).
  • _eventt_text_severity_: (Solo alertas de evento) Prioridad en texto de el evento que dispara la alerta (Maintenance, Informational, Normal Minor, Warning, Major, Critical).
  • _event_id_: (Solo alertas de evento) Id del evento que disparó la alerta.
  • _event_description_: (Sólo en alertas de evento) la descripción textual del evento que disparó la alerta.
  • _id_agent_: ID del agente, util para construir URL de acceso a la consola de Pandora.
  • _id_group_: El ID del grupo del agente. (>=5.1SP4)
  • _id_alert_: ID de la alerta, util para correlar la alerta en herramientas de terceros.
  • _policy_: Nombre de la política a la que pertenece el módulo (si aplica).
  • _interval_: Intervalo de la ejecución del módulo.
  • _target_ip_: Dirección IP del objetivo del módulo.
  • _target_port_: Puerto del objetivo del módulo.
  • _groupcontact_: Información de contacto del grupo. Se configura al crear el grupo.
  • _groupcustomid_: ID personalizado del grupo.
  • _groupother_: Otra información sobre el grupo. Se configura al crear el grupo.
  • _name_tag_: Nombre de los tags asociados al módulo.
  • _email_tag_: Emails asociados a los tags de módulos.
  • _phone_tag_: Teléfonos asociados a los tags de módulos.
  • _moduletags_: URLs asociadas a los tags de módulos.
  • _plugin_parameters_: Parámetros del plugin del módulo.
  • _alert_critical_instructions_: Instrucciones contenidas en el módulo para un estado CRITICAL.
  • _alert_warning_instructions_: Instrucciones contenidas en el módulo para un estado WARNING.
  • _alert_unknown_instructions_: Instrucciones contenidas en el módulo para un estado UNKNOWN.
  • _modulegraph_nh_: (>=6.0) (Solo para alertas que usen el comando eMail) Devuelve una imagen codificada en base64 de una gráfica del módulo con un período de n horas (eg. _modulegraph_24h_). Requiere de una configuración correcta de la conexión del servidor a la consola vía api, la cual se realiza en el fichero de configuración del servidor.
  • _homeurl_: Es un link de la URL pública esta debe de estar configurada en las opciones generales del setup.

1.5.2.1 Orden de la sustitución de las macros y los campos _field*_

Después de describir lo que es un comando, una acción y una plantilla, probablemente a estas alturas ya se esté preguntando porqué hay que definir en cada una de ellas, los campos field1, field2, field3... field 10 y qué sentido tiene todo esto.

Cuando se dispara una alerta, los valores field* se acarrean desde la acción al comando, y desde la plantilla al comando. Es decir, si en la acción el valor _field1_ es diferente de cadena vacía, entonces ignorará el valor que se le pase desde la plantilla, y esta no tendrá efecto. Si en el valor _field1_ del comando, es un valor diferente de _field1_ significa que directamente ignorará cualquier parámetro que se la pase en el campo1 (field1) desde la acción o desde la plantilla, y que ni la acción ni la plantilla podrán redefinirlo. Al tener como valor _field1_, significa que se le está diciendo al comando, que meta en ese campo, lo que le llegue desde la acción o desde la plantilla.

En la acción ocurre lo mismo, pero de una forma más sutil. Si ese campo está vacío, significa que cualquier cosa que se le pase desde la plantilla de alerta, se le pasará al comando, sin embargo, si ese campo es diferente de cadena vacía, utilizará los valores de ese campo y se ignorarán los valores que vengan desde la plantilla.

Esto se ha concebido así para dar la posibilidad de establecer algunos parámetros "fijos" por comando o acción, y tener siempre la posibilidad de hacerlos flexibles.

1.5.2.2 Ejemplo completo de alerta con reemplazamiento de macros

Suponiendo que usted desee crear una entrada en un LOG donde en cada línea aparezca el siguiente formato:


2009-12-24 00:12:00 pandora [CRITICAL] Agent <agent_name> Data <module_data> Module <module_name> in CRITICAL status

Command Configuration

echo _timestamp_ pandora _field2_ >> _field1_

Action Configuration

Field1 = /var/log/pandora/pandora_alert.log
Field2 = <En blanco>
Field3 = <En blanco>

Template Configuration

Field1 = <En blanco>
Field2 = [CRITICAL] Agent _agent_ Data _data_ Module _module_ in CRITICAL status
Field3 = <En blanco>

En la sección de recuperación:

Field2 = [RECOVERED] [CRITICAL] Agent _agent_ Data _data_ Module _module_ in CRITICAL status
Field3 = <En blanco>

De este modo, al ejecutar una alerta, la siguiente línea se colocará en el LOG:

2009-10-13 13:37:00 pandora [CRITICAL] Agent raz0r Data 0.00 Module Host Alive in CRITICAL status

Y la siguiente línea para recuperar la alerta:


2009-10-13 13:41:55 pandora [RECOVERED] [CRITICAL] Agent raz0r Data 1.00 Module Host Alive in CRITICAL status

1.5.3 Editar una Plantilla

Es posible editar las plantillas que han sido creadas desde Plantillas en el menu de gestión de Alertas.




Plantilla.jpg



Para editar la plantilla sólo necesita hacer click en el nombre de la plantilla.

1.5.4 Eliminar una plantilla

Para eliminar una plantilla, haga click en el icono de papelera gris situado a la derecha de la alerta.




Cruz.jpg



1.6 Asignar Plantillas de alerta a los módulos

Hasta aquí, hemos definido los comandos y acciones como la respuesta que Pandora FMS da para un valor "fuera de rango".Mediante estas plantillas definimos cuando un valor está "fuera de rango" y que circunstancias deberían darse para que Pandora FMS pueda funcionar. En esta sección se describe la manera de relacionar las plantillas y las acciones con los agentes de Pandora y con los módulos de esos agentes. Esta operación es la única que finalmente hace que Pandora FMS "reaccione" cuando hay una fecha fuera de un rango específico.

Las alertas pueden ser asignadas de dos maneras desde el submenú de Alertas o desde el submenú de gestión de alertas, ambos en el menú de Administración, pero también podemos asignarlas desde el Submenú de políticas de Administración, tal como veremos en la sección de Monitorización con políticas.

1.6.1 Gestión de Alertas desde el submenú de Alertas

1.6.1.1 Asignación de Alertas desde el submenú de Alertas

La asignación de alertas para módulos se hace rellenando los campos requeridos y haciendo click en List of Alerts, en la pantalla que nos sale hacemos click arriba a la derecha sobre el lapicero (Builder alert).



Pinar.jpg



Estos son los campos que deberían rellenarse:

  • Group:Mediante un combo puede escoger el grupo al que el agente pertenece.
  • Agent:Escribiendo el nombre del Agente para asignarle la alerta.
  • Module: Escribiendo el módulo que se utilizará para que se pueda disparar la alerta.
  • Template: Mediante un combo puede seleccionar la plantilla que quiere utilizar para configurar la alerta.
  • Actions: Permite escoger entre todas las alertas que han sido configuradas. Las acciones seleccionadas pueden añadirse a la acción que se ha definido en la plantilla. Es posible escoger más de una acción.
  • Threshold: Una acción de alerta no será ejecutada más de una vez cada action_threshold segundos, a pesar del número de veces que la alerta sea disparada.

1.6.1.2 Modificar alertas desde el Submenu de Alertas

Una vez que se ha creado una alerta, es sólo posible modificar las acciones que se han añadido a la acción que tiene la plantilla.

Es también posible suprimir la acción que fue seleccionada cuando has creado la alerta haciendo click en el icono de papelera gris que está a la derecha de la acción, o añadir nuevas acciones haciendo click en el botón "Añadir".




Modifica.jpg



1.6.1.3 Desactivar Alertas desde el Submenú de Alertas

Una vez se ha creado la alerta, es posible desactivarla haciendo click en el icono de bombilla que está a la derecha del nombre de la alerta.



Desha.jpg



Las alertas que están disponibles están en azul y las alertas que no están disponibles están en amarillo.

1.6.1.4 Eliminar Alertas desde el submenú de Alertas

Es posible eliminar cualquier alerta haciendo click en el icono de basura gris que está situado a la derecha de la alerta.



Filter.jpg



1.6.2 Gestionar alertas desde el agente

1.6.2.1 Asignación de alertas desde el Agente

Otra opción para añadir una alerta es hacerlo desde el agente.Haga click en Administración >> Gestionar monitorización>> Gestionar Agentes, donde están todos los agentes de Pandora.
Pandora 6.0: Otra opción para añadir una alerta es hacerlo desde el agente.Haga click en Resources >> Manage Agents, donde están todos los agentes de Pandora.




Tarantu.jpg



Seleccionar un agente y hacer click en la caja de Alertas.



Vicho.jpg



Ahora vamos a detallar los campos que deberían rellenarse:

  • Module: Para escribir el módulo que se usará para lanzar las alerta.
  • Template: Mediante un combo, puede seleccionar la plantilla que desea para configurar la alerta.
  • Actions: Permiten escoger entre todas las acciones que han sido configuradas. La acción elegida se añadirá a la acción que es definida en la plantilla.Es posible seleccionar más de una acción.
  • Threshold: La acción de una alerta no será ejecutada mas de una vez cada tantos segundos de action_threshold,sin tener en cuenta el número de veces que la alerta sea disparada

1.6.2.2 Modificar alertas desde el Agente

Una vez que la alerta ha sido creada,sólo es posible modificar las acciones que han sido añadidas a la acción que tiene la plantilla. Es posible eliminar la acción que se seleccionó para crear la alerta haciendo click en la cruz roja que está a la derecha de la acción, o bien añadiendo nuevas acciones haciendo click en el botón "Añadir".




Gusano.jpg



1.6.2.3 Desactivar alertas desde el Agente

Una vez que una alerta ha sido creada, será posible desactivarla haciendo click en el icono de bombilla que está a la derecha del nombre de la alerta.



Cuca.jpg



Las alertas que están disponibles están en azul, y las alertas que no están disponibles están en amarillo.

1.6.2.4 Eliminar alertas desde el Agente

Es posible eliminar cualquier Alerta haciendo click en el icono gris de papelera que está a la derecha de la Alerta.




Adorno.jpg



1.7 Definiendo una Alerta

Bien, ahora vamos a ponernos en el caso anterior. Tenemos una necesidad: monitorizar un módulo que contiene valores numéricos. En nuestro caso, es un modulo que mide la CPU del sistema, en otro caso puede ser un sensor de temperatura, que engrega el valor en grados centígrados. Veamos primero que nuestro módulo recibe datos correctamente:


Qgcpu1.png

Bien. En esta captura vemos que tenemos un modulo llamado sys_cpu 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 Critical Status como vemos en la captura siguiente:


Qgcpu3.png

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. Asi que ya lo tenemos.

1.8 Configurando la acción

Ahora tenemos que crear una acción que sea "Enviar un email al operador". Vamos a ello: Menú de Alertas -> Acciones 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.9 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 a ello: Vamos al menú de Alertas -> Templates y le damos al botón para crear una nueva plantilla (template) de alerta:


Qgcpu6.png

Lo que define la condición es el campo "Condition", 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 valga 20 o más.

La prioridad definida aqui "Critical" es la prioridad de la alerta, que no tiene que ver con el estado "Critico" del módulo. Las criticidades de las alertas son para visualizarlas luego, en otras vistas, como la vista de eventos, con diferentes criticidades.

Pasemos al paso 2, pulsando el boton "next":


Qgcpu7.png

El paso 2 define todos los "valores" de configuración "finos" de la plantilla de alerta, de la condición de disparo. Algunos de ellos, los primeros, son bastante sencillos, restringen el momento de actuación de esta alerta a ciertos días entre diferentes horas.

Los parámetros más críticos aquí son los siguientes:

  • Time threshold: Por defecto es un día. Si un módulo permanece todo el rato caído, durante, por ejemplo 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, cuando se caiga. Si el modulo se recupera, y luego se vuelve a caer, nos enviará una alerta de nuevo, pero si sigue caída desde la 2º caida, 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 me ejecute las acciones asociadas a la plantilla de alerta. Es una forma de evitar que falsos positivos me "inunden" a alertas, 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-campo10". 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). Los demás campos aparecen en blanco. 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_user 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, a no ser que la modifique.

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


Qgcpu8.png

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.10 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

Hemos creado una asociación entre el modulo "cpu_user" y la plantilla de alerta "Critical condition". Por defecto mostrará la acción que tenemos definida en esa pantilla "Enviar email a XXX".

Template warning.png

Para la auto validación de alertas de los módulos en desconocido habrá que habilitar 'Generar eventos desconocidos' dentro de las opciones avanzadas del módulo correspondiente.


Geventos.jpg

 


1.11 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


Cuando una alerta se recupera, todas las acciones que se hayan ejecutado hasta ese momento se volverán a ejecutar, no sólo las que correspondan a la configuración de "Number of alerts match from" actual.

1.12 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.13 Protección en cascada

La protección en cascada es una característica de Pandora FMS que permite evitar una "lluvia" de alertas cuando un grupo de agentes no es accesible, debido a una conexión principal que falla. Este tipo de cosas ocurren cuando un elemento de la red intermedio como un router o un switch fallan, y se deja inaccesible a una gran parte de la red gestionada con Pandora FMS. Probablemente vaya todo bien, pero como Pandora FMS no puede verlos, los considera como caídos o en estado desconocido, lo cual puede generar de repente una gran cantidad de eventos/alertas.



Recursive cascade protection ilustration.png



La protección en cascada se activa desde la configuración del agente. Haga click en la opcion "proteccion en cascada".



Down1.jpg



Cuando la protección en cascada se activa en el agente, las alertas con estado CRITICO son contrastadadas antes de ejecutarse en ese agente, esto significa, que no se disparará si el agente "padre" de ese agente tiene algún módulo en estado "CRITICO" que tenga una alerta disparada. Solo se dispararán cuando el padre (y el padre de este y así sucesivamente) están en estado NORMAL en todos sus modulos/alertas. Eso no aplica a alertas sobre estados WARNING o UNKNOWN en el padre, que no serán tenidas en cuenta.

Para que la protección en cascada funcione bien, es conveniente configurar en todos los padres una alerta asociado a la condición CRITICAL en al menos un módulo, para poder evitar que si se disparara, no generaría alertas ninguno de los hijos de ese agente.

1.13.1 Ejemplos

Tiene los siguientes agentes:

- ROUTER: modulo ICMP check y modulo de SNMP check, usando un OID estándard para verificar el estado de un puerto ATM. Podemos tambien verificar la latencia contra el router de nuestro proveedor.

- WEB SERVER: tiene varios modulos ejecutados por el agente: CPU, Memoria, verificacion del proceso apache. Tambien tiene un chequeo de latencia WEB de cuatro pasos.

- DATABASE SERVER: tiene varios modulos ejecutados por el agente: CPU, Memoria, verificacion del proceso MySQL. Ademas tiene algunos chequeos adicionales de integridad de la BBDD Tambien tiene verificacion de la conectividad remota a otra base de datos, usando un plugin específico que se logea, hace una query y sale, midiendo el tiempo total.

En WEB SERVER y en DATABASE SERVER, definimos como padre a ROUTER. Activamos la casilla de cascade protection en WEBSERVER y DATABASE SERVER.

Ahora definimos varias alertas sencillas:

-ROUTER:

SNMP Check / CRITICAL -> Action, send MAIL. Latency > 200ms / WARNING -> Action, send MAIL.

-WEB SERVER

CPU / WARNING MEM / WARNING PROCESS / CRITICAL -> Action, send MAIL. HTTP LATENCY / CRITICAL -> Action, send MAIL.

-DATABASE SERVER

CPU / WARNING MEM / WARNING PROCESS / CRITICAL -> Action, send MAIL. SQL LATENCY / CRITICAL > Action, send MAIL.

Si se cae la conexion del ROUTER, que es a través de donde pandora se conecta a WEB SERVER y DATABASE; sin activar la protección en cascada, recibiría seis alertas, trate de imaginar el efecto que ocasionaría esto si en vez de dos servidores, tiene doscientos. A este efecto se le conoce por "tormenta de eventos", en el peor escenario, puede tumbar su servidor de correo, el servidor de monitorización y su propio movil, inundándolo de SMS's.

Si tiene la protección en cascada, solo recibiría una alerta, diciendo que la interfaz ATM del router está caida. Sin embargo yo vería los elementos de WEBSERVER y DATABASE SERVER en rojo, pero no me llegarían las alertas.

1.14 Lista de días especiales (Versiones <=6.0)

Desde la versión 5.0, Pandora FMS tiene una funcionalidad para días especiales. Esta permite definir vacaciones y dias especiales de trabajo para las plantillas de alerta. Los días definidos en la lista de días especiales son tratados como el mismo día de la semana que se escogió.


1.14.1 Crear un día especial

Pandora 6.0: Los dias nuevos especiales se crean haciendo click en le botón de crea de la lista de días especiales, en el Menu de gestión de alertas del menú de administración.




Creating special day1.png



Una vez hayamos hecho click en Crear, aparecerá esta pantalla:



Creating special day2.png



Estos son los campos que debería rellenar:

  • Date: Fecha de días especiales. El formato de datos es AAAA-MM-DD. Si quiere definir el mismo día cada año, puede utilizar '*' para AAAA.
  • Same day of the week:Escoja un día. La fecha de arriba es tratada igual que el día seleccionado.
  • Description: Descripción de día especial.

Por ejemplo, asumiendo que es un festivo, el 3 de Marzo de 2012. Cuando defina '2012-05-03' como 'Domingo', ese día será tratado como un domingo. Una vez que haya rellenado los campos, haga click en el botón de Crear.

Template warning.png

Para habilitar la lista de días especiales, "utilizar lista de dias especiales" debería ser implementada en la plantilla de alerta (paso 2)

 


1.14.2 Editar un día especial

Es posible editar los días especiales creados desde la opción de la lista de días especiales del menú de gestión de alertas del menú de administración.



Editing special day1.png



Para editar un día especial sólo tiene que hacer click en la fecha.



Editing special day2.png



Una vez realizados los cambios,haga click en el botón "Actualizar"

1.14.3 Eliminar un día especial

Para eliminar un día especial, haga click en el icono de papelera gris situado a la derecha del día.




Deleting special day.png



1.15 Lista de días especiales (Versiones >= 6.1)

Desde la versión 6.1, la funcionalidad de días especiales de Pandora cuenta con un calendario. Esto permite definir vacaciones y días especiales para las plantillas de alerta. Los días definidos como especiales en esta lista son tratados como el día de la semana que se seleccione.

1.15.1 Crear un día especial

Los nuevos días especiales se crean en el apartado "Alerts" -> "List of special days", haciendo clic en el botón de "Más" o en "Create", debajo del calendario.



Creating special day61-1.png



Una vez que se ha hecho click en uno de ellos, aparecerá una pantalla como esta:



Creating special day2.png



Los apartados a rellenar son los siguientes:

  • Date: La fecha del día especial. El formato es YYYY-MM-DD. Para establecer el mismo día todos los años, puede utilizarse "*" en YYYY.
  • Group: Aquí se selecciona el grupo al que se le aplica el día especial.
  • Same day of the week: Seleccione un día. La fecha del apartado "Date" será tratado igual que este día de la semana.
  • Description: Descripción del día especial.

Por ejemplo, supongamos que el 2 de mayo de 2017 es un día especial. Si definimos "2017-05-02" como "Domingo", ese día será tratado como si fuera un domingo.

Una vez los campos hayan sido seleccionados, hacemos clic en el botón "Create".

Nota: Para habilitar la lista de días especiales, la opción "Use special days list" debe estar marcada en la plantilla de la alerta (Paso 2).

1.15.2 Crear días especiales masivamente usando un archivo .ics

Los días especiales también pueden ser creados utilizando un archivo de tipo iCalendar (.ics). Éstos pueden ser importados en la parte superior de la ventana. Una vez importados, se registrarán los datos correspondientes en el mes actual.



Creating special day ics.png



1.15.3 Editar un día especial

Es posible crear los días especiales creados en la opción "List of special days" en el apartado "Alerts".



Editing special day61-1.png



Para editar un día especial, haga clic en el icono de la llave inglesa junto al día especial que corresponda.



Editing special day2.png



Una vez que se hayan realizado los cambios, haga clic en el botón "Update" para confirmarlos.

1.15.4 Eliminando un día especial

Para eliminar un día especial, haga clic en el icono de la papelera, ubicado junto al icono de la llave inglesa, del día especial.



Deleting special day61.png



1.16 Ejemplos de alertas completas

1.16.1 Envío de alertas por SMS

En este ejemplo, vamos a ver algo muy frecuente: cómo enviar un SMS cuando algo ocurra o esté a punto de suceder.

Para hacer esto, utilizaremos un script publicado en nuestra website (http://pandorafms.org) en la sección de librería de Modulo Exchage. Este script utiliza un API Perl comercial para enviar SMS utilizando un gateway HTTP comercial ( necesitará crear una cuenta y pagar dinero). Esto es muy sencillo, ya que una vez que configure la cuenta y haya configurado el script (solo poniendo su usuario y contraseña) ya estará listo para ser usado.

Supongamos que tenga configurado su cuenta de SMS y haya instalado el script en el servidor de Pandora FMS. Corra el comando.

> sendsms 


You must give three parameters:  <source> <destination> 'Full message'
Don't forget to send the message with single quotes (), and put the destination number 
with international code (346276223 for spanish phones, for example)

Nuestro primer paso, despues de asegurarnos de que el comando sendsms esté listo para usarse, es definir el "comando de alerta". Definimos el comando en la interfaz de administración de Pandora FSM




Smsalert sample1.png




En este comando, enviamos "346666666666" como fuente del mensaje.Podemos usar una palabra (alfanumérica), pero algunos operadores de móviles no gestionan bien las ID's alfanuméricas. Field1 y Field2 se utilizarán para definir el comando behaviour. En la foto del teléfono móvil qeue recibe el SMS utilizo una cadena de identificación :"Aeryn". EL field1 será el teléfono de destino, y el field2 el texto, defnido en la Acción de las alertas.

Ahora defina la acción de la alerta. Esta ejecuta el comando previamente definido,reemplazando field1 y field2 con valores personalizados.En este caso en concreto, la alerta de plantilla no pone ningún dato en el SMS; toda la información es definida en Alert Action.




Smsalert sample3.png



Field1 es mi número de teléfono (un poco encubierto, ya que no quiero que me llamen en mitad de la noche ;).En Field2 está el mensaje de texto. Utilizo aquí unas pocas macros, que serán reemplazadas en el transcurso del tiempo, cuando se produzca la alerta.

Paso final!: vamos a crear una Plantilla de Alerta (sáltese esto si ya tiene una válida). Queremos crear una Plantilla de Alerta muy sencilla, sólo para "disparar" cuando un modulo sea CRITICO. Esta alerta se disparará una vez al día como máximo, pero si se recupera, se lanzará de nuevo cada vez que se recupere y dispare de nuevo.




Smsalert sample5.png





Smsalert sample6.png



Ahora, sólo tiene que asignar un módulo con una plantilla de alerta y una acción de alerta:




Smsalert sample4.png



Para tener este campo de alerta, el módulo deberá estar en CRITICAL. En la siguiente captura, revisaré la configuración del módulo para ver si su umbral CRITICAL está definido. Si no lo está, la alerta nunca se disparará porque está esperando tener un status CRITICAL. En mi caso, lo he fijado a 20. Cuando se recibe un valor menor, el módulo pasará a CRITICAL y la alerta se disparará.




Smsalert sample7.png



Todo listo. Ya podemos "forzar" la alerta para ejecutarla y testearla. Para forzar la alerta, vaya a la vista de alerta del agente y haga click en el icono circular verde.



Smsalert sample8.png



Un SMS podrá aparecer en mi teléfono móvil, como muestra la siguiente foto. Obtuve datos "N/A" porque, cuando fuerzas la alerta, no se recibe ningún dato real por parte del módulo.




Smsalert sample9.png



1.16.2 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_user - 23.00 - Custom log alert #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.


1.16.2.1 Ejemplo completo de alerta con macros de sustitución

Supongamos que lo que quiere es generar una entrada en un LOG donde en cada línea aparezca el siguiente formato:

2009-12-24 00:12:00 pandora [CRITICAL] Agent <agent_name> Data <module_data> Module <module_name> in CRITICAL status

Configuracion del comando

echo _timestamp_ pandora _field2_ >> _field1_

Configuración de la acción

Field1 = /var/log/pandora/pandora_alert.log
Field2 = <En blanco>
Field3 = <En blanco>

Configuración de la plantilla

Field1 = <En blanco>
Field2 = [CRITICAL] Agent _agent_ Data _data_ Module _module_ in CRITICAL status
Field3 = <En blanco>

En la sección de recuperación:

Field2 = [RECOVERED] [CRITICAL] Agent _agent_ Data _data_ Module _module_ in CRITICAL status
Field3 = <En blanco>

Asi al ejecutar una alerta, se insertaría la siguiente linea en el LOG:

2009-10-13 13:37:00 pandora [CRITICAL] Agent raz0r Data 0.00 Module Host Alive in CRITICAL status

Y la siguiente línea al recuperar la alerta:

2009-10-13 13:41:55 pandora [RECOVERED] [CRITICAL] Agent raz0r Data 1.00 Module Host Alive in CRITICAL status

1.17 Custom module alert macros

Se puede añadir cualquier número de macros a un módulo de agente.



Add module macros.png


Estas macros tienen las siguientes características:

  • Se definen en el modulo.
  • Almacenan los datos en la BBDD
  • Pueden tener cualquier nombre, p.e: _pepito
  • No se reflejan en la configuracion local (.conf)
  • Se usan exclusivamente para las alertas.
  • No se pueden definir a nivel de componente.
  • Se pueden definir en las politicas.

Estas macros especificas se pueden añadir expandiendo la sección de macros de cualquier módulo.



Module macros.png


Los valores establecidos pueden ser utilizados como parte de los campos en la definición de alertas. Por Ejemplo: Para incluir una macro a la acción de envió de correo electrónico es necesario configurar el campo de cuerpo del mensaje de la siguiente manera:



Campos alertas.png


Si un modulo es añadido a esta alerta sin tener la macro configurada la sección donde debería aparecer el valor de la macro en la acción aparecerá vacía.

1.18 Alertas de eventos y correlación

Existe un Capítulo específico para tratar este tema

Go back to Pandora FMS documentation index


1.19 Guía rápida de configuración de correos para alertas en Pandora FMS

1.19.1 Configuración de correo con cuenta Gmail

Para que el servidor de Pandora pueda mandar las alertas mediante correo de cuenta Gmail necesitamos tener configurado Pandora y Postfix del siguiente modo:

1.19.1.1 Configuración Pandora

Para configurar correctamente el correo con una cuenta de Gmail en el archivo de configuración del servidor de Pandora (/etc/pandora/pandora_server.conf) tienen que estar comentados todos los campos excepto el mta_address que lo configuraremos con localhost o la ip del servidor donde se encuentre el servidor postfix instalado.

Si tenemos instalado Postfix en el mismo servidor que Pandora la configuración en el pandora_server.conf sería esta:

mta_address localhost 
#mta_port 25
#mta_user [email protected]
#mta_pass mypassword
#mta_auth LOGIN
#mta_from Pandora FMS <[email protected]>


A continuación os voy a mostrar un pequeño resumen de la configuración de una alerta en la consola de Pandora.

1.19.1.1.1 Configuración de Acción

Para configurar el destinatario de correo usamos la acción Mail to XXX para añadir un destinatario de correo al que se enviaran todos los correos de las alertas.


GMAIL1.png

1.19.1.1.2 Configuración de la Alerta

En este caso se ha generado en la configuración del módulo > Alertas, una nueva alerta con el módulo que podéis ver en la captura.


GMAIL2.png

Una vez que salta la alerta observamos como llegará al correo elegido en la acción:


GMAIL3.png


GMAIL4.png

1.19.1.2 Configuración Postfix

Asumiendo que ya tiene instalado Postfix en su servidor y todo funciona correctamente excepto el envío de mail via gmail, debe seguir estos pasos:

1-- Editar el fichero /etc/postfix/main.cf y añadir las siguientes líneas al final del archivo:

relayhost = [smtp.gmail.com]:587
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl/passwd
smtp_sasl_security_options = noanonymous
smtp_use_tls = yes
smtp_tls_CAfile = /etc/postfix/cacert.pem

2-- Crear el archivo /etc/postfix/sasl/passwd con su dirección de gmail y contraseña ( debe crear el directorio "sasl" y despues crear el fichero passwd aqui).

Crear el directorio “sasl”:

mkdir /etc/postfix/sasl

To create the passwd file:

nano /etc/postfix/sasl/passwd

Añade la siguiente linea en el fichero con su propia dirección de gmail y contraseña:

[smtp.gmail.com]:587 [email protected]:PASSWORD

Protegerlo adecuadamente mediante:

chmod 600 /etc/postfix/sasl/passwd

Esto permitirá que solo usuarios root accedan al fichero

3-- Transformamos /etc/postfix/sasl/passwd a un fichero indexado de tipo hash mediante la instrucción:

postmap /etc/postfix/sasl/passwd

Lo que creará el fichero /etc/postfix/sasl/passwd.db

4-- Ahora instalaremos los certificados de Gmail y Equifax. La Appliance de Pandora FMS no tiene estos certificados por defecto. Si ya tiene estos certificados instalados puede saltar este punto.

Para instalar el certificado de Gmail siga estos pasos:

El certificado SSL Google está firmado por Equifax - lo primero que necesitamos a buscarlo. Nos movemos al directorio “tls”:

cd /etc/pki/tls/

Descargamos el certificado Equifax.

sudo wget -O Equifax_Secure_Certificate_Authority.pem https://www.geotrust.com/resources/root_certificates/certificates/Equifax_Secure_Certificate_Authority.cer

Añadimos los permisos al fichero descargado:

chmod 644 Equifax_Secure_Certificate_Authority.pem

También necesitamos solicitar la firma para el certificado:

openssl x509 -in Equifax_Secure_Certificate_Authority.pem -fingerprint -subject -issuer -serial -hash -noout

Instalamos a continuación el certificado de Gmail. Lo primero que necesitamos es la utilidad c_rehash, instalando este paquete:

yum install openssl-perl

Si no tiene en ninguno de los repositorios este paqute, siguiendo estos pasos resolverá el problema:

 sudo su
 nano /etc/yum.repos.d/extra_repos.repo
 In the #percona repository I changed the baseurl line to:  http://repo.percona.com/centos/6/os/x86_64/
 ^O to write the edited file
 ^x to exit
 After returning to root terminal, enter "yum install openssl-perl" and accept the defaults

Lo siguiente que necesitamos es adquirir realmente el certificado para GMail. Usando openssl lo hacemos así:

openssl s_client -connect pop.gmail.com:995 -showcerts

La salida debe contener las líneas requeridas para el certificado y tenemos que copiarlos a /etc/pki/tls/gmail.pem archivo. Para ello, cree el archivo:

nano /etc/pki/tls/gmail.pem

y pega estas lineas en el mismo:

-----BEGIN CERTIFICATE-----
MIIDWjCCAsOgAwIBAgIKYgy3qQADAAAJ5zANBgkqhkiG9w0BAQUFADBGMQswCQYD
VQQGEwJVUzETMBEGA1UEChMKR29vZ2xlIEluYzEiMCAGA1UEAxMZR29vZ2xlIElu
dGVybmV0IEF1dGhvcml0eTAeFw0wOTA3MTcxNzE2NTVaFw0xMDA3MTcxNzI2NTVa
MGcxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRYwFAYDVQQHEw1N
b3VudGFpbiBWaWV3MRMwEQYDVQQKEwpHb29nbGUgSW5jMRYwFAYDVQQDEw1wb3Au
Z21haWwuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDTHqjJfnRXdpmZ
4iP/WNCpvzX4N97bEZ3rvS4aDYey/DJetKZqp9DK1Ie4/C5j8M1aakwiTNA/eHS/
wNWVgQx8+HxproYKUeeYj3shYKEkHGfrRYBcyCxc7Gd6NSGaaYru3Z7nJ+STIPUJ
E1N35JAwcjjdITVI2O4LckAL4b7GkwIDAQABo4IBLDCCASgwHQYDVR0OBBYEFIln
0T5I8Mw6cqhtUS4pyMGYRxOTMB8GA1UdIwQYMBaAFL/AMOv1QxE+Z7qekfv8atrj
axIkMFsGA1UdHwRUMFIwUKBOoEyGSmh0dHA6Ly93d3cuZ3N0YXRpYy5jb20vR29v
Z2xlSW50ZXJuZXRBdXRob3JpdHkvR29vZ2xlSW50ZXJuZXRBdXRob3JpdHkuY3Js
MGYGCCsGAQUFBwEBBFowWDBWBggrBgEFBQcwAoZKaHR0cDovL3d3dy5nc3RhdGlj
LmNvbS9Hb29nbGVJbnRlcm5ldEF1dGhvcml0eS9Hb29nbGVJbnRlcm5ldEF1dGhv
cml0eS5jcnQwIQYJKwYBBAGCNxQCBBQeEgBXAGUAYgBTAGUAcgB2AGUAcjANBgkq
hkiG9w0BAQUFAAOBgQCEGIebkDpktdjtzMiTTmEiN7e4vc73hEI4K0jYKyY0Wn5N
dc44AXTfIWOzsikwb886PCUSevGs9rcw2/kaHdPaBSuGrzSCf8ODQqTC3odry3lo
PtZGr6nf/81F5UW71+bE1iWOQlJ5/olWOr2SlqYla1iOmosEctD/GyoFnDh+BA==
-----END CERTIFICATE-----

Ejecutamos la utilidad c_rehash:

cd /etc/pki/tls

y

c_rehash

Finalmente lo testeamos con la siguiente ejecución:

openssl s_client -connect pop.gmail.com:995 -CApath /etc/pki/tls

El punto importante es verificar el código de retorno: 0 (ok), y permiso definitivo Gpop ready. Si usted los consigue, entonces puede conectarse a Gmail.

Creamos el archivo Equifax_secure_CA.pem:

nano /etc/ssl/certs/Equifax_Secure_CA.pem

Pegamos las siguientes líneas:

-----BEGIN CERTIFICATE-----
MIIDIDCCAomgAwIBAgIENd70zzANBgkqhkiG9w0BAQUFADBOMQswCQYDVQQGEwJV
UzEQMA4GA1UEChMHRXF1aWZheDEtMCsGA1UECxMkRXF1aWZheCBTZWN1cmUgQ2Vy
dGlmaWNhdGUgQXV0aG9yaXR5MB4XDTk4MDgyMjE2NDE1MVoXDTE4MDgyMjE2NDE1
MVowTjELMAkGA1UEBhMCVVMxEDAOBgNVBAoTB0VxdWlmYXgxLTArBgNVBAsTJEVx
dWlmYXggU2VjdXJlIENlcnRpZmljYXRlIEF1dGhvcml0eTCBnzANBgkqhkiG9w0B
AQEFAAOBjQAwgYkCgYEAwV2xWGcIYu6gmi0fCG2RFGiYCh7+2gRvE4RiIcPRfM6f
BeC4AfBONOziipUEZKzxa1NfBbPLZ4C/QgKO/t0BCezhABRP/PvwDN1Dulsr4R+A
cJkVV5MW8Q+XarfCaCMczE1ZMKxRHjuvK9buY0V7xdlfUNLjUA86iOe/FP3gx7kC
AwEAAaOCAQkwggEFMHAGA1UdHwRpMGcwZaBjoGGkXzBdMQswCQYDVQQGEwJVUzEQ
MA4GA1UEChMHRXF1aWZheDEtMCsGA1UECxMkRXF1aWZheCBTZWN1cmUgQ2VydGlm
aWNhdGUgQXV0aG9yaXR5MQ0wCwYDVQQDEwRDUkwxMBoGA1UdEAQTMBGBDzIwMTgw
ODIyMTY0MTUxWjALBgNVHQ8EBAMCAQYwHwYDVR0jBBgwFoAUSOZo+SvSspXXR9gj
IBBPM5iQn9QwHQYDVR0OBBYEFEjmaPkr0rKV10fYIyAQTzOYkJ/UMAwGA1UdEwQF
MAMBAf8wGgYJKoZIhvZ9B0EABA0wCxsFVjMuMGMDAgbAMA0GCSqGSIb3DQEBBQUA
A4GBAFjOKer89961zgK5F7WF0bnj4JXMJTENAKaSbn+2kmOeUJXRmm/kEd5jhW6Y
7qj/WsjTVbJmcVfewCHrPSqnI0kBBIZCe/zuf6IWUrVnZ9NA2zsmWLIodz2uFHdh
1voqZiegDfqnc1zqcPGUIWVEX/r87yloqaKHee9570+sB3c4
-----END CERTIFICATE-----

Guardamos y salimos

Con el fin de añadir la autoridad Equifax certificar, que certifica correos electrónicos de Gmail, en el archivo de certificado que utiliza postfix, ejecute el siguiente comando en una consola como root:

cat /etc/ssl/certs/Equifax_Secure_CA.pem > /etc/postfix/cacert.pem

5-- Finalmente, reiniciamos postfix para aplicar los cambios, así:

/etc/init.d/postfix restart

6-- Podemos comprobar el funcionamiento abriendo dos consolas. En una ejecutaremos el siguiente comando para monitorear el comportamiento del correo:

tail -f /var/log/maillog

Y en la otra enviaremos un correo:

echo "Prueba correo" | mail [email protected]

Si los pasos anteriores han tenido éxito, en la otra consola deberíamos ver algo como ésto:

Dec 18 18:33:40 OKComputer postfix/pickup[10945]: 75D4A243BD: uid=0 from=
Dec 18 18:33:40 OKComputer postfix/cleanup[10951]: 75D4A243BD: message-id=
Dec 18 18:33:40 OKComputer postfix/qmgr[10946]: 75D4A243BD: from=, size=403, nrcpt=1 (queue active)
Dec 18 18:33:44 OKComputer postfix/smtp[10953]: 75D4A243BD: [email protected], relay=smtp.gmail.com[74.125.93.109]:587, delay=3.7,  delays=0.15/0.14/1.8/1.6, dsn=2.0.0, status=sent (250 2.0.0 OK 1324249500 eb5sm36008464qab.10)
Dec 18 18:33:44 OKComputer postfix/qmgr[10946]: 75D4A243BD: removed

Si el resultado es el anterior, Pandora apuntará al servidor Postfix para mandar los correos y serán enviados sin problemas.