Table of Contents
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.
Visión general
A veces, la disponibilidad de un host depende de otro. Un servidor que está detrás de un router será inaccesible si el router se cae. Con triggers configurados para ambos, podrías recibir notificaciones de que dos hosts están caídos, cuando en realidad solo el router es el responsable.
Aquí es donde una dependencia entre hosts podría ser útil. Con la dependencia configurada, las notificaciones de los dependientes podrían retenerse y solo se enviaría la notificación del problema raíz.
Aunque Zabbix no admite dependencias entre hosts directamente, estas pueden definirse con otro método más flexible: las dependencias de triggers. Un trigger puede tener uno o más triggers de los que depende.
Así que en nuestro ejemplo simple, abrimos el formulario de configuración del trigger del servidor y configuramos que depende del trigger respectivo del router. Con dicha dependencia, el trigger del servidor no cambiará su estado mientras el trigger del que depende esté en estado 'PROBLEM', y por lo tanto no se tomarán acciones dependientes ni se enviarán notificaciones.
Si tanto el servidor como el router están caídos y existe la dependencia, Zabbix no ejecutará acciones para el trigger dependiente.
Mientras el trigger padre esté en estado PROBLEM, sus dependientes pueden reportar valores que no son confiables. Por lo tanto, los triggers dependientes no se volverán a evaluar hasta que el trigger padre (el router en el ejemplo anterior):
- vuelva del estado 'PROBLEM' al estado 'OK';
- cambie su estado de 'PROBLEM' a 'UNKNOWN';
- se cierre manualmente, por correlación o con la ayuda de las funciones de fecha y hora y/o nodata();
- se resuelva por el valor de un item que no esté involucrado en el trigger dependiente;
- esté deshabilitado, tenga un item deshabilitado o un host de item deshabilitado
En todos los casos mencionados anteriormente, el trigger dependiente (servidor) solo se volverá a evaluar cuando se reciba una nueva métrica para él. Esto significa que el trigger dependiente puede no actualizarse inmediatamente.
Además:
- Se puede agregar una dependencia de trigger desde cualquier trigger de host a cualquier otro trigger de host, siempre que no resulte en una dependencia circular.
- Se puede agregar una dependencia de trigger de una template a otra. Si algún trigger de la template A depende de algún trigger de la template B, la template A solo se puede vincular a un host (u otra template) junto con la template B, pero la template B se puede vincular a un host (u otra template) sola.
- Se puede agregar una dependencia de trigger de un trigger de template a un trigger de host. En este caso, vincular dicha template a un host creará un trigger de host que depende del mismo trigger de template del que dependía el trigger. Esto permite, por ejemplo, tener una template donde algunos triggers dependan de los triggers del router (host). Todos los hosts vinculados a esta template dependerán de ese router específico.
- No se puede agregar una dependencia de trigger de un trigger de host a un trigger de template.
- Se puede agregar una dependencia de trigger de un trigger prototipo a otro trigger prototipo (dentro de la misma regla de descubrimiento de bajo nivel) o a un trigger real. Un trigger prototipo no puede depender de un trigger prototipo de una regla LLD diferente ni de un trigger creado a partir de un trigger prototipo. Un trigger prototipo de host no puede depender de un trigger de una template.
Configuración
Para definir una dependencia, abra la pestaña Dependencias en el formulario de configuración del trigger. Haga clic en Añadir en el bloque 'Dependencias' y seleccione uno o más triggers de los que dependerá el trigger.
Haga clic en Actualizar. Ahora el trigger tiene la indicación de su dependencia en la lista.
Ejemplo de varias dependencias
Por ejemplo, el Host está detrás del Router2 y el Router2 está detrás del Router1.
Si el Router1 está caído, entonces obviamente el Host y el Router2 también son inaccesibles, sin embargo, recibir tres notificaciones sobre el Host, el Router1 y el Router2 estando todos 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 de trigger correspondientes. Si se encuentran tales dependencias y uno de esos triggers está en estado Problem, entonces el estado del trigger no será cambiado, las acciones no se ejecutarán y no se enviarán notificaciones.
Zabbix realiza esta comprobación de forma recursiva. Si el Router1 o el Router2 son inaccesibles, el trigger del Host no se actualizará.