1 Correlación de eventos basada en disparadores

Visión general

La correlación de eventos basada en disparadores permite correlacionar problemas separados reportados por un disparador.

Si bien generalmente un evento OK puede cerrar todos los eventos de problema creados por un disparador, hay casos en los que se necesita un enfoque más detallado. Por ejemplo, al monitorizar archivos de registro, es posible que desee descubrir ciertos problemas en un archivo de registro y cerrarlos individualmente en lugar de todos juntos.

Este es el caso de los disparadores que tienen el parámetro Modo de generación de eventos PROBLEM establecido en Múltiple. Dichos disparadores se utilizan normalmente para la monitorización de registros, procesamiento de traps, etc.

Es posible en Zabbix relacionar eventos de problema basados en etiquetado. Las etiquetas se utilizan para extraer valores y crear una identificación para los eventos de problema. Aprovechando esto, los problemas también pueden cerrarse individualmente en función de la coincidencia de la etiqueta.

En otras palabras, el mismo disparador puede crear eventos separados identificados por la etiqueta del evento. Por lo tanto, los eventos de problema pueden identificarse uno por uno y cerrarse por separado en función de la identificación por la etiqueta del evento.

Cómo funciona

En la monitorización de logs puede encontrar líneas similares a estas:

Línea1: Servicio 1 detenido
Línea2: Servicio 2 detenido
Línea3: Servicio 1 reiniciado
Línea4: Servicio 2 reiniciado

La idea de la correlación de eventos es poder emparejar el evento de problema de la Línea1 con la resolución de la Línea3 y el evento de problema de la Línea2 con la resolución de la Línea4, y cerrar estos problemas uno por uno:

Línea1: Servicio 1 detenido
Línea3: Servicio 1 reiniciado #problema de la Línea 1 cerrado

Línea2: Servicio 2 detenido
Línea4: Servicio 2 reiniciado #problema de la Línea 2 cerrado

Para hacer esto, necesita etiquetar estos eventos relacionados como, por ejemplo, "Servicio 1" y "Servicio 2". Esto se puede hacer aplicando una expresión regular a la línea del log para extraer el valor de la etiqueta. Luego, cuando se crean los eventos, se etiquetan como "Servicio 1" y "Servicio 2" respectivamente y el problema puede emparejarse con la resolución.

Configuración

Métrica

Para empezar, puede que desee configurar una métrica que monitorice un archivo de registro, por ejemplo:

log[/var/log/syslog]

Con la métrica configurada, espere un minuto para que se apliquen los cambios de configuración y luego vaya a Datos más recientes para asegurarse de que la métrica ha comenzado a recopilar datos.

Trigger

Con el item en funcionamiento, debe configurar el trigger. Es importante decidir qué entradas del archivo de registro merecen atención. Por ejemplo, la siguiente expresión de trigger buscará una cadena como 'Stopping' para señalar posibles problemas:

find(/My host/log[/var/log/syslog],,"regexp","Stopping")=1 

A continuación, defina una expresión de recuperación. La siguiente expresión de recuperación resolverá todos los problemas si se encuentra una línea de registro que contenga la cadena "Starting":

find(/My host/log[/var/log/syslog],,"regexp","Starting")=1 

Como no queremos eso, es importante asegurarse de alguna manera de que los problemas raíz correspondientes se cierren, no solo todos los problemas. Ahí es donde el etiquetado puede ayudar.

Los problemas y las resoluciones se pueden emparejar especificando una etiqueta en la configuración del trigger. Deben realizarse los siguientes ajustes:

• Problem event generation mode: Multiple
• OK event closes: All problems if tag values match
• Introduzca el nombre de la etiqueta para la coincidencia de eventos

• configure las tags para extraer valores de etiqueta de las líneas de registro

Si se configura correctamente, podrá ver eventos de problema etiquetados por aplicación y asociados con su resolución en Monitoring > Problems.

• Las macros indexadas siempre se refieren al campo Expression de la configuración del trigger, no a la Recovery expression. Por ejemplo, en un evento de recuperación, {ITEM.VALUE1} resolverá el último valor del primer item en la expresión del problema en el momento de la recuperación. Si la expresión de recuperación se basa en un item diferente y el valor del item de la expresión del problema cambia en el momento de la recuperación, los eventos tendrán etiquetas diferentes y no se correlacionarán.

• Con dos aplicaciones que escriben mensajes de error y de recuperación en el mismo archivo de registro, un usuario puede decidir usar dos etiquetas de service en el mismo trigger con diferentes valores de etiqueta, utilizando expresiones regulares separadas en los valores de etiqueta para extraer los nombres de, por ejemplo, service A y service B de la macro {ITEM.VALUE} (por ejemplo, cuando los formatos de mensaje difieren). Sin embargo, esto puede no funcionar como se esperaba si no hay coincidencia con las expresiones regulares. Las expresiones regulares sin coincidencia producirán valores de etiqueta vacíos y un único valor de etiqueta vacío en los eventos de problema y OK es suficiente para correlacionarlos. Por lo tanto, un mensaje de recuperación de service A puede cerrar accidentalmente un mensaje de error de service B.

• Las etiquetas reales y los valores de etiqueta solo se vuelven visibles cuando se dispara un trigger. Si la expresión regular utilizada no es válida, se reemplaza silenciosamente por una cadena *UNKNOWN*. Si se omite el evento de problema inicial con un valor de etiqueta *UNKNOWN*, pueden aparecer eventos OK posteriores con el mismo valor de etiqueta *UNKNOWN* que podrían cerrar eventos de problema que no deberían haber cerrado.

• Si un usuario utiliza la macro {ITEM.VALUE} sin funciones de macro como valor de etiqueta, se aplica la limitación de 255 caracteres. Cuando los mensajes de registro son largos y los primeros 255 caracteres no son específicos, esto también puede dar lugar a etiquetas de evento similares para problemas no relacionados.