Eventos y reacción

Resumen

Hay varios tipos de eventos generados en Zabbix:

  • eventos de trigger - cada vez que un trigger cambia su estado (OK→PROBLEM→OK)
  • eventos de servicio - cada vez que un servicio cambia su estado (OK→PROBLEM→OK)
  • eventos de descubrimiento - cuando se detectan hosts o servicios
  • eventos de autorregistro - cuando los agents activos se registran automáticamente por el server
  • eventos internos - cuando un item/regla de descubrimiento de bajo nivel deja de ser compatible o un trigger entra en un estado desconocido

Los eventos tienen marca de tiempo y pueden ser la base de acciones como enviar correos de notificación, crear tickets o ejecutar comandos remotos.

Para ver los detalles del evento en el frontend, vaya a Monitoring > Problems. Allí puede hacer clic en la fecha y hora del evento para abrir la página de detalles del evento, donde puede ver información adicional sobre el evento, incluido si fue suprimido por mantenimiento o suprimido manualmente por un usuario.

Problem resolution

Problem events created by triggers are resolved automatically, if the condition that caused the problem no longer exists.

To add flexibility and convenience to problem event management, the following options exist:

Eventos de trigger

El cambio de estado del trigger es la fuente de eventos más frecuente y más importante. Cada vez que el trigger cambia de estado, se genera un evento. El evento contiene detalles del cambio de estado del trigger: cuándo ocurrió y cuál es el nuevo estado.

Los triggers crean dos tipos de eventos: Problem y OK.

Eventos de problema

Se crea un evento de problema:

  • cuando una expresión de trigger se evalúa como TRUE si el trigger está en estado OK;
  • cada vez que una expresión de trigger se evalúa como TRUE si la generación de múltiples eventos de problema está habilitada para el trigger.
Eventos OK

Un evento OK cierra el o los eventos de problema relacionados y puede ser creado por 3 componentes:

  • triggers - según la configuración de "generación de eventos OK" y "los eventos OK cierran";
  • correlación de eventos
  • gestor de tareas - cuando un evento se cierra manualmente

Los triggers tienen una configuración de "OK event generation" que controla cómo se generan los eventos OK:

  • Expression - se genera un evento OK para un trigger en estado de problema cuando su expresión evalúa a FALSE. Esta es la configuración más simple y está habilitada de forma predeterminada.
  • Recovery expression - se genera un evento OK para un trigger en estado de problema cuando su expresión evalúa a FALSE y la expresión de recuperación evalúa a TRUE. Esto puede usarse si el criterio de recuperación del trigger es diferente del criterio de problema.
  • None - nunca se genera un evento OK. Esto puede usarse junto con la generación de múltiples eventos de problema para simplemente enviar una notificación cuando ocurre algo.

Además, los triggers tienen una configuración de "OK event closes" que controla qué eventos de problema se cierran:

  • All problems - un evento OK cerrará todos los problemas abiertos creados por el trigger
  • All problems if tag values match - un evento OK cerrará los problemas abiertos creados por el trigger que tengan al menos un valor de etiqueta coincidente. La etiqueta se define mediante la configuración del trigger "Tag for matching". Si no hay eventos de problema que cerrar, entonces no se genera el evento OK. A esto a menudo se le llama correlación de eventos a nivel de trigger.
Correlación de eventos

La correlación de eventos (también llamada correlación global de eventos) es una forma de configurar reglas personalizadas de cierre de eventos (lo que da lugar a la generación de eventos OK).

Las reglas definen cómo se emparejan los nuevos eventos de problema con los eventos de problema existentes y permiten cerrar el nuevo evento o los eventos coincidentes generando los correspondientes eventos OK.

Sin embargo, la correlación de eventos debe configurarse con mucho cuidado, ya que puede afectar negativamente al rendimiento del procesamiento de eventos o, si está mal configurada, cerrar más eventos de los previstos (en el peor de los casos, incluso podrían cerrarse todos los eventos de problema). Algunos consejos de configuración:

  1. reduzca siempre el ámbito de la correlación estableciendo una etiqueta única para el evento de control (el evento que se empareja con eventos antiguos) y use la condición de correlación 'new event tag'
  2. no olvide añadir una condición basada en el evento antiguo al usar la operación 'close old event', o podrían cerrarse todos los problemas existentes
  3. evite usar nombres de etiqueta comunes utilizados por diferentes configuraciones de correlación
Administrador de tareas

Si la opción 'Allow manual close' está habilitada para trigger, entonces es posible cerrar manualmente los eventos de problema generados por el trigger. Esto se hace en el frontend cuando se actualiza un problema. El evento no se cierra directamente; en su lugar, se crea una tarea de 'close event', que el administrador de tareas procesa poco después. El administrador de tareas generará un evento OK correspondiente y el evento de problema se cerrará.

Eventos de servicio

Los eventos de servicio se generan solo si las acciones de servicio para estos eventos están habilitadas. En este caso, cada cambio del estado del servicio crea un nuevo evento:

  • Evento de problema - cuando el estado del servicio cambia de OK a Problem
  • Evento OK - cuando el estado del servicio cambia de Problem a OK

El evento contiene detalles del cambio de estado del servicio: cuándo ocurrió y cuál es el nuevo estado.

Eventos de descubrimiento

Zabbix analiza periódicamente los rangos de IP definidos en las reglas de descubrimiento de red. La frecuencia de la comprobación se puede configurar de forma individual para cada regla. Una vez que se descubre un host o un servicio, se genera un evento de descubrimiento (o varios eventos).

Zabbix genera los siguientes eventos:

Evento Cuándo se genera
Service Up Cada vez que Zabbix detecta un servicio activo.
Service Down Cada vez que Zabbix no puede detectar el servicio.
Host Up Si al menos uno de los servicios está UP para la IP.
Host Down Si todos los servicios no responden.
Service Discovered Si el servicio vuelve después de un tiempo de inactividad o se descubre por primera vez.
Service Lost Si el servicio se pierde después de haber estado activo.
Host Discovered Si el host vuelve después de un tiempo de inactividad o se descubre por primera vez.
Host Lost Si el host se pierde después de haber estado activo.

Eventos de autorregistro de agent activo

El autorregistro de agent activo crea eventos en Zabbix.

Si está configurado, se crea un evento de autorregistro de agent activo cuando un agent activo previamente desconocido solicita comprobaciones o si los metadatos del host han cambiado. El server agrega un nuevo host autorregistrado, usando la dirección IP y el puerto recibidos del agent.

Para obtener más información, consulte la página de autorregistro de agent activo.

Eventos internos

Los eventos internos ocurren cuando:

  • un item cambia de estado de 'normal' a 'unsupported'
  • un item cambia de estado de 'unsupported' a 'normal'
  • una regla de descubrimiento de bajo nivel cambia de estado de 'normal' a 'unsupported'
  • una regla de descubrimiento de bajo nivel cambia de estado de 'unsupported' a 'normal'
  • un trigger cambia de estado de 'normal' a 'unknown'
  • un trigger cambia de estado de 'unknown' a 'normal'

El objetivo de introducir eventos internos es permitir que los usuarios sean notificados cuando se produzca cualquier evento interno, por ejemplo, cuando un item pasa a estar unsupported y deja de recopilar datos.

Los eventos internos solo se crean cuando las acciones internas para estos eventos están habilitadas. Para detener la generación de eventos internos (por ejemplo, para items que pasan a estar unsupported), deshabilite todas las acciones para eventos internos en Alerts > Actions > Internal actions.

Si las acciones internas están deshabilitadas, mientras un objeto esté en el estado 'unsupported', el evento de recuperación para este objeto seguirá creándose.

Si las acciones internas están habilitadas, mientras un objeto esté en el estado 'unsupported', el evento de recuperación para este objeto se creará, aunque no se haya creado un 'problem event' para el objeto.

Véase también: Receiving notification on unsupported items