Correlação de eventos: como o motor decide que 200 alertas são um incidente só

Autor: Pedro Tebaldi PM do KeepGreen| Revisão técnica: Ednilson Correa SRE

Publicado mai/2020Atualizado ago/2026

Três da manhã, o painel do NOC acende. Em oito minutos entram 217 alertas. A lista mistura latência de aplicação, timeout de banco e fila de mensageria subindo. Somam-se dois balanceadores fora do ar e quatorze hosts sem resposta ao ping. Antes de investigar qualquer coisa, portanto, o plantonista precisa responder uma pergunta: isso aqui é um problema ou são quatorze?

A correlação de eventos existe para responder isso antes do humano. Ela decide quais dos 217 eventos falam do mesmo objeto, dentro da mesma janela de tempo, com dependência entre si. Em seguida, entrega ao plantão um incidente com contexto no lugar de uma fila com 217 linhas.

Este guia trata da camada que quase nenhum material aborda. Ou seja: o que o motor precisa receber para tomar essa decisão, como escolher a janela e quais modelos realmente existem. Por fim, como medir se o arranjo funciona. Filtrar, agrupar e suprimir vêm depois. A decisão vem primeiro.

O que é correlação de eventos

A correlação de eventos é o processo que analisa eventos de fontes diferentes para decidir quais deles pertencem ao mesmo incidente. Em seguida, ela aponta qual foi o evento causador e quais são efeitos derivados.

Em resumo, o resultado não é um relatório: é um item a menos na fila do plantão, com contexto suficiente para começar o diagnóstico.

Nesse sentido, vale separar do que ela não é. Deduplicação junta ocorrências idênticas do mesmo evento. Adicionalmente, agrupamento reúne eventos parecidos em um único aviso. Supressão, por fim, silencia o que já se sabe derivado de uma causa conhecida. Os três aparecem em detalhe nas técnicas de redução de ruído.

Assim, a correlação fica uma camada abaixo dessas três. Ela produz a informação que todas consomem: a afirmação de que o evento A e o evento B pertencem ao mesmo incidente. Sem essa afirmação, agrupar vira apostar que eventos próximos no relógio têm relação entre si. Em ambiente grande, no entanto, essa aposta erra com frequência incômoda.

As três perguntas que todo motor de correlação responde

Motor de regra, motor temporal ou modelo de aprendizado: todos percorrem a mesma sequência de três perguntas. Ou seja, trocar de ferramenta muda a implementação da resposta, nunca a pergunta.

Identidade: os eventos falam do mesmo objeto?

Antes de qualquer janela ou algoritmo, o motor precisa afirmar uma coisa. O evento vindo do coletor de rede e o evento vindo do agente de aplicação apontam para o mesmo objeto. Isto é: mesmo host, mesmo serviço, mesma transação.

Portanto, essa afirmação depende de um campo em comum entre as duas fontes. Sem campo em comum não existe correlação: existe coincidência.

Tempo: os eventos cabem na mesma janela?

Causa precede efeito, portanto a proximidade temporal é evidência legítima. Ela é fraca sozinha, no entanto. Em ambiente com milhares de itens coletados, muita coisa acontece no mesmo segundo sem nenhuma relação causal. Dessa forma, a janela só vira critério utilizável quando alguém dimensiona o tamanho dela pelo intervalo de coleta.

Dependência: um objeto sustenta o outro?

Essa é a pergunta que separa correlação de agrupamento. Por exemplo: se o switch de borda caiu, os quatorze hosts atrás dele não são quatorze incidentes, são efeito de um. Responder isso, contudo, exige um mapa de dependência declarado, seja pela topologia física, seja pelo grafo de chamadas entre serviços.

A ordem entre as três importa. Errar a identidade contamina as outras duas. Como resultado, o motor mede tempo entre objetos que considera distintos e procura dependência onde nem consegue nomear as pontas. Por isso o trabalho começa pela chave, não pela regra.

A chave de correlação: o pré-requisito que quase ninguém configura

Projeto de correlação raramente falha por falta de algoritmo. Ele falha porque o mesmo servidor chega ao motor como srv-app-01 pelo agente, como SRV-APP-01.corp.local pelo inventário e como 10.20.4.11 pela trap SNMP.

Logo, são três objetos distintos do ponto de vista do motor. Três objetos não se correlacionam.

A chave de correlação é o campo, ou o conjunto de campos, que dá identidade estável a um evento entre fontes diferentes. Ela precisa existir já na ingestão, antes de qualquer regra. Além disso, cada sinal carrega a sua.

Padronizar esses campos na mão é trabalho perpétuo. Por isso, o caminho mais curto passa por adotar um esquema de nomes já publicado.

As convenções semânticas do OpenTelemetry definem nomes comuns para atributos de recurso e de operação. Com elas, times diferentes emitem telemetria com o mesmo vocabulário.

Inclusive, o trace_id é a expressão mais forte dessa ideia. No rastreamento distribuído, um identificador único acompanha a requisição por todos os serviços que ela atravessa.

Qualquer log emitido dentro daquele contexto carrega o mesmo identificador. Dessa forma, ligar log de um serviço ao trace de outro deixa de ser inferência e vira consulta.

Adotar instrumentação padronizada desde o começo resolve o problema na origem. A alternativa, em contrapartida, é reconstruir identidade dentro do motor. Isso significa expressão regular sobre texto livre, revisada toda vez que um fornecedor muda o formato do log.

A armadilha, aqui, é tratar isso como responsabilidade da ferramenta de correlação. Nenhum motor resolve identidade sozinho: ele apenas compara os campos que recebe. Em resumo, quando a normalização não acontece na ingestão, ela não acontece em lugar nenhum.

Janela de tempo: quanto esperar antes de abrir o incidente

Escolher a janela é escolher quanto atraso de acionamento você aceita pagar por quanta redução de fila. Janela curta abre incidente rápido e fragmenta a mesma falha em vários itens.

Janela longa, por outro lado, consolida bem e atrasa o primeiro toque humano. Não existe valor universal, existe o par que a sua operação suporta.

Três formatos cobrem quase todos os casos. A janela fixa divide o tempo em blocos iguais e correlaciona o que cai no mesmo bloco. Ela é simples de implementar, porém corta eventos na fronteira.

A janela deslizante, por outro lado, se reposiciona a cada evento novo, o que elimina esse corte artificial. Já a janela de sessão fecha sozinha após um período sem evento novo. Dessa forma, ela acomoda bem tempestade de duração imprevisível.

Ainda assim, existe um piso defensável para o tamanho. A janela precisa ser maior que o intervalo de coleta que produz os eventos derivados. Com polling de 60 segundos, por exemplo, uma janela de 30 segundos separa causa de efeito por construção. Comece pelo intervalo mais lento da cadeia, depois calibre com incidente real.

O relógio: por que a correlação temporal falha em silêncio

Um segundo detalhe derruba mais projeto que o dimensionamento: o relógio. Correlação temporal compara carimbos de tempo gerados em máquinas diferentes. Quando elas divergem, o efeito aparece antes da causa na linha do tempo. Como resultado, a regra causal simplesmente não dispara.

Sincronização por NTP em toda a frota é pré-requisito, não higiene opcional. Ademais, verifique o desvio nos coletores que mais geram evento derivado.

Vale distinguir também o horário do evento do horário de ingestão. Um coletor que ficou sem conectividade entrega meia hora de eventos de uma vez, todos com ingestão praticamente idêntica. Nesse caso, correlacionar por ingestão funde meia hora de operação em um incidente só. Prefira o horário do evento sempre que a fonte fornecer um confiável.

Por fim, a janela também define o que chega ao plantão e quando. Quanto mais tarde o incidente abre, mais tarde a regra de escalação começa a contar; o SLA de primeira resposta sente isso na apuração. Trate os dois números como um par, nunca como configurações independentes.

Os cinco modelos de correlação e quando usar cada um

Fornecedores vendem os modelos como gerações sucessivas, em que o mais novo substitui o anterior. Entretanto, na operação real eles convivem: cada um exige um insumo diferente. Você usa o que os seus dados já sustentam.

O critério de escolha, portanto, não é a sofisticação do modelo: é qual insumo você já tem em casa. Quem mantém um mapa de topologia da rede confiável começa pela correlação topológica, que entrega o maior ganho por hora investida. Do mesmo modo, quem já normalizou telemetria começa pela semântica.

Plataformas de AIOps entram bem depois, sobre um histórico que já existe. Modelo de aprendizado sem base rotulada aprende o ruído atual e o devolve organizado. Antes de tudo, verifique se os seus incidentes passados registram desfecho, causa e itens afetados.

Boa parte do trabalho de campo, aliás, não está em escolher o modelo: está em encadeá-lo com os filtros aplicados antes da fila. Correlação recebe um fluxo mais limpo quando dedup e throttle já rodaram na entrada.

Como medir se a correlação está funcionando

Sem número, correlação vira crença. Por isso, três indicadores bastam para começar, desde que o terceiro exista de verdade.

A taxa de compressão é a razão entre eventos recebidos e incidentes abertos no mesmo período. Um motor que ingere 4.000 eventos por dia e abre 120 incidentes trabalha em 33 para 1. Acompanhe a série, no entanto, nunca o valor isolado: queda súbita costuma indicar coletor parado, não melhora de ambiente.

O tempo até o reconhecimento mostra o custo da janela. Se a compressão sobe enquanto o MTTA sobe junto, você comprou consolidação com atraso de acionamento. Essa troca pode valer a pena. Ainda assim, precisa ser decisão consciente, com o número na frente de quem responde pelo SLA.

A contramétrica que quase ninguém acompanha

O terceiro indicador é o que raramente aparece em material de fornecedor: a fusão indevida. Ele conta quantas vezes dois incidentes reais entraram como um só, deixando o segundo invisível até alguém reclamar.

Meça pela reabertura em janela curta e pelo post-mortem que revela uma segunda causa dentro do mesmo ticket. Em síntese, é o modo de falha que a correlação cria e que a operação sem correlação não tinha. Compressão alta sem esse contrapeso pode significar cegueira, não maturidade.

Do lado do custo humano, aliás, o problema que a correlação ataca já está medido em pesquisa de mercado.

A Observability Survey 2026 da Grafana Labs reuniu 1.363 respostas, coletadas entre outubro de 2025 e janeiro de 2026. Nela, a fadiga de alertas aparece como o maior obstáculo isolado para acelerar a resposta a incidentes, apontada por 30% dos respondentes.

O efeito colateral aparece em outra medição. O SRE Report 2026, da Catchpoint, ouviu 418 praticantes. A mediana de tempo consumida por tarefas repetitivas de baixo valor ficou em 34%. Triagem manual de alerta duplicado é exatamente esse tipo de tarefa.

Reduzir esse desperdício é o retorno concreto do investimento, muito antes de qualquer ganho de imagem. Em suma, quando a fadiga de alertas cede, o plantão volta a ler o que recebe.

Correlação em segurança: por que o SIEM inverte o objetivo

A mesma técnica muda de propósito quando atravessa a fronteira da segurança. No SIEM, a correlação cruza logs de firewall, autenticação, endpoint e aplicação em busca de um padrão que nenhuma fonte isolada mostrava.

O exemplo clássico é a força bruta seguida de login bem-sucedido. Dezenas de falhas de autenticação, sozinhas, parecem ruído de usuário distraído. Por outro lado, correlacionadas com um acesso bem-sucedido a partir do mesmo endereço, elas configuram um padrão que exige resposta imediata.

A diferença de objetivo muda o que se faz com o resultado. No NOC, a correlação existe para reduzir o número de itens que chegam ao operador, agrupando sintomas do mesmo incidente. No SOC, em contrapartida, ela existe para revelar um sinal que estava distribuído entre fontes. Mesma mecânica, intenções opostas.

Essa inversão tem consequência prática na calibragem. No NOC, agrupar demais atrasa o acionamento. No SOC, do mesmo modo, agrupar demais apaga a evidência: o analista precisa da sequência preservada, evento a evento, para reconstruir o que aconteceu.

Por onde começar

A ordem de implementação é quase sempre a mesma. Contudo, quase nunca é a que o projeto tenta seguir. Antes de tudo, normalize identidade na ingestão para os dez serviços que mais geram evento. Sem isso, qualquer motor entrega agrupamento por acaso.

Em seguida, declare a dependência dos serviços críticos. Não precisa ser o ambiente inteiro no primeiro ciclo: comece pelos processos de negócio que param a operação quando falham.

Depois disso, defina a janela por classe de evento, já que rede e aplicação não têm o mesmo tempo de propagação. Por fim, ligue a medição e trate compressão, MTTA e fusão indevida como um trio.

Em uma das maiores redes de varejo do Brasil, aliás, o insumo que faltava não era motor: era o mapa. Antes de escrever qualquer regra, mapeamos os processos críticos de negócio com suas interdependências. A cadeia ia de PDV e self checkout até PIX, gateway de pagamento e rede das lojas.

Com 42 lojas no painel consolidado e a dependência declarada, o time passou a enxergar impacto durante o incidente em vez de reconstruí-lo depois. Como resultado, as salas de guerra deixaram de ser rotina. O desenho completo do projeto está no case, junto do catálogo de serviços que sustentou o arranjo.

Nesse sentido, Ednilson Corrêa, engenheiro sênior da OpServices, reconstrói um incidente de varejo do primeiro alerta até a causa. O vídeo mostra onde o mapa de dependência entra na investigação.

Cabe ressaltar um último ponto de rota. Correlação não substitui a análise de causa raiz: ela entrega o contexto estruturado que torna a análise viável em minutos. O motor diz que esses 217 eventos são um incidente e aponta o candidato a causador. Explicar por que aquilo aconteceu, ainda assim, continua sendo trabalho de gente.

O que muda quando o alerta chega correlacionado

A correlação de eventos não é um recurso de painel: é a decisão que define o que o seu time vê às três da manhã. Ou um item com causa provável e escopo delimitado, ou uma fila de 217 linhas para triar na mão.

O caminho até lá é menos glamouroso do que a categoria sugere. Ele passa por identidade estável na ingestão, dependência declarada nos serviços que param o negócio e janela dimensionada pelo intervalo de coleta. Além disso, exige três indicadores acompanhados com honestidade, incluindo o que denuncia agrupamento errado. Modelo e ferramenta vêm depois dessa base, nunca antes.

Em suma, comece pequeno e meça. Dez serviços normalizados com o mapa de dependência correto valem mais que um motor sofisticado alimentado por eventos que ninguém identifica. Para desenhar essa base no seu ambiente e definir o arranjo que a sua operação sustenta, fale com nossos especialistas.