3 Dependencias del iniciador

Descripción general

A veces, la disponibilidad de un equipo depende de otro. Un servidor que está detrás de un router se volverá inaccesible si el router falla. Con disparadores configurados para ambos, podrías recibir notificaciones de que dos equipos están caídos, cuando en realidad solo el router era el responsable.

Aquí es donde puede ser útil establecer alguna dependencia entre equipos. Con la dependencia configurada, las notificaciones de los dependientes podrían retenerse y solo se enviaría la notificación sobre el problema raíz.

Aunque Zabbix no admite dependencias entre equipos directamente, estas pueden definirse mediante otro método más flexible: las dependencias de disparadores. Un disparador puede tener uno o más disparadores de los que depende.

Así, en nuestro ejemplo sencillo, abrimos el formulario de configuración del disparador del servidor y establecemos que depende del disparador correspondiente del router. Con esta dependencia, el disparador del servidor no cambiará su estado mientras el disparador del que depende esté en estado 'PROBLEM' (PROBLEMA), por lo que 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 disparador dependiente.

Mientras el disparador principal esté en estado PROBLEM, sus dependientes pueden informar valores que no son confiables. Por lo tanto, los disparadores dependientes no se volverán a evaluar hasta que el disparador principal (el router en el ejemplo anterior):

• vuelva del estado 'PROBLEM' (PROBLEMA) al estado 'OK';
• cambie su estado de 'PROBLEM' (PROBLEMA) a 'UNKNOWN' (DESCONOCIDO);
• 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 ítem que no esté involucrado en el disparador dependiente;
• se desactive, tenga un ítem desactivado o un equipo de ítem desactivado

En todos los casos mencionados anteriormente, el disparador dependiente (servidor) solo se volverá a evaluar cuando se reciba una nueva métrica para él. Esto significa que el disparador dependiente puede no actualizarse inmediatamente.

Además:

• Se puede añadir una dependencia de disparador desde cualquier disparador de equipo a cualquier otro disparador de equipo, siempre que no resulte en una dependencia circular.
• Se puede añadir una dependencia de disparador de una plantilla a otra. Si algún disparador de la plantilla A depende de algún disparador de la plantilla B, la plantilla A solo puede vincularse a un equipo (u otra plantilla) junto con la plantilla B, pero la plantilla B puede vincularse a un equipo (u otra plantilla) sola.
• Se puede añadir una dependencia de disparador de un disparador de plantilla a un disparador de equipo. En este caso, vincular dicha plantilla a un equipo creará un disparador de equipo que depende del mismo disparador de plantilla del que dependía el disparador. Esto permite, por ejemplo, tener una plantilla donde algunos disparadores dependan de los disparadores del router (equipo). Todos los equipos vinculados a esta plantilla dependerán de ese router específico.
• No se puede añadir una dependencia de disparador de un disparador de equipo a un disparador de plantilla.
• Se puede añadir una dependencia de disparador de un prototipo de disparador a otro prototipo de disparador (dentro de la misma regla de descubrimiento de bajo nivel) o a un disparador real. Un prototipo de disparador no puede depender de un prototipo de disparador de una regla LLD diferente ni de un disparador creado a partir de un prototipo de disparador. Un prototipo de disparador de equipo no puede depender de un disparador de una plantilla.

Configuración

Para definir una dependencia, abra la pestaña Dependencias en el disparador formulario de configuración. Haga clic en Agregar en el Bloquee 'Dependencias' y seleccione uno o más desencadenantes que el desencadenante dependerá de.

Haga clic en Actualizar. Ahora el disparador 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á.