[comment]: # translation:outdated

[comment]: # ({69aa4121-69aa4121})
# 1 Correlação de evento baseada em trigger

[comment]: # ({/69aa4121-69aa4121})

[comment]: # ({8032759c-f01b1f93})
#### Visão geral

A correlação de evento baseada em gatilho permite correlacionar problemas
separados reportados por um gatilho.

Enquanto de forma geral um evento OK pode encerrar todos os eventos problema
criados por um gatilho, há casos onde uma abordagem mais detalhada é necessária.
Por exemplo, quando monitorando arquivos de log você pode querer descobrir
certos problemas em um arquivo de log e encerrá-los individualmente em vez de
todos ao mesmo tempo.

Este é o caso com gatilhos que possuem habilitada a *Geração de Eventos Problema
Múltiplos*. Tais gatilhos são normalmente usados para monitoramento de log,
processamento de trap, etc.

No Zabbix é possível relacionar eventos problema baseado em [etiquetagem](/manual/config/tagging).
Etiquetas são usadas para extrair valores e criar identificação para eventos
problema. Tirando vantagem disto, problemas podem também ser encerrados
individualmente com base na correspondência de etiqueta.

Em outras palavras, o mesmo gatilho pode criar eventos separados identificados
pela etiqueta do evento. Assim eventos problema podem ser identificados um a um
e encerrados separadamente com base na identificação pela etiqueta do evento.

[comment]: # ({/8032759c-f01b1f93})

[comment]: # ({1d5513d0-12f3de38})
#### Como isso funciona

No monitoramento de log você pode encontrar linhas similares
a estas:

    Linha1: Aplicação 1 parada
    Linha2: Aplicação 2 parada
    Linha3: Aplicação 1 foi reiniciada
    Linha4: Aplicação 2 foi reiniciada

A ideia da correlação de evento é estar apto a corresponder o evento
problema da Linha1 à resolução da Linha3 e o evento problema da Linha2
à resolução da Linha4, e encerrar estes problemas um a um:

    Linha1: Aplicação 1 parada
    Linha3: Aplicação 1 foi reiniciada #problema da Linha 1 encerrado

    Linha2: Aplicação 2 parada
    Linha4: Aplicação 2 foi reiniciada #problema da Linha 2 encerrado

Para fazer isto você precisa etiquetar estes eventos relacionados como, 
por exemplo, "Aplicação 1" e "Aplicação 2". Isto pode ser feito pela
aplicação de uma expressão regular à linha de log para extrair o valor
da etiqueta. Então, quando eventos são criados, eles são etiquetados como
"Aplicação 1" e "Aplicação 2" respectivamente e o problema pode ser
correspondido à resolução.

[comment]: # ({/1d5513d0-12f3de38})

[comment]: # ({29850850-5d32b87c})
#### Configuração

[comment]: # ({/29850850-5d32b87c})

[comment]: # ({a3806229-8d1971f2})
##### Item

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

    log[/var/log/syslog]

![](../../../../assets/en/manual/config/event_correlation/correlation_item.png)

Com o item configurado, aguarde um minuto para que as mudanças de configuração
sejam capturadas e então vá até [últimos dados](/manual/web_interface/frontend_sections/monitoring/latest_data) para
certificar-se de que o item iniciou a coleta de dados.

[comment]: # ({/a3806229-8d1971f2})

[comment]: # ({91112f2e-57e60c4e})
##### Gatilho

Com o item funcionando você precisa configurar o [gatilho](/manual/config/triggers/trigger).
É importante decidir quais entradas no arquivo de log são dignas de atenção.
Por exemplo, a seguinte expressão de gatilho buscará por uma string como
'Parando (Stopping)' para sinalizar possíveis problemas:

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

::: noteimportant
Para certificar-se que cada linha contendo uma string "Parando" é 
considerada um problema também defina o *Modo geração de evento problema*
na configuração do gatilho para 'Múltiplo'.
:::

Então defina uma expressão de recuperação. A seguinte expressão de recuperação
solucionará todos os problemas se uma linha de log é encontrada contento a string
"Iniciando (Starting)":

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

Como nós não queremos este comportamento, é importante certificar-se de alguma
forma de que os problemas raíz sejam encerrados, e não todos os problemas. É
aqui onde a etiquetagem pode ajudar.

Problemas e soluções podem ser correspondidos especificando uma etiqueta na
configuração do gatilho. As seguintes configurações devem ser feitas:

-   *Modo geração de evento problema*: Múltiplo
-   *Evento OK encerra*: Todos os problemas se valores de etiqueta corresponderem
-   Informe o nome da etiqueta para correspondência de evento

![](../../../../assets/en/manual/config/event_correlation/correlation_trigger.png)

-   configure as [etiquetas](/manual/config/tagging) para extrair os valores de etiqueta
    das linhas do log

![](../../../../assets/en/manual/config/event_correlation/correlation_trigger2.png)

Se configurado com sucesso você conseguirá ver os eventos problema etiquetados
por aplicação e correspondidos à sua solução em *Monitoramento* → *Problemas*.

![](../../../../assets/en/manual/config/matched_problems.png){width="600"}

::: notewarning
Devido possibilidade de má configuração, quando etiquetas de evento similares
podem ser criadas para problemas **não relacionados**, por favor revise os
casos destacados abaixo!
:::

-   Com duas aplicações gravando mensagens de erro e recuperação no
    mesmo arquivo de log um usuário deve decidir usar duas etiquetas
    *Aplicação* no mesmo gatilho com valores de etiqueta diferentes
    pelo uso de expressões regulares separadas nos valores de etiqueta
    para extrair os nomes de, digamos, aplicação A e aplicação B da
    macro {ITEM.VALUE} (p.e. quando os formatos de mensagem diferem).
    No entanto, isto pode não funcionar como planejado se não houver
    correspondência com as expressões regulares. Expressões regulares
    não correspondidas renderão valores de etiqueta vazios e um único
    valor de etiqueta vazio em ambos os eventos PROBLEMA e OK é 
    suficiente para correlacioná-los. Então uma mensagem de recuperação
    da aplicação A podem acidentalmente encerrar uma mensagem de erro
    da aplicação B.

```{=html}
<!-- -->
```
-   Etiquetas vigentes e valores de etiqueta só se tornam visíveis quando
    um gatilho é disparado. Se a expressão regular utilizada for inválida,
    ela é silenciosamente substituída por uma string \*DESCONHECIDO\*. Se
    o evento problema inicial com um valor de etiqueta \*DESCONHECIDO\* é
    ignorado, podem existir eventos OK subsequentes com o mesmo valor de
    etiqueta \*DESCONHECIDO\* que podem encerrar eventos problema que não
    deveriam ter sido encerrados.

```{=html}
<!-- -->
```
-   Se um usuário usa a macro {ITEM.VALUE} sem funções de macro como valor
    de etiqueta, a limitação de 255 caracteres se aplica. Quando mensagens
    de log são longas e os primeiros 255 caracteres não são específicos,
    isto pode também resultar em etiquetas de evento similares para problemas
    não relacionados.

[comment]: # ({/91112f2e-57e60c4e})