3 Dependencias del iniciador

Descripció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 es el responsable.

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: 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 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 y/o nodata();
  • se resuelva por el valor de un item que no esté involucrado en el trigger dependiente;
  • se desactive, tenga un item desactivado o un host de item desactivado

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 de inmediato.

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 puede vincularse a un host (u otra template) junto con la template B, pero la template B puede vincularse 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 el trigger dependía. 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:

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

  2. Haga clic en Agregar en la sección Dependencias y seleccione uno o más triggers de los que dependerá el trigger.

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

Zabbix - Router1 - Router12 - Host

Si el Router1 está inactivo, entonces, obviamente, el Host y el Router2 tampoco son accesibles, recibir tres notificaciones sobre el Host, el Router1 y el Router2 que están inactivos es excesivo.

Entonces en este caso definimos dos dependencias:

el iniciador 'El host está inactivo' depende del iniciador 'El enrutador 2 está inactivo'
el iniciador 'Router2 está inactivo' depende del iniciador 'Router1 está inactivo'

Antes de cambiar el estado del iniciador 'Host inactivo', Zabbix verifica las dependencias de activación correspondientes. Si se encuentran tales y uno de esos iniciadores está en el estado 'Problema', entonces el estado del iniciador 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 están inalcanzables, el iniciador del Host no se actualizará.