[comment]: # ({41c636fc-d5d0048d})
# 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](/manual/config/triggers/best_practices).

[comment]: # ({/41c636fc-d5d0048d})

[comment]: # ({32910aff-26bda053})
### Visión general

A veces, la disponibilidad de un host depende de otro. Un servidor que
está detrás de un router se volverá 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 era el culpable.

Aquí es donde una dependencia entre hosts puede ser útil. Con
la dependencia configurada, las notificaciones de los dependientes pueden ser retenidas y
solo se enviará la notificación sobre el problema raíz.

Aunque Zabbix no admite dependencias entre hosts directamente, estas
pueden definirse con otro método más flexible: 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 se establece una dependencia entre el trigger "servidor caído" y el trigger "router caído", 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](/manual/config/triggers/expression/time) y/o [nodata()](/manual/config/triggers/expression/history#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) se volverá a evaluar solo 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 dependen 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.

[comment]: # ({/32910aff-26bda053})

[comment]: # ({6656cfaa-c4578b73})
### Configuración

Para definir una dependencia:

1.  Abra la pestaña *Dependencias* en el [formulario de configuración](/manual/config/triggers/trigger#configuration) del trigger.
2.  Haga clic en *Añadir* en la sección *Dependencias* y seleccione uno o más triggers de los que dependerá el trigger.

    ![](../../../../../assets/es/manual/config/triggers/dependency.png){width="600"}

3.  Haga clic en *Actualizar*.

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

![](../../../../../assets/es/manual/config/triggers/dependency_list.png)

[comment]: # ({/6656cfaa-c4578b73})

[comment]: # ({ca1527f7-4dc2ce6b})
##### Ejemplo de varias dependencias

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

    Zabbix - Router1 - Router2 - Host

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á.

[comment]: # ({/ca1527f7-4dc2ce6b})