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 (el contact1 es por defecto, se puede eliminar):

{
  "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"
  }
}

DutyTime: horario y días en que el contacto recibirá los eventos configurados; para este ejemplo:

contact2: de las 6:00hrs a las 20:00hrs, de lunes a viernes

contact3: las 24 horas del día, toda la semana

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 pasos anteriores, es necesario reiniciar los demonios de OMK y opEvents para aplicar los cambios:

service omkd restart
service opeventsd restart

Con esto, es posible proceder a la ejecución de pruebas de funcionamiento, validar la información recibida y ajustar las políticas según sea necesario, así como crear nuevas en función de los requerimientos del entorno.

Se genera un evento "Node Down" del equipo Nodo_BN_nd.

Al revisar en opEvents, se observa que, al generarse el evento, se ejecutan las acciones configuradas: escalamiento del evento, envío de correo electrónico y ejecución del script de ping en la consola.

Al revisar el correo electrónico, se observa la recepción del mensaje con la información configurada previamente en los archivos de configuración. Asimismo, en el cuerpo del correo se incluye un enlace que dirige a la ventana de detalles del evento correspondiente, como se muestra a continuación:

Nota: Para generar correctamente el enlace del evento, es necesario configurar la dirección del servidor donde se encuentra instalado opEvents en el archivo opCommon.json, específicamente en el parámetro "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