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 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} resolverá 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 a partir 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 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á substituída silenciosamente por uma string *UNKNOWN*. Se o evento inicial de problema 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.