Eventos e reação

Visão geral

Há vários tipos de eventos gerados no Zabbix:

  • eventos de trigger - sempre que um trigger altera seu status (OK→PROBLEM→OK)
  • eventos de serviço - sempre que um serviço altera seu status (OK→PROBLEM→OK)
  • eventos de descoberta - quando hosts ou serviços são detectados
  • eventos de autorregistro - quando agents ativos são registrados automaticamente pelo server
  • eventos internos - quando um item/regra de descoberta de baixo nível se torna não suportado ou um trigger entra em um estado desconhecido

Os eventos têm marcação de tempo e podem servir de base para ações como envio de e-mail de notificação, criação de tickets ou execução de comandos remotos.

Para ver os detalhes do evento no frontend, vá para Monitoring > Problems. Lá, você pode clicar na data e hora do evento para abrir a página de detalhes do evento, onde é possível ver informações adicionais sobre o evento, incluindo se ele foi suprimido por causa de manutenção ou suprimido manualmente por um usuário.

Problem resolution

Problem events created by triggers are resolved automatically, if the condition that caused the problem no longer exists.

To add flexibility and convenience to problem event management, the following options exist:

Eventos de trigger

A mudança de estado do trigger é a fonte mais frequente e mais importante de eventos. Cada vez que o trigger altera seu estado, um evento é gerado. O evento contém detalhes da mudança de estado do trigger - quando ela aconteceu e qual é o novo estado.

Dois tipos de eventos são criados por triggers - Problem e OK.

Eventos de problema

Um evento de problema é criado:

  • quando uma expressão de trigger é avaliada como TRUE se o trigger estiver no estado OK;
  • a cada vez que uma expressão de trigger é avaliada como TRUE se a geração de múltiplos eventos de problema estiver habilitada para o trigger.
Eventos OK

Um evento OK fecha o(s) evento(s) de problema relacionado(s) e pode ser criado por 3 componentes:

  • triggers - com base nas configurações de "OK event generation" e "OK event closes";
  • correlação de eventos
  • gerenciador de tarefas - quando um evento é fechado manualmente

Triggers têm uma configuração de "OK event generation" que controla como os eventos OK são gerados:

  • Expression - um evento OK é gerado para um trigger em estado de problema quando sua expressão é avaliada como FALSE. Esta é a configuração mais simples, habilitada por padrão.
  • Recovery expression - um evento OK é gerado para um trigger em estado de problema quando sua expressão é avaliada como FALSE e a expressão de recuperação é avaliada como TRUE. Isso pode ser usado se o critério de recuperação do trigger for diferente do critério de problema.
  • None - um evento OK nunca é gerado. Isso pode ser usado em conjunto com a geração de múltiplos eventos de problema para simplesmente enviar uma notificação quando algo acontece.

Além disso, triggers têm uma configuração de "OK event closes" que controla quais eventos de problema são fechados:

  • All problems - um evento OK fechará todos os problemas abertos criados pelo trigger
  • All problems if tag values match - um evento OK fechará os problemas abertos criados pelo trigger e que tenham pelo menos um valor de tag correspondente. A tag é definida pela configuração de trigger "Tag for matching". Se não houver eventos de problema para fechar, então o evento OK não é gerado. Isso é frequentemente chamado de correlação de eventos no nível do trigger.
Correlação de eventos

A correlação de eventos (também chamada de correlação global de eventos) é uma forma de configurar regras personalizadas de fechamento de eventos (resultando na geração de eventos OK).

As regras definem como os novos eventos de problema são pareados com eventos de problema existentes e permitem fechar o novo evento ou os eventos correspondentes gerando os eventos OK correspondentes.

No entanto, a correlação de eventos deve ser configurada com muito cuidado, pois pode afetar negativamente o desempenho do processamento de eventos ou, se estiver configurada incorretamente, fechar mais eventos do que o pretendido (no pior caso, até mesmo todos os eventos de problema poderiam ser fechados). Algumas dicas de configuração:

  1. sempre reduza o escopo da correlação definindo uma tag exclusiva para o evento de controle (o evento que é pareado com eventos antigos) e use a condição de correlação 'new event tag'
  2. não se esqueça de adicionar uma condição com base no evento antigo ao usar a operação 'close old event', ou todos os problemas existentes poderão ser fechados
  3. evite usar nomes de tags comuns usados por diferentes configurações de correlação
Gerenciador de tarefas

Se a configuração 'Allow manual close' estiver habilitada para o trigger, então é possível fechar manualmente eventos de problema gerados pelo trigger. Isso é feito no frontend ao atualizar um problema. O evento não é fechado diretamente - em vez disso, uma tarefa 'close event' é criada, que é tratada pelo gerenciador de tarefas em seguida. O gerenciador de tarefas gerará um evento OK correspondente e o evento de problema será fechado.

Eventos de service

Os eventos de service são gerados somente se as ações de service para esses eventos estiverem habilitadas. Nesse caso, cada alteração do estado do service cria um novo evento:

  • Evento de problema - quando o estado do service é alterado de OK para Problem
  • Evento OK - quando o estado do service é alterado de Problem para OK

O evento contém detalhes da alteração do estado do service - quando ela aconteceu e qual é o novo estado.

Eventos de descoberta

O Zabbix verifica periodicamente os intervalos de IP definidos nas regras de descoberta de rede. A frequência da verificação é configurável individualmente para cada regra. Assim que um host ou um serviço é descoberto, um evento de descoberta (ou vários eventos) é gerado.

O Zabbix gera os seguintes eventos:

Evento Quando gerado
Service Up Sempre que o Zabbix detecta um serviço ativo.
Service Down Sempre que o Zabbix não consegue detectar o serviço.
Host Up Se pelo menos um dos serviços estiver UP para o IP.
Host Down Se todos os serviços não estiverem respondendo.
Service Discovered Se o serviço voltar após um período de indisponibilidade ou for descoberto pela primeira vez.
Service Lost Se o serviço for perdido após estar UP.
Host Discovered Se o host voltar após um período de indisponibilidade ou for descoberto pela primeira vez.
Host Lost Se o host for perdido após estar UP.

Eventos de autorregistro do agent ativo

O autorregistro do agent ativo cria eventos no Zabbix.

Se configurado, um evento de autorregistro do agent ativo é criado quando um agent ativo anteriormente desconhecido solicita verificações ou se os metadados do host foram alterados. O server adiciona um novo host autorregistrado, usando o endereço IP e a porta recebidos do agent.

Para mais informações, consulte a página de autorregistro do agent ativo.

Eventos internos

Eventos internos acontecem quando:

  • um item muda de estado de 'normal' para 'unsupported'
  • um item muda de estado de 'unsupported' para 'normal'
  • uma regra de descoberta de baixo nível muda de estado de 'normal' para 'unsupported'
  • uma regra de descoberta de baixo nível muda de estado de 'unsupported' para 'normal'
  • um trigger muda de estado de 'normal' para 'unknown'
  • um trigger muda de estado de 'unknown' para 'normal'

O objetivo da introdução de eventos internos é permitir que os usuários sejam notificados quando qualquer evento interno ocorrer, por exemplo, quando um item se torna unsupported e para de coletar dados.

Eventos internos só são criados quando as ações internas para esses eventos estão habilitadas. Para interromper a geração de eventos internos (por exemplo, para itens que se tornam unsupported), desabilite todas as ações para eventos internos em Alerts > Actions > Internal actions.

Se as ações internas estiverem desabilitadas, enquanto um objeto estiver no estado 'unsupported', o evento de recuperação para esse objeto ainda será criado.

Se as ações internas estiverem habilitadas, enquanto um objeto estiver no estado 'unsupported', o evento de recuperação para esse objeto será criado, mesmo que o 'problem event' não tenha sido criado para o objeto.

Veja também: Recebendo notificação sobre itens unsupported