3 Dependencias del iniciador

Resumen

A veces la disponibilidad de un host depende de otro. Un server que está detrás de un router dejará de ser accesible si el router deja de funcionar. Con triggers configurados para ambos, podría recibir notificaciones sobre dos hosts caídos, cuando en realidad el único culpable era el router.

Aquí es donde una dependencia entre hosts puede resultar útil. Con la dependencia configurada, las notificaciones de los dependientes podrían retenerse y enviarse solo 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 trigger. Un trigger puede tener uno o más triggers de los que depende.

Así, en nuestro ejemplo sencillo, 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á su estado mientras el trigger del que depende esté 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 down" y el trigger "router down", Zabbix no ejecutará acciones para el trigger dependiente.

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

  • vuelva de estado 'PROBLEM' a estado 'OK';
  • cambie su estado de 'PROBLEM' a 'UNKNOWN';
  • se cierre manualmente, por correlación o con la ayuda de las funciones date and time y/o nodata();
  • se resuelva mediante un valor de un item que no intervenga 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 (server) se volverá a evaluar solo cuando se reciba una nueva métrica para él. Esto significa que es posible que el trigger dependiente no se actualice de inmediato.

Además:

  • La dependencia de trigger puede añadirse desde cualquier trigger de host a cualquier otro trigger de host, siempre que no genere una dependencia circular.
  • La dependencia de trigger puede añadirse de un template a otro. Si algún trigger del template A depende de algún trigger del template B, el template A solo puede vincularse a un host (o a otro template) junto con el template B, pero el template B puede vincularse a un host (o a otro template) por separado.
  • La dependencia de trigger puede añadirse desde un trigger de template a un trigger de host. En este caso, al vincular dicho template a un host se creará un trigger de host que dependerá del mismo trigger de template del que dependía el trigger. 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.
  • La dependencia de trigger no puede añadirse desde un trigger de host a un trigger de template.
  • La dependencia de trigger puede añadirse desde un trigger prototype a otro trigger prototype (dentro de la misma regla de low-level discovery) o a un trigger real. Un trigger prototype no puede depender de un trigger prototype de una regla LLD diferente ni de un trigger creado a partir de un trigger prototype. Un trigger prototype de host no puede depender de un trigger de un template.

Configuración

Para definir una dependencia:

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

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

  3. Haga clic en Update.

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, el host y Router2 también son inalcanzables, pero recibir tres notificaciones sobre que el 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 de trigger correspondientes. 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 no es alcanzable, el trigger del host no se actualizará.