Dependencias de triggers

Las dependencias de triggers se pueden utilizar para evitar alertas que no estén relacionadas con la causa raíz.

Consulte todas las mejores prácticas.

Descripción general

A veces, la disponibilidad de un host depende de otro. Un server que se encuentra detrás de un router dejará de estar disponible si el router deja de funcionar. Si se configuran triggers para ambos, es posible que reciba notificaciones sobre dos hosts caídos, cuando en realidad el único responsable era el router.

En este caso, puede resultar útil establecer una dependencia entre los hosts. Una vez configurada la dependencia, las notificaciones de los elementos dependientes pueden retenerse y enviarse únicamente la notificación sobre el problema raíz.

Aunque Zabbix no admite dependencias directas entre hosts, estas pueden definirse mediante un método más flexible: las dependencias entre triggers. Un trigger puede depender de uno o varios triggers.

En nuestro sencillo ejemplo, abrimos el formulario de configuración del trigger del server y establecemos que depende del trigger correspondiente del router. Con esta dependencia, el trigger del server no cambiará de estado mientras el trigger del que depende se encuentre en estado 'PROBLEM'; por lo tanto, no se ejecutarán acciones dependientes ni se enviarán notificaciones.

Si tanto el server como el router están caídos y se establece una dependencia entre el trigger "server caído" y el trigger "router caído", Zabbix no ejecutará acciones para el trigger dependiente.

Mientras el trigger principal se encuentre en estado PROBLEM, es posible que sus elementos dependientes informen de valores que no sean fiables. Por lo tanto, los triggers dependientes no se volverán a evaluar hasta que el trigger principal (el router en el ejemplo anterior):

  • vuelva del estado 'PROBLEM' al estado 'OK';
  • cambie su estado de 'PROBLEM' a 'UNKNOWN';
  • se cierre manualmente, mediante correlación o con ayuda de las funciones date and time y/o nodata();
  • se resuelva mediante el valor de un item que no intervenga en el trigger dependiente;
  • se deshabilite, tenga un item deshabilitado o un host con un item deshabilitado

En todos los casos mencionados anteriormente, el trigger dependiente (el server) se volverá a evaluar únicamente cuando se reciba una nueva métrica para él. Esto significa que el trigger dependiente podría no actualizarse inmediatamente.

Además:

  • Se puede añadir una dependencia de trigger desde cualquier trigger de host a cualquier otro trigger de host, siempre que no se genere una dependencia circular.
  • Se puede añadir una dependencia de trigger de un template a otro. Si algún trigger del template A depende de algún trigger del template B, el template A solo podrá vincularse a un host (o a otro template) junto con el template B, mientras que el template B podrá vincularse por separado a un host (o a otro template).
  • Se puede añadir una dependencia de trigger desde un trigger de template a un trigger de host. En este caso, vincular dicho template a un host creará un trigger de host que dependerá del mismo trigger de template del que dependía el trigger original. Esto permite, por ejemplo, tener un template en el que algunos triggers dependan de los triggers del router (host). Todos los hosts vinculados a este template dependerán de ese router específico.
  • No se puede añadir una dependencia de trigger desde un trigger de host a un trigger de template.
  • Se puede añadir una dependencia de trigger desde un prototipo de trigger a otro prototipo de trigger (dentro de la misma regla de descubrimiento de bajo nivel) o a un trigger real. Un prototipo de trigger no puede depender de un prototipo de trigger de una regla LLD diferente ni de un trigger creado a partir de un prototipo de trigger. Un prototipo de trigger de host no puede depender de un trigger de un template.

Configuración

Para definir una dependencia:

  1. Abra la pestaña Dependencias en el formulario de configuración del trigger.

  2. Haga clic en Añadir en la sección Dependencias y seleccione uno o varios triggers de los que dependerá el trigger.

  3. Haga clic en Actualizar.

Ahora el trigger muestra la indicación de su dependencia en la lista.

Ejemplo de varias dependencias

Por ejemplo, el Host está detrás de Router2 y Router2 está detrás de Router1.

Zabbix - Router1 - Router2 - Host

Si Router1 está caído, entonces, obviamente, Host y Router2 también son inalcanzables, pero recibir tres notificaciones sobre que Host, Router1 y Router2 están caídos es excesivo.

Así que, en este caso, definimos dos dependencias:

el trigger 'Host is down' depende del trigger 'Router2 is down'
el trigger 'Router2 is down' depende del trigger 'Router1 is down'

Antes de cambiar el estado del trigger 'Host is down', Zabbix comprobará las dependencias correspondientes del trigger. Si se encuentran y uno de esos triggers está en el estado Problem, entonces el estado del trigger no se cambiará, no se ejecutarán las acciones y no se enviarán notificaciones.

Zabbix realiza esta comprobación de forma recursiva. Si Router1 o Router2 es inalcanzable, el trigger de Host no se actualizará.