1 Correlação de eventos baseada em trigger

Visão geral

A correlação de eventos baseada em trigger permite correlacionar problemas separados relatados por uma trigger.

Embora geralmente um evento OK possa fechar todos os eventos de problema criados por uma trigger, há casos em que uma abordagem mais detalhada é necessária. Por exemplo, ao monitorar arquivos de log, você pode querer descobrir certos problemas em um arquivo de log e fechá-los individualmente, em vez de todos juntos.

Este é o caso de triggers que têm o parâmetro Modo de geração de evento PROBLEM definido como Múltiplo. Essas triggers normalmente são usadas para monitoramento de logs, processamento de traps, etc.

É possível no Zabbix relacionar eventos de problema com base em tagging. As tags são usadas para extrair valores e criar identificação para eventos de problema. Aproveitando isso, os problemas também podem ser fechados individualmente com base na correspondência da tag.

Em outras palavras, a mesma trigger pode criar eventos separados identificados pela tag do evento. Portanto, os eventos de problema podem ser identificados um a um e fechados separadamente com base na identificação pela tag do evento.

Como funciona

No monitoramento de logs, você pode encontrar linhas semelhantes a estas:

Linha1: Serviço 1 parado
       Linha2: Serviço 2 parado
       Linha3: Serviço 1 foi reiniciado
       Linha4: Serviço 2 foi reiniciado

A ideia da correlação de eventos é ser capaz de associar o evento de problema da Linha1 à resolução da Linha3 e o evento de problema da Linha2 à resolução da Linha4, e fechar esses problemas um a um:

Linha1: Serviço 1 parado
       Linha3: Serviço 1 foi reiniciado #problema da Linha 1 fechado
       
       Linha2: Serviço 2 parado
       Linha4: Serviço 2 foi reiniciado #problema da Linha 2 fechado

Para fazer isso, você precisa marcar esses eventos relacionados como, por exemplo, "Serviço 1" e "Serviço 2". Isso pode ser feito aplicando uma expressão regular à linha do log para extrair o valor da tag. Então, quando os eventos são criados, eles são marcados como "Serviço 1" e "Serviço 2" respectivamente e o problema pode ser associado à resolução.

Configuração

Item

Para começar, você pode querer configurar um item que monitore um arquivo de log, por exemplo:

log[/var/log/syslog]

Com o item configurado, aguarde um minuto para que as alterações de configuração sejam aplicadas e, em seguida, vá para Últimos dados para garantir que o item começou a coletar dados.

Trigger

Com o item funcionando, você precisa configurar o trigger. É importante decidir quais entradas no arquivo de log valem a pena prestar atenção. Por exemplo, a seguinte expressão de trigger irá procurar por uma string como 'Stopping' para sinalizar possíveis problemas:

find(/My host/log[/var/log/syslog],,"regexp","Stopping")=1 

Em seguida, defina uma expressão de recuperação. A seguinte expressão de recuperação resolverá todos os problemas se uma linha de log for encontrada contendo a string "Starting":

find(/My host/log[/var/log/syslog],,"regexp","Starting")=1 

Como não queremos isso, é importante garantir de alguma forma que os problemas raiz correspondentes sejam fechados, não apenas todos os problemas. É aí que a marcação pode ajudar.

Problemas e resoluções podem ser correspondidos especificando uma tag na configuração do trigger. As seguintes configurações devem ser feitas:

• Modo de geração de evento de problema: Múltiplos
• Evento OK fecha: Todos os problemas se os valores das tags corresponderem
• Insira o nome da tag para correspondência de eventos

• configure as tags para extrair valores de tags das linhas de log

Se configurado com sucesso, você poderá ver eventos de problema marcados por aplicação e correspondidos à sua resolução em Monitoramento → Problemas.

• Macros indexadas sempre se referem ao campo Expressão da configuração do trigger, não à Expressão de recuperação. Por exemplo, em um evento de recuperação, {ITEM.VALUE1} será resolvido para o valor mais recente do primeiro item na expressão de problema no momento da recuperação. Se a expressão de recuperação for baseada em um item diferente e o valor do item da expressão de problema mudar até o momento da recuperação, os eventos receberão tags diferentes e não serão correlacionados.
  

• Com dois aplicativos gravando mensagens de erro e recuperação no mesmo arquivo de log, um usuário pode decidir usar duas tags service no mesmo trigger com valores de tag diferentes usando expressões regulares separadas nos valores das tags para extrair os nomes, por exemplo, do serviço A e do serviço B da macro {ITEM.VALUE} (por exemplo, quando os formatos das mensagens diferem). No entanto, isso pode não funcionar como planejado se não houver correspondência com as expressões regulares. Expressões regulares sem correspondência resultarão em valores de tag vazios e um único valor de tag vazio em ambos os eventos de problema e OK é suficiente para correlacioná-los. Assim, uma mensagem de recuperação do serviço A pode acidentalmente fechar uma mensagem de erro do serviço B.

• Tags e valores de tags reais só se tornam visíveis quando um trigger dispara. Se a expressão regular usada for inválida, ela será silenciosamente substituída por uma string *UNKNOWN*. Se o evento de problema inicial com um valor de tag *UNKNOWN* for perdido, podem aparecer eventos OK subsequentes com o mesmo valor de tag *UNKNOWN* que podem fechar eventos de problema que não deveriam ter sido fechados.

• Se um usuário usar a macro {ITEM.VALUE} sem funções de macro como valor da tag, a limitação de 255 caracteres se aplica. Quando as mensagens de log são longas e os primeiros 255 caracteres não são específicos, isso também pode resultar em tags de evento semelhantes para problemas não relacionados.