En este documento, se mostrará la forma en la que se puede configurar el envío de eventos por correo electrónico utilizando el módulo opEvents, integrando algunos parámetros personalizados. De igual forma, se mostrará un ejemplo de cómo se puede configurar el envío de eventos a otro gestor.

1 Personalización de correos / Configuración de plantillas con información esencial
- 1.1 Configuración de correos de destinatarios
- 1.2 Personalización de template
- 1.3 Configuración del servidor de correo
  - 1.3.1 Cómo crearla:
- 1.4 Nivel de escalación
- 1.5 Creación de política
2 Envío de eventos a otro gestor
- 2.1 Configuración de parámetros del gestor

Personalización de correos / Configuración de plantillas con información esencial

Para realizar la configuración del envío de eventos por email utilizando opEvents, basta con seguir los pasos que se describirán a continuación:

Configuración de correos de destinatarios

Como primer paso, se procede a configurar una o varias direcciones de correo electrónico correspondientes a los destinatarios a quienes se desea enviar las alertas generadas por los equipos.

Nota: antes de modificar cualquier archivo del sistema, se recomienda hacer una copia de seguridad del mismo.

Desde la consola de NMIS, se debe acceder a la ruta /usr/local/omk/conf.

En esta ruta se debe localizar el archivo denominado “Contacts.json”, el cual contiene la configuración de los destinatarios de correo electrónico.

El archivo Contacts.json es donde se registran los contactos y es utilizado por OMK.

Nota: dentro de la configuración de cada contacto existe una propiedad llamada "EmailTemplate", la cual debe contener el nombre del template correspondiente, según la información que se desea enviar al destinatario. Estos templates están definidos en el archivo “EventEmails.json”, el cual se abordará más adelante.

Al configurar los correos electrónicos (en este ejemplo, se agregan dos direcciones), el archivo tendrá un aspecto similar al siguiente:

{
  "contact1": {
    "Contact": "Contact1",
    "TimeZone": "0",
    "Location": "default",
    "Level": "(Fatal|Critical|Major|Minor|Warning|Normal)",
    "Pager": "",
    "Email": "nobody@localhost",
    "EmailTemplate": "default",
    "Phone": "",
    "Mobile": "5555551234",
    "DutyTime": "06:20:MonTueWedThuFri"
  },
  "contact2": {
    "Contact": "Contact2",
    "TimeZone": "0",
    "Location": "CDMX",
    "Level": "(Fatal|Critical|Major|Minor|Warning|Normal)",
    "Pager": "",
    "Email": "correo@domino.xx",
    "EmailTemplate": "default",
    "Phone": "",
    "Mobile": "5500001111",
    "DutyTime": "06:20:MonTueWedThuFri"
  },
  "contact3": {
    "Contact": "Contact3",
    "TimeZone": "0",
    "Location": "EDOMEX",
    "Level": "(Fatal|Critical|Major|Minor|Warning|Normal)",
    "Pager": "",
    "Email": "correo@domino.xx",
    "EmailTemplate": "veryshort",
    "Phone": "001805123123",
    "Mobile": "5580654059",
    "DutyTime": "00:24:MonTueWedThuFriSatSun"
  }
}

Una vez realizados los cambios, se deben guardar y verificar la integridad del archivo, ejecutando jq . Contacts.json.

Personalización de template

Como segundo paso, se puede optar por personalizar una plantilla existente o utilizar alguna de las que ya vienen definidas por defecto. Esta configuración se realiza en la siguiente ruta: /usr/local/omk/conf/EventEmails.json.

Dentro del archivo EventEmails.json, se encuentran tres templates predefinidos: “brief”, “default” y “veryshort”, cada uno con diferente nivel de detalle. Para este ejemplo, se procederá a modificar la plantilla “default”.
Por ejemplo, en la sección "subject", se incluye la fecha del evento, el nombre del nodo y el tipo de evento. En este caso, se añade un texto adicional al inicio para indicar que la alerta corresponde al departamento de "Cobranzas". En el body del correo se muestran otros datos relevantes como el evento, el nodo que lo generó, la prioridad, entre otros. Esta sección puede ser personalizada libremente, permitiendo agregar o eliminar propiedades según la información que se desee enviar en el correo.
Una vez finalizada la configuración, se debe guardar el archivo y verificar su integridad.

Este template es por defecto. Se debe de ajustar de acuerdo a los requerimientos de cada contacto.

Configuración del servidor de correo

Como tercer paso, se procede a configurar la cuenta de correo desde la cual se realizará el envío de los eventos.
Esta configuración se lleva a cabo en el archivo /usr/local/omk/conf/opCommon.json, en la sección de "email". En este ejemplo, se utiliza un servidor de correo electrónico de Gmail, esto debe de ser ajustado según corresponda.

"email" : {
      "mail_from" : "correodenotificaciones@gmail.com",
      "mail_server_port" : 587,
      "mail_password" : "passworddecorreo",
      "mail_domain" : "gmail.com",
      "mail_server" : "smtp.gmail.com",
      "mail_use_tls" : "true",
      "mail_user" : "correodenotificaciones@gmail.com "
   },

Alternativamente, esta configuración también puede realizarse desde la interfaz web del módulo opEvents. Para ello, se debe acceder al menú lateral derecho: System → System Configuration, y en la página de administración, ingresar a Settings. Ahí se encuentra el apartado Mail, donde es posible especificar los datos del servidor de correo a utilizar.

NOTA: Si tienes verificación en dos pasos (2FA) activada, no puedes usar tu contraseña normal para enviar correos desde scripts. Necesitas una contraseña de aplicación.

Cómo crearla:

Inicia sesión en: https://myaccount.google.com
Ve a: Seguridad
Activa la verificación en dos pasos, si aún no está.
Luego ve a:
https://myaccount.google.com/apppasswords
Elige:
- App: por ejemplo, Correo
- Dispositivo: el que tú quieras o Otro (personalizado)
Google generará una contraseña de 16 caracteres.
Usa esa contraseña tu aplicación o script

Nivel de escalación

Una vez definidos los datos que se desean incluir en el correo y configurado el servidor de correo, se procede a ajustar la política y el nivel de escalación para las alertas. Esta configuración se realiza en el archivo /usr/local/omk/conf/EventActions.json.
Dentro del archivo EventActions.json, primero se debe dar de alta la sección encargada de escalar (enviar) la alerta, la cual se integra en el apartado "escalate".
En esta sección, la configuración se realiza mediante una estructura "if", donde se define el nombre de la escalación, la prioridad del evento y el tiempo (en segundos) que debe esperar antes de enviar correos a los destinatarios.
Adicionalmente, es posible ejecutar comandos o scripts junto con el envío de correos. En este ejemplo, se ejecuta un comando ping.

...
 "escalate" : {
      "Notibn": {
         "name": "Notibn",
         "5": "email(contact2) AND script.ping_node()",
         "IF": {
            "priority": ">= 0"
         }         
      },
...

Creación de política

Una vez configurada la escalación, se procede a dar de alta la política a la que se aplicará dicha escalación. Alternativamente, también es posible crear una nueva política según las necesidades específicas del entorno. Esta configuración se realiza igualmente en el archivo EventActions.json, dentro de la sección "policy".
Para este ejemplo, se crea una política destinada al evento "Node Down". La política se define dentro de una estructura "if", especificando los valores del evento que se desea validar, su prioridad, las acciones que se deben ejecutar (en este caso, algunos scripts), y finalmente se invoca la escalación previamente configurada (denominada "Notibn").

...
 "policy" : {
      "5": {
          "BREAK": "false",    
               "IF": "event.event eq \"Node Down\"",
               "THEN": [
                  "escalate.Notibn()",     
                  "script.ping_node()"
               ]
            }
   },
...

Se adjunta un ejemplo de configuración de archivo que puede ser utilizado:

Una vez completados los cinco pasos anteriores, es necesario reiniciar los demonios de omk y opevents para aplicar los cambios:

service omkd restart
service opeventsd restart

Con esto, ya se puede proceder a realizar pruebas de funcionamiento, ajustar la información recibida y modificar las políticas según sea necesario, o bien crear nuevas según los requerimientos del entorno.

Se genero un evento “Node Down“ del equipo Nodo_BN_nd.

Al revisar en opEvents podemos constatar que al generarse el evento toma las acciones de escalar el evento, enviar el correo y correr el scrip de ping en la consola.

Si revisamos nuestro correo podemos ver que ya nos llego el email y con los datos que configuramos previamente en los archivos de configuración, incluso en el cuerpo del email vamos a encontrar un link que nos llevara a la ventana de detalles del evento en cuestión como se muestra a continuación.

NOTA: para poder generar de forma correcta el link del evento es importante configurar la dirección de nuestro servidor donde tenemos instalado opEvents en el archivo “opCommon.json” en el apartado “opevents_url_base“.

...
 "opevents_auto_acknowledge_up" : "true",
      "opevents_syslog_rules" : "<omk_conf>/EventSyslogRules.json",
      "opevents_kb_link_title" : "KB Lookup",
      "opevents_gui_current_events_priorities_upper" : 10,
      "state_flap_window" : "0",
      "opevents_url_base" : "http://192.168.1.100",
      "opevents_standard_path" : "/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin",
      "opevents_hostname" : ""
   },
...

Envío de eventos a otro gestor

Configuración de parámetros del gestor

El siguiente ejemplo de configuración deberá ser adaptado a la infraestructura mediante las pruebas correspondientes de envío al gestor que el cliente maneje.

Esta configuración aplica para enviar traps SNMP.
Para habilitar el envío de eventos a otro sistema de gestión, se debe editar el archivo /usr/local/omk/conf/EventActions.nmis.
Localizar la sección llamada "script" e insertar el siguiente contenido.
En el contenido a agregar, el valor IP_ADDRESS_OF_TEMIP debe ser reemplazado por la dirección IP del servidor de destino, y COMMUNITY_STRING por la cadena SNMP deseada.

"send_snmptrap_gestor" : {
    "arguments" : "-v 2c -Ci -c COMMUNITY_STRING IP_ADDRESS_OF_TEMIP '' 1.3.6.1.4.1.4818.1.1 1.3.6.1.4.1.4818.2.1.1 s event._id 1.3.6.1.4.1.4818.2.1.2 s event.time 1.3.6.1.4.1.4818.2.1.3 s event.date 1.3.6.1.4.1.4818.2.1.4 s event.node 1.3.6.1.4.1.4818.2.1.5 s event.host 1.3.6.1.4.1.4818.2.1.6 s event.event 1.3.6.1.4.1.4818.2.1.7 s event.element 1.3.6.1.4.1.4818.2.1.8 s event.state 1.3.6.1.4.1.4818.2.1.9 s event.stateful 1.3.6.1.4.1.4818.2.1.10 s event.details 1.3.6.1.4.1.4818.2.1.11 s event.type 1.3.6.1.4.1.4818.2.1.12 s event.priority 1.3.6.1.4.1.4818.2.1.13 s event.level",
    "exec" : "/usr/bin/snmptrap",
    "output" : "save"
},

Una vez completada la configuración, la sección script dentro del archivo se visualizará de la siguiente manera:

"script" : {
    "send_snmptrap" : {
        "arguments" : "-v 2c -Ci -c COMMUNITY_STRING IP_ADDRESS_OF_TEMIP '' 1.3.6.1.4.1.4818.1.1 1.3.6.1.4.1.4818.2.1.1 s event._id 1.3.6.1.4.1.4818.2.1.2 s event.time 1.3.6.1.4.1.4818.2.1.3 s event.date 1.3.6.1.4.1.4818.2.1.4 s event.node 1.3.6.1.4.1.4818.2.1.5 s event.host 1.3.6.1.4.1.4818.2.1.6 s event.event 1.3.6.1.4.1.4818.2.1.7 s event.element 1.3.6.1.4.1.4818.2.1.8 s event.state 1.3.6.1.4.1.4818.2.1.9 s event.stateful 1.3.6.1.4.1.4818.2.1.10 s event.details 1.3.6.1.4.1.4818.2.1.11 s event.type 1.3.6.1.4.1.4818.2.1.12 s event.priority 1.3.6.1.4.1.4818.2.1.13 s event.level",
        "exec" : "/usr/bin/snmptrap",
        "output" : "save"
    },
    "traceroute_node" : {          
       "output" : "save",
       "arguments" : "--max-hops=20 node.configuration.host",
       "exec" : "traceroute"   
     },       
     "ping_node" : {
        "exec" : "/bin/ping",
        "arguments" : "-c 5 node.configuration.host",
        "output" : "save"
     },
     "ping_neighbor" : {
        "exec" : "/bin/ping",
        "output" : "save",
        "arguments" : "-c 5 event.element"
     }  
},

Una vez añadida la sección "send_snmptrap_gestor" dentro de la sección "script", se debe configurar una acción para enviar el snmptrap.
A continuación, se mostrará cómo agregar un nuevo evento para que sea enviado a otro gestor.
Se edita el archivo correspondiente y se agregan los eventos "Proactive Interface Output Utilisation" y su evento de cierre "Proactive Interface Output Utilisation Closed".
En este ejemplo, en la condición THEN se añade la acción que se debe ejecutar cuando ocurra el evento. En este caso, se enviará el evento a otro gestor mediante la instrucción script.send_snmptrap_gestor(), especificando la dirección IP del gestor receptor y el puerto correspondiente.
De igual forma, en la condición THEN se añade la acción que se debe ejecutar cuando ocurra el evento. En este caso, se enviará el evento a otro gestor mediante la instrucción "script.send_snmptrap_gestor", especificando la dirección IP del gestor receptor y el puerto correspondiente.

"5":{
IF:"event.event eq "Proactive Interface Output Utilisation"",
THEN:"script.send snmptrap_gestor()",
BREAK:"true"
},
"10":{
IF:"event.event eq "Proactive Interface Output Utilisation Closed”",
THEN:"script.send snmptrap gestor ()",
BREAK:"true"
},

....
"script" : {
    "send_snmptrap_gestor" : {
        "arguments" : "-v 2c -Ci -c COMMUNITY_STRING IP_ADDRESS_OF_TEMIP '' 1.3.6.1.4.1.4818.1.1 1.3.6.1.4.1.4818.2.1.1 s event._id 1.3.6.1.4.1.4818.2.1.2 s event.time 1.3.6.1.4.1.4818.2.1.3 s event.date 1.3.6.1.4.1.4818.2.1.4 s event.node 1.3.6.1.4.1.4818.2.1.5 s event.host 1.3.6.1.4.1.4818.2.1.6 s event.event 1.3.6.1.4.1.4818.2.1.7 s event.element 1.3.6.1.4.1.4818.2.1.8 s event.state 1.3.6.1.4.1.4818.2.1.9 s event.stateful 1.3.6.1.4.1.4818.2.1.10 s event.details 1.3.6.1.4.1.4818.2.1.11 s event.type 1.3.6.1.4.1.4818.2.1.12 s event.priority 1.3.6.1.4.1.4818.2.1.13 s event.level",
        "exec" : "/usr/bin/snmptrap",
        "output" : "save"
    },
....

Con esta configuración, se enviarán los eventos Proactive Interface Output Utilisation y Proactive Interface Output Utilisation Closed hacia otro gestor, y será posible visualizar el detalle del envío en el Event Context de opEvents.

Envío de alertas: opEvents a email y a otros gestores