Correlación de eventos basada en trigger

Resumen

La correlación de eventos basada en trigger permite correlacionar problemas separados notificados por un mismo trigger.

Aunque, en general, un evento OK puede cerrar todos los eventos de problema creados por un trigger, hay casos en los que se necesita un enfoque más detallado. Por ejemplo, al supervisar archivos de registro, es posible que desee detectar ciertos problemas en un archivo de registro y cerrarlos individualmente en lugar de todos juntos.

Este es el caso de los triggers que tienen el parámetro PROBLEM event generation mode establecido en Multiple. Estos triggers se usan normalmente para la supervisión de registros, el procesamiento de traps, etc.

En Zabbix es posible relacionar eventos de problema basándose en etiquetado. Las etiquetas se usan para extraer valores y crear una identificación para los eventos de problema. Aprovechando esto, los problemas también se pueden cerrar individualmente en función de la etiqueta coincidente.

En otras palabras, el mismo trigger 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 mediante la etiqueta del evento.

Cómo funciona

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

Line1: Service 1 stopped
Line2: Service 2 stopped
Line3: Service 1 was restarted
Line4: Service 2 was restarted

La idea de la correlación de eventos es poder asociar el evento de problema de la Line1 con la resolución de la Line3 y el evento de problema de la Line2 con la resolución de la Line4, y cerrar estos problemas uno por uno:

Line1: Service 1 stopped
Line3: Service 1 was restarted #problem from Line 1 closed

Line2: Service 2 stopped
Line4: Service 2 was restarted #problem from Line 2 closed

Para ello, necesita etiquetar estos eventos relacionados como, por ejemplo, "Service 1" y "Service 2". Esto puede hacerse 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 respectivamente como "Service 1" y "Service 2" y el problema puede asociarse con la resolución.

Configuración

Item

Para empezar, es posible que desee configurar un item que supervise un archivo de registro, por ejemplo:

log[/var/log/syslog]

Una vez configurado el item, espere un minuto para que se apliquen los cambios de configuración y luego vaya a Latest data para asegurarse de que el item haya comenzado a recopilar datos.

Trigger

Con el item en funcionamiento, necesitas 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 

Luego define 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
• Introduce el nombre de la etiqueta para la coincidencia de eventos

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

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

• Los macros indexados siempre hacen referencia 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á al ú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 para el momento de la recuperación, los eventos tendrán etiquetas diferentes y no se correlacionarán.

• Con dos aplicaciones escribiendo 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, usando expresiones regulares separadas en los valores de etiqueta para extraer los nombres de, por ejemplo, service A y service B del 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 que no coincidan producirán valores de etiqueta vacíos y un único valor de etiqueta vacío tanto en los eventos de problema como en los de OK es suficiente para correlacionarlos. Así, un mensaje de recuperación de service A podría 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 usa el 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.