Últimamente he recibido algunas preguntas sobre cómo nuestros sistemas gestionan los eventos y las interrupciones importantes. Dependiendo de su entorno de resolución, puede llamar a esto una serie de cosas como gestión jerárquica de eventos, deduplicación de eventos o incluso capear tormentas de eventos. Independientemente de la verborrea, el concepto es el mismo: si un dispositivo se cae, ¿su sistema de gestión de eventos envía múltiples notificaciones sobre los nodos dependientes que también se han caído? opEvents gestiona estos eventos con un método increíblemente sencillo, utilizando la deduplicación de estados y la correlación de eventos.

Deduplicación con estado

opEvents utiliza la deduplicación de estados para asegurar que sólo se ha creado un evento para una instancia de un estado. Por ejemplo, si un nodo se registra como caído, se sondea más tarde y sigue caído, esto no generará dos eventos, sino que se considerará un solo evento. Esto depende de que el estado actual siga registrado como caído y el nodo no se considere en una ventana de flap. Se considera que hay un flap si un nodo sube y baja dentro de una ventana determinada (por defecto 90 segundos), esto ayudará a reducir el total de notificaciones de eventos mientras se asegura que se registran los fallos correctos.

Correlación de eventos

El poder de opEvents está encapsulado en cómo maneja la correlación de eventos. Hay un punto en la gestión de fallos en el que un ingeniero de redes preferiría la información correcta en lugar de toda la información. La Correlación de Eventos utiliza este principio para hacer parte del trabajo pesado por usted y darle la información que es más relevante para un problema. Se puede generar un evento sintético que procesará los eventos correlacionados, basándose en la ubicación o la dependencia, por ejemplo, los agrupa y sólo se activa un evento. Esto ayudará a diagnosticar los fallos, pero también a reducir el número de eventos disparados si una ubicación está fuera de servicio. La combinación de estos dos principios puede ayudar a reducir el tiempo de detección de la causa raíz, a la vez que se mantiene una vigilancia sobre su red. Si puede configurar su gestión de eventos con estos principios, estará obteniendo la mejor información para hacer su trabajo, sin el ruido extra. Una pequeña inversión en este proceso le permitirá ahorrar considerablemente a largo plazo. Como siempre, nuestra Wiki de la Comunidad tiene guías detalladas sobre cómo implementar estos conceptos:

• Correlación de eventos
• Correlación de eventos basada en la ubicación
• Deduplicación y control de tormentas en opEvents

Así como algunos seminarios web increíblemente útiles sobre estos temas:

• Gestión de rendimiento y fallos para MSP y empresas
• Configuración de la escalada de eventos y notificaciones
• Gestión inteligente de fallos y configuraciones

Si tiene preguntas sobre cualquier tema, tiene una solicitud de función o cualquier comentario, no dude en ponerse en contacto con nosotros - ¡Aquí!

En el último mes, el mayor proveedor de telecomunicaciones de Australia, Telstra, ha sido objeto de críticas debido a tres importantes interrupciones de sus servicios. Aunque los incidentes han sido calificados de casuales, la empresa recibió comentarios y quejas negativas que se sumaron para formar una imagen de marca negativa. Cuando los errores perturban a todo un país, uno que depende de tus servicios para el funcionamiento de las empresas, es difícil recuperarse positivamente. Esto se ejemplifica en una pérdida significativa en el precio de sus acciones el último mes, cayendo de 3,25 a 2,74 dólares en dos semanas. Sin embargo, estas interrupciones deberían ayudar a moldear la forma en que cada empresa se enfrenta a los fallos. Si su empresa es reactiva, los fallos operativos importantes parecerán peores que los de sus competidores proactivos. Asegurarse de que se destinan recursos a la gestión proactiva de las averías es una ventaja. Una cita de un gestor de comunicación que trabaja para limitar el tiempo de inactividad de sus clientes es la que mejor representa esta cuestión: desean "resolver los problemas de los clientes antes de que se pongan en contacto con nosotros". Esta mentalidad, poner la satisfacción del usuario en primer lugar, les ayudará a generar más clientes porque se centran en aumentar la satisfacción del usuario. Iniciar el cambio de un equipo reactivo a uno proactivo requiere recursos comprometidos para ayudar a dar forma a un proceso de automatización. El coste inicial de desarrollar estos protocolos puede ser alto, pero el retorno de la inversión se ve en breve y se extrapola en el tiempo. En los siguientes seminarios web, dirigidos por Mark Henry, se puede encontrar información esencial para empezar a hacerlo:

• Desarrollar un NOC estratégico
• Guía para automatizar la configuración de eventos
• Gestión de fallos y configuración para MSP

Mark es un Ingeniero de Sistemas Senior en Opmantek pero ha construido sus propios MSPs; su historia ha sido impulsada por el aumento de la satisfacción del usuario, esto le dará la base para comenzar a automatizar sus problemas. Si su enfoque es mejorar la satisfacción del usuario, el crecimiento de su negocio será más sencillo y los eventos catastróficos serán limitados.

Es muy importante que una red esté configurada de manera que cumpla con la legislación pertinente, pero también para garantizar la máxima calidad del servicio. Es necesario comprobar la infraestructura de TI para evaluar si cumple con las normas establecidas. Esto era cada vez más difícil con el alcance de la infraestructura de TI que se requiere ahora para mantener estrictos acuerdos de nivel de servicio, pero ahora esas comprobaciones pueden pasar de ser manuales a ser automatizadas.

opConfig cuenta con un motor de cumplimiento increíblemente potente, que puede utilizarse para auditar una red y garantizar que todos los dispositivos cumplen con un conjunto de políticas. El producto viene con las mejores prácticas de CISCO-NSA como conjunto de políticas de cumplimiento por defecto, pero añadir sus propias políticas personalizadas es extremadamente fácil de hacer. La página de la Comunidad tiene todos los recursos que necesitará para crear sus propias políticas o editar algunas de las existentes(localizadas aquí).

Sin embargo, este informe se centra en lo que hay que hacer con la información que se proporciona una vez que se aplican estas políticas. Hay dos maneras clave de procesar esta información y hacer que su red vuelva a cumplir con las normas, dependiendo de cuántos dispositivos se requieran para arreglar.

La primera se utiliza normalmente si se ha heredado un problema de cumplimiento, a través de fusiones y adquisiciones, por ejemplo, donde un gran número de dispositivos no son conformes. En este caso, el mejor proceso puede ser la introducción de una nueva configuración en todos los dispositivos. Esto puede llevar más tiempo que las correcciones de un solo elemento, pero se sabe que cada dispositivo se configurará con la misma línea de base. El empuje de la configuración se ha explicado a través de nuestra página de la Comunidad y esboza un ejemplo estupendo también(situado aquí).

Esto lleva a la ocurrencia más común cuando pequeños cambios en un dispositivo han sido notados por el sistema de auditoría. El informe de conformidad puede automatizarse para que se ejecute cada mañana antes de la hora de inicio programada de un equipo y genere un informe de los dispositivos que no son conformes. Muchos ingenieros de redes utilizarán esto como una hoja de tareas para el día/mañana, el informe en un monitor y la CLI requerida en el otro. A medida que vayan completando las tareas, su entorno será más conforme y los niveles de servicio aumentarán.

El resultado del informe puede verse arriba. Esto ejemplifica lo que el motor de cumplimiento de opConfig buscará. La categoría de aciertos y errores se refiere a las políticas que se prueban. Si hay un punto de configuración que se puede probar para la política, esto resultará en un acierto. Si no hay nada disponible habrá un fallo (tenga en cuenta que un acierto o un fallo no implica que haya un fallo, está detallando un protocolo de prueba exitoso). La segunda columna se refiere a las excepciones y a los OKs, una excepción requerirá cambiar la configuración de un dispositivo, el OK denota que el dispositivo está actuando de acuerdo con lo que requiere la política.

Si desea más información sobre estos temas, navegue por los foros de la comunidad en los enlaces de arriba o póngase en contacto con nosotros a través de los enlaces de abajo.

NMIS es una herramienta poderosa nada más sacarla de la caja, sin embargo, si se toma el tiempo necesario para entender todo lo que realmente es capaz de hacer, se puede personalizar para que se adapte a casi cualquier proceso de Gestión de Redes. Una característica útil que los usuarios de NMIS pueden desconocer es la capacidad de crear Tablas Personalizadas. Esta guía le llevará paso a paso con un ejemplo del mundo real para ayudar a que su red funcione para usted.

Paso 1. Cree una nueva configuración de tabla NMIS.

For each known type of table there is a separate table configuration file all of which are named Table-<tableName>.nmis (e.g for the table Nodes.nmis the configuration file is called Table-Nodes.nmis). Both of these tables and their configuration files are located in the conf directory – /usr/local/nmis8/conf. The benefit of NMIS being open-source, is that this code can be modified and customized to display any information you reqquire. For this example we are going to create a Service Level Agreement (SLA) table to be able to assign devices to specific SLA levels (Bronze, Silver, Gold). Below is an example of what our new file Table-SLA.nmis will look like.

%hash = (
SLA => [{
Service_Level => {
header => ‘Service Level’,
display => ‘popup,header’,
value => [“Gold”, “Silver”, “Bronze”] }},
{ Email => {
header => ‘Email Address’,
display => ‘key,header,text’,
value => [“”] }},
{ Name => {
header => ‘Name’,
display => ‘header,text’,
value => [“”] }},
]
);

Para que entiendas lo que muestra este código, lo dividiremos en algunas secciones:

SLA => – This is the name of the table and it should match the naming convention from the filename, Table-<tableName>.nmis.

Service_Level => - Cada columna de la tabla se define con una entrada similar a ésta. En este caso la columna se llamaría Nivel_de_servicio. Para terminar de definir la columna los siguientes campos necesarios son los de cabecera, visualización y valor.

header => - Muestra lo que se mostrará cuando se vea la tabla. En este ejemplo se mostraría "Nivel de servicio".

display => 'key, header, text, popup' - header indica si debe estar en la cabecera o no, y text indica qué tipo de caja de entrada utilizar. Esta sección también incluye la clave, que se incluye como clave primaria si es necesario. La opción de visualización del popup hace una caja de selección de un solo valor, esto es equivalente a un elemento de formulario HTML "select". Este ejemplo muestra estos tres niveles de servicio como una visualización "popup".

valor => - Muestra cuál es el valor por defecto o la lista de selección. En este ejemplo, el valor se establecerá en Oro, Plata o Bronce, dependiendo del nivel de servicio.

Ahora que se entiende cómo se construye el código, se puede ver que la siguiente sección, Correo electrónico utiliza un encabezado de 'Dirección de correo electrónico'. Se muestra utilizando las opciones de visualización de clave, cabecera o texto. Observe que el valor se establece en comillas vacías, esto es porque el usuario introducirá la dirección de correo electrónico utilizando el teclado o la pantalla de `texto`. La sección de código "Nombre" tiene un formato similar al de la dirección de correo electrónico.

Paso 2. Añada la tabla a Tables.nmis.

Una vez creado el archivo de configuración de la tabla(Table-SLA.nmis en este caso), es necesario añadir la tabla al archivo Tables.nmis. Este archivo enumera todas las tablas que se envían con NMIS, así como las tablas personalizadas que se añaden. Este siguiente paso puede realizarse fácilmente utilizando la interfaz gráfica de usuario de NMIS.
Para ello, vaya a la barra de menú de NMIS y seleccione Sistema -> Configuración del sistema -> Tablas. Una vez que aparezca el menú Tablas, en la esquina superior derecha de la tabla debería ver Acción > añadir. Introduzca las propiedades de la tabla, el nombre de la tabla debe coincidir con el nombre en la Configuración de la Tabla (SLA en nuestro caso). El "Display Name" es lo que quieres que aparezca en el menú y el campo Description es para recordar lo que hace la Tabla. Una vez hecho esto, actualice el Tablero NMIS y verá su nueva tabla en la tabla de Tablas. Todavía no podrá acceder a su tabla, esto se debe a que no se han definido los permisos para la misma.

Paso 3. Cree los permisos en Access.nmis.

Para que la tabla muestre información, es necesario darle permisos de acceso en NMIS. Hay un script que se creó para hacer precisamente esto. Ejecute el siguiente script para añadir permisos por defecto a la tabla recién creada:
/usr/local/nmis8/admin/add_table_auth.pl SLA
La parte SLA al final del script es, por supuesto, el nombre de la tabla. Debería ver un mensaje una vez que se ejecute el script diciendo
Checking NMIS Authorization for SLA INFO: Autorización NO definida para SLA RW Access, AÑADIRLA AHORA
así como otro mensaje similar para el acceso a la vista. Este script se puede ejecutar varias veces, si ejecuta el script de nuevo no añadirá la tabla dos veces, sin embargo, le permitirá saber si los permisos se han creado para la tabla en particular.

Paso 4. Añade los datos a tu tabla.

Una vez que se han dado los permisos correctos a la tabla, es hora de añadirle una entrada de datos. Actualice el panel NMIS y navegue hasta su tabla - Sistema -> Configuración del Sistema -> SLA para el ejemplo actual. Es probable que aparezca un mensaje de error la primera vez que haga esto y es porque todavía no hay datos en la tabla.
Para añadir datos a la tabla, haga clic en Acción > Añadir. Introduzca un nombre, un nivel de servicio y un correo electrónico y haga clic en Añadir para guardarlo. Ahora, cuando abra la tabla, debería ver esta información completada. Esta información se almacena en /usr/local/nmis8/conf/SLA.nmis para el ejemplo actual. Si lo desea, puede añadir a este archivo utilizando el mismo formato que la primera entrada, si no desea utilizar la interfaz gráfica de usuario, ambos métodos funcionan. Eso es todo, ¡su nueva tabla SLA personalizada está creada! Puede crear tantas tablas como necesite y puede tomar el control del flujo de trabajo de su equipo. Estas tablas personalizadas son útiles en NMIS pero también se pueden utilizar en otros módulos de Opmantek como opCharts.

Uso de su tabla NMIS personalizada en opCharts

Si desea visualizar la tabla SLA o cualquier otra tabla creada dentro de las tablas de opCharts, existe una función que permite eliminar o añadir columnas de la tabla según se desee. Esta función está disponible para las versiones 3.2.2 y posteriores de opCharts. Una nota importante antes de comenzar es que las únicas vistas que soportan columnas personalizadas por el momento son la vista de Interfaces, la vista de Nodos, la vista de Apagones Programados y la vista de Contexto de Nodo o Widget de Información de Nodo.

Paso 1. Edite el archivo de configuración deseado para la vista correspondiente.

Una nota de precaución antes de cambiar nada, habilite esta función con cuidado, cuando actualice opCharts tendrá que vigilar de cerca ya que las tablas y las propiedades de los nodos pueden cambiar entre versiones. La actualización de opCharts puede romper la funcionalidad de una configuración de tabla personalizada. Si utiliza esta función, se recomienda actualizar en un entorno de prueba antes de actualizar su entorno de producción.

Habilitación de la función

Para habilitar esta función hay que hacer lo siguiente.
- Crear un directorio llamado /usr/local/omk/conf/table_schemas
- Copie el archivo de configuración de la vista específica que requiere modificación de /usr/local/ omk/lib/json/opCharts/table_schemas/ en /usr/local/omk/conf/table_schemas.
Nota - Sólo los archivos JSON necesarios deben ser copiados al directorio /usr/local/omk/conf/table_schemas ya que tener archivos de configuración innecesarios en este directorio puede hacer que las futuras actualizaciones sean impredecibles.
Dicho esto, cada vista tiene un archivo de configuración independiente. Dependiendo de la vista de opCharts a la que desee añadir su tabla NMIS SLA o cualquier otra tabla, deberá editar el archivo correspondiente. A continuación encontrará una lista de los nombres de los archivos dependiendo de la vista en la que desee mostrar su tabla:

Vista de interfaces - opCharts_interface-list.json
Vista de nodos - opCharts_node-list.json
Interrupciones programadas - opCharts_outage-schema.json
Contexto del nodo - opCharts_node-summary-table.json

For our example, we are going to be using the Nodes View or opCharts_node-list.json. Start by editing the file with your favorite text editor – vi /usr/local/omk/conf/ table_schemas/opCharts_node-list.json .
Once you open the file you will notice it is formatted into a list of the tables already shown in opCharts Nodes view. The order that these sections of code are in determines the order the tables will be displayed. This means you can have your custom table in any order you wish, further, you can remove unwanted parts of a table by removing the entry from this file. For the sake of this example, I will be adding our NMIS SLA table to the bottom of this file causing it to display at the end of the row of tables. The entry for the SLA table should be similar to the following below:

{
“name”: “configuration.SLA”,
“label”: “Service Level”,
“cell”: “String”
}

The “name” section is the name of the node property and requires you to call the intended configuration file which in our case is the configuration file we created (SLA.nmis). The “label” section of code is what text will be displayed in the table column. “Cell” is the cell type and typically is left as “string”.

Paso 2. Actualice la página de opCharts

Una vez editado el archivo, guárdelo, compruebe si hay errores de sintaxis y actualice la página web de opCharts. No es necesario reiniciar ningún demonio. Cuando la página se haya recargado, debería ver su nueva columna mostrada en la tabla. La tabla se muestra, sin embargo, no hay datos poblados todavía. Para que los datos aparezcan tenemos que modificar algunos archivos más.

Filtrado de nodos por atributos en NMIS/opCharts

Ahora que tiene su tabla de Niveles de Servicio en opCharts, ¿qué pasaría si quisiera utilizar la función de filtro de opCharts para mostrar sólo los dispositivos con un Nivel de Servicio Oro, por ejemplo? Esto se puede lograr haciendo unos pocos cambios rápidos.

Paso 1. Modifique la Tabla-Nodos.nmis.

Comience por editar el archivo Table-Nodes.nmis ubicado en /usr/local/nmis8/conf/Table-Nodes.nmis. Para este ejemplo, vamos a añadir nuestro campo de Nivel de Servicio.
Inserte el nuevo campo entre la entrada 'extra_options' y la entrada 'advanced_options'. Puede elegir dónde quiere que se muestre en NMIS, pero si sigue esta guía se mostrará debajo de la sección Extra Options en la tabla Nodes de NMIS.
El código en negrita a continuación muestra un ejemplo de dónde elegí insertar la tabla SLA. Esta sección es similar al diseño de nuestro archivoTable-SLA.nmis con una diferencia clave, la regla de validación añadida 'onefromlist'. Esta regla indica que el valor de la propiedad debe ser uno de los valores explícitos dados (Bronce, Plata, Oro), o uno de los valores de visualización por defecto si no se dan otros valores en esta regla.

{
netType => {
header => 'Tipo de red',
display => 'popup',
value => [ split(/\s*,\s*/, $C->{nettype_list}) ],
validate => { "onefromlist" => undef } }},
{
ubicación => {
header => 'Ubicación',
display => 'header,popup',
value => [ sort keys %{loadGenericTable('Ubicaciones')}],
validate => { "onefromlist" => undef } }},
{
SLA => {
header => 'Nivel de Servicio',
display => 'header,popup',
value => ["Oro", "Plata", "Bronce"],
validate => { "onefromlist" => undef } }
},

Paso 2. Compruebe que su tabla se está representando correctamente

Acceda a la GUI de NMIS y en el menú superior vaya a Sistema -> Configuración del sistema -> Nodos NMIS. Si los pasos fueron correctos se mostrará una columna de "Nivel de Servicio".

Paso 3. Modificar Config.nmis

Abra y edite el archivo Config.nmis con su editor de texto favorito. Este archivo se encuentra en
/usr/local/nmis8/conf/Config.nmis . Añade el nombre de la tabla (SLA) en la lista siguiendo el formato de las otras entradas. A continuación se muestra un fragmento del aspecto de este código utilizando nuestro ejemplo:

'node_summary_field_list' => 'host,uuid,customer,businessService,SLA,serviceStatus,snmpdown,wmidown,
remote_connection_name,remote_connection_url,host_addr,location',

Paso 4. Modificar opCommon.nmis

Add the new field to the opcharts_node_selector_sections in opCommon.nmis. The opCommon.nmis file is located at /usr/local/omk/conf/opCommon.nmis Follow the format of the code already present adding a new section for our Service Level table ‘SLA’. A snippet of what this code may look like is below:

‘opcharts_node_selector_sections’ => [
{
‘key’ => ‘nodestatus’,
‘name’ => ‘Node Status’
},
{
‘key’ => ‘group’,
‘name’ => ‘Group’
},
{
‘key’ => ‘roleType’,
‘name’ => ‘Node Role’
},
{
‘key’ => ‘SLA’,
‘name’ => ‘SLA’
},

Step 5. Verify the changes worked properly.

Después de realizar los cambios en el archivo opCommon.nmis, asegúrese de guardarlos y luego realice un reinicio del servicio omkd - service omkd restart. Una vez reiniciado el servicio, abra un navegador y navegue a la vista de Nodos en opCharts. El nuevo campo debería aparecer en la tabla, así como en el menú Filtro de nodos de la izquierda. Si sigue este ejemplo, debería aparecer la posibilidad de filtrar por SLA. Simplemente haga clic en el filtro y elija el
Nivel de Servicio y los nodos deberían ser filtrados dependiendo del nivel de servicio que se les haya asignado.

Conclusión

Los entornos de red son muy diferentes, al igual que sus ingenieros de red, lo que cambia significativamente la información que es importante reportar. NMIS y opCharts, así como los otros módulos de Opmantek, permiten increíbles niveles de personalización, dan la posibilidad de reportar la información que le conviene.
Para obtener más información sobre NMIS y opCharts y todas sus funciones, visite nuestro sitio web o envíenos un correo electrónico a contact@opmantek.com.

Como ingeniero de soporte de Opmantek, trabajo con muchas organizaciones que supervisan miles de dispositivos en sus redes. En entornos de red complejos, se generan miles o incluso millones de eventos en un periodo corto. Estos eventos van desde los críticos hasta los informativos, y la identificación y comprensión de ambos es clave para mantener una red en funcionamiento eficiente.

Mirar los registros de eventos es tedioso, y con muchos eventos, es fácil perderse los críticos. Los ingenieros me han dicho que dejaron de mirar las notificaciones de eventos porque había tantos, que se volvieron indiferentes a ellos. La solución de gestión de eventos de Opmantek, opEvents, no sólo reduce el spam de eventos, sino que también puede utilizarse para una gestión eficaz del tiempo y los eventos.

Un equipo de ingenieros de una gran organización estaba siendo bombardeado por eventos de cientos de máquinas durante su período de actualización de Windows programado regularmente. Este equipo ignoraba las notificaciones de eventos durante este tiempo ya que se producían con mucha frecuencia. Sin embargo, al mismo tiempo, tenían múltiples avisos de que un grupo de servidores junto con sus servicios se habían caído. Los registros de eventos indicaban que esto estaba ocurriendo, el personal de TI fue notificado pero, como ocurría durante un período típico de eventos ocupados, fueron ignorados. Como resultado, estos servidores permanecieron fuera de servicio hasta que alguien finalmente se dio cuenta del suceso horas más tarde. Este tiempo de inactividad supuso una pérdida de ingresos para la empresa y el descontento de algunos directivos. 

Se descubrió que este problema se produjo debido a que un router dejó de funcionar. El equipo buscó una solución y dio con opEvents de Opmantek. Con opEvents, su organización obtiene la capacidad de clasificar y correlacionar múltiples eventos de varias fuentes en un solo evento. Esto reduce el spam de eventos y el desorden para ayudar a su equipo a identificar rápidamente qué eventos son importantes y cuáles no. opEvents analizará, clasificará y correlacionará inteligentemente múltiples eventos de varias fuentes en un solo evento, reduciendo el ruido antes de crear cualquier alerta. Este equipo de ingenieros puede ahora identificar rápidamente no sólo cuando un enrutador está completamente muerto, sino también ver si algún enrutador tiene un rendimiento inferior, previniendo cualquier tiempo de inactividad futuro, haciendo que el equipo sea más proactivo.

El equipo de ingenieros del ejemplo anterior discutió cómo se podría utilizar opEvents para evitar que una situación como ésta se repita. Se les ocurrió una regla de correlación de eventos para notificarles en casos similares. 

Para crear este tipo de regla de correlación, comience por navegar por el archivo conf de su instalación de opEvents y creando una entrada en EventRules.nmis.

Una regla simple de correlación de eventos consiste en:

• Un evento nombreespecificando el nombre de su evento recién creado.
• Una lista de evento que son los eventos deseados para la correlación
• Un mínimo recuento de eventos que tienen que ser detectados para activar la regla
• Una lista opcional de groupby de la lista. Estas definen si el recuento se interpreta globalmente para todos los eventos nombrados, o por separado dentro de grupos más pequeños.
• Una opción enriquecer opcional. Esto ajusta el contenido del evento recién creado.
• La última ventana que define la ventana de tiempo a examinar para el evento.

A continuación se muestra un ejemplo de regla de correlación de eventos:

‘3’=> { name => ‘Customer Outage’, events => [“Node Down”,”SNMP Down”], window => ’60’, count=> 5, groupby=>[‘node.customer’], # count separately for every observed value of customer enrich=>{priority => 3, answer => 42}, # any such items gets inserted in the new event }, The example shows an event correlation event rule indicating that when the events “Node Down” and “SNMP Down” are triggered within a 60-second window, separate them into per-customer groups; if it counts 5 or more events in a group, then create a new event called Customer Outage. This is only one example of a custom event correlation rule. There are many more examples, use cases, and features that are discussed more on our opEvents Wiki page.

El uso de esta herramienta de gestión de eventos reducirá el spam de eventos, lo que permitirá a su equipo darse cuenta de los eventos críticos que necesitan una acción rápida. Los eventos importantes serán más difíciles de pasar por alto durante las tormentas de eventos. Los eventos redundantes pueden reducirse mediante la automatización de la gestión de eventos. Ahorre tiempo, reduzca los costes operativos, obtenga información sobre la red y mantenga su red funcionando sin problemas. Amplíe su conjunto de herramientas con estas características y otras más en opEvents y tome el control de su red.

Para obtener más información sobre las herramientas de gestión de eventos de Opmantek, otras soluciones de Opmantek o para programar una demostración, visite nuestro sitio web en www.opmantek.com. También puede enviarnos un correo electrónico a contact@opmantek.com.