Você está visualizando a documentação da versão de desenvolvimento, que pode estar incompleta.
Esta página foi traduzida automaticamente. Se você notar um erro, selecione-o e pressione Ctrl+Enter para reportá-lo aos editores.

3 Dependências de trigger

Visão geral

Às vezes, a disponibilidade de um host depende de outro. Um servidor que está atrás de um roteador ficará inacessível se o roteador cair. Com triggers configurados para ambos, você pode receber notificações sobre dois hosts inativos - enquanto apenas o roteador era o culpado.

É aí que alguma dependência entre hosts pode ser útil. Com a dependência definida, as notificações dos dependentes podem ser retidas e apenas a notificação sobre o problema raiz enviada.

Embora o Zabbix não suporte dependências entre hosts diretamente, elas podem ser definidas com outro método, mais flexível - dependências de trigger. Um trigger pode ter um ou mais triggers dos quais depende.

Então, em nosso exemplo simples, abrimos o formulário de configuração do trigger do servidor e definimos que ele depende do respectivo trigger do roteador. Com essa dependência, o trigger do servidor não mudará seu estado enquanto o trigger do qual depende estiver no estado 'PROBLEM' - e assim nenhuma ação dependente será tomada e nenhuma notificação será enviada.

Se tanto o servidor quanto o roteador estiverem inativos e houver dependência, o Zabbix não executará ações para o trigger dependente.

Enquanto o trigger pai estiver no estado PROBLEM, seus dependentes podem relatar valores que não podem ser confiáveis. Portanto, triggers dependentes não serão reavaliados até que o trigger pai (o roteador no exemplo acima):

  • volte do estado 'PROBLEM' para 'OK';
  • mude seu estado de 'PROBLEM' para 'UNKNOWN';
  • seja fechado manualmente, por correlação ou com a ajuda das funções date and time e/ou nodata();
  • seja resolvido por um valor de um item não envolvido no trigger dependente;
  • seja desabilitado, tenha um item desabilitado ou um host de item desabilitado

Em todos os casos mencionados acima, o trigger dependente (servidor) será reavaliado apenas quando uma nova métrica para ele for recebida. Isso significa que o trigger dependente pode não ser atualizado imediatamente.

Além disso:

  • A dependência de trigger pode ser adicionada de qualquer trigger de host para qualquer outro trigger de host, desde que não resulte em uma dependência circular.
  • A dependência de trigger pode ser adicionada de um template para outro. Se algum trigger do template A depende de algum trigger do template B, o template A só pode ser vinculado a um host (ou outro template) junto com o template B, mas o template B pode ser vinculado a um host (ou outro template) sozinho.
  • A dependência de trigger pode ser adicionada de um trigger de template para um trigger de host. Nesse caso, vincular esse template a um host criará um trigger de host que depende do mesmo trigger de template do qual o trigger estava dependendo. Isso permite, por exemplo, ter um template onde alguns triggers dependem dos triggers do roteador (host). Todos os hosts vinculados a esse template dependerão desse roteador específico.
  • A dependência de trigger não pode ser adicionada de um trigger de host para um trigger de template.
  • A dependência de trigger pode ser adicionada de um protótipo de trigger para outro protótipo de trigger (dentro da mesma regra de descoberta de baixo nível) ou para um trigger real. Um protótipo de trigger não pode depender de um protótipo de trigger de uma regra LLD diferente ou de um trigger criado a partir de protótipo de trigger. Um protótipo de trigger de host não pode depender de um trigger de um template.

Configuração

Para definir uma dependência, abra a aba Dependências no formulário de configuração do trigger. Clique em Adicionar no bloco 'Dependências' e selecione um ou mais triggers dos quais o trigger irá depender.

Clique em Atualizar. Agora o trigger tem a indicação de sua dependência na lista.

Exemplo de várias dependências

Por exemplo, o Host está atrás do Router2 e o Router2 está atrás do Router1.

Zabbix - Router1 - Router2 - Host

Se o Router1 estiver fora do ar, então obviamente o Host e o Router2 também estarão inacessíveis, ainda assim receber três notificações sobre o Host, o Router1 e o Router2 estarem todos fora do ar é excessivo.

Portanto, neste caso, definimos duas dependências:

o trigger 'Host está fora do ar' depende do trigger 'Router2 está fora do ar'
       o trigger 'Router2 está fora do ar' depende do trigger 'Router1 está fora do ar'

Antes de alterar o status do trigger 'Host está fora do ar', o Zabbix verificará as dependências de trigger correspondentes. Se tais dependências forem encontradas e um desses triggers estiver no estado 'Problema', então o status do trigger não será alterado, as ações não serão executadas e nenhuma notificação será enviada.

O Zabbix realiza essa verificação recursivamente. Se o Router1 ou o Router2 estiverem inacessíveis, o trigger do Host não será atualizado.