Correlação de eventos baseada em trigger

Visão geral

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

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

Esse é o caso dos triggers que têm o parâmetro PROBLEM event generation mode definido como Multiple. Esses triggers são normalmente usados para monitoramento de logs, processamento de traps etc.

No Zabbix, é possível 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 tag correspondente.

Em outras palavras, o mesmo 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 é conseguir associar o evento de problema da Linha1 à resolução da Linha3 e o evento de problema da Linha2 à resolução da Linha4, e encerrar esses problemas um a um:

Linha1: Serviço 1 parado
Linha3: Serviço 1 foi reiniciado #problema da Linha 1 encerrado

Linha2: Serviço 2 parado
Linha4: Serviço 2 foi reiniciado #problema da Linha 2 encerrado

Para fazer isso, você precisa marcar esses eventos relacionados, por exemplo, como "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 recebem as tags "Serviço 1" e "Serviço 2" respectivamente, e o problema pode ser associado à resolução.

Configuração

Item

Para começar, talvez você queira 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 Latest data para verificar se o item começou a coletar dados.

Trigger

Com o item em funcionamento, você precisa configurar o trigger. É importante decidir quais entradas no arquivo de log merecem atenção. Por exemplo, a seguinte expressão de trigger procurará 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 for encontrada uma linha de log 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, e não apenas todos os problemas. É aí que a marcação pode ajudar.

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

• Problem event generation mode: Multiple
• OK event closes: All problems if tag values match
• Informe o nome da tag para correspondência de eventos

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

Se configurado corretamente, você poderá ver eventos de problema marcados por aplicação e associados à sua resolução em Monitoring > Problems.

• Macros indexadas sempre se referem ao campo Expression da configuração do trigger, e não à Recovery expression. Por exemplo, em um evento de recuperação, {ITEM.VALUE1} será resolvido para o valor mais recente do primeiro item na expressão do 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 do problema mudar até o momento da recuperação, os eventos terão tags diferentes e não serão correlacionados.

• Com duas aplicações gravando mensagens de erro e de recuperação no mesmo arquivo de log, um usuário pode decidir usar duas tags de 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 service A e do service 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 gerarão valores de tag vazios, e um único valor de tag vazio tanto em eventos de problema quanto em eventos OK é suficiente para correlacioná-los. Assim, uma mensagem de recuperação do service A pode encerrar acidentalmente uma mensagem de erro do service B.

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

• Se um usuário usar a macro {ITEM.VALUE} sem funções de macro como o 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.