Monitoramento de causa raiz: o que instrumentar para a causa chegar junto com o alerta

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

Publicado dez/2020Atualizado ago/2026

Às 3h12 o console abre com 180 alertas. Banco de dados fora, aplicação retornando erro 500, três balanceadores em warning, serviço de pagamento sem resposta. Todos são verdadeiros. Nenhum deles diz qual veio primeiro.

Essa distância entre volume de sinal e valor de sinal é o problema real do plantão. A equipe queima os primeiros 40 minutos decidindo por onde começar. O dado que responde a essa pergunta, porém, já está coletado em algum lugar da stack.

O monitoramento de causa raiz é o arranjo de coleta, topologia e correlação que responde “o que quebrou primeiro”. Ele faz isso sem depender da memória de quem atende. Este guia trata dessa camada de instrumentação.

Os métodos de investigação ficam de fora do escopo aqui. O guia de análise de causa raiz aplicada a TI cobre 5 Porquês, Ishikawa e árvore de falhas. A referência clássica desses métodos está na compilação da American Society for Quality.

Por que o primeiro alerta quase nunca aponta a causa

O primeiro alerta aponta o componente mais vigiado, não o que falhou primeiro. Serviços de negócio costumam ser verificados a cada 30 segundos, enquanto enlaces de rede rodam em polling de 5 minutos. Quando o enlace cai, a aplicação reclama antes. A ordem dos alertas reflete a cadência da coleta, não a cadência da falha.

Dois efeitos se somam a isso. O primeiro é a propagação: um item de configuração indisponível derruba tudo que depende dele, gerando dezenas de eventos legítimos em segundos. O segundo é o viés do plantonista, que abre a investigação pelo componente que domina melhor.

Sem topologia declarada, a operação trata 180 sintomas como 180 problemas. Com topologia, trata como um problema e 179 consequências. Essa diferença aparece direto no tempo de diagnóstico.

O custo dessa demora está medido. No levantamento anual de indisponibilidades do Uptime Institute, 57% das organizações relataram prejuízo acima de US$ 100 mil na queda mais recente. Cada minuto de triagem entra nessa conta.

Existe um teste simples para medir isso na sua operação. Pegue os cinco últimos incidentes maiores e confira quantos alertas cada um gerou. Em seguida, meça o intervalo entre o primeiro alerta e a primeira hipótese registrada. Esse intervalo é o custo direto da falta de correlação.

O que o monitoramento precisa coletar para chegar à causa

Três conjuntos de dados sustentam qualquer diagnóstico causal. A topologia diz quem depende de quem. A telemetria mostra o comportamento de cada camada. O registro de mudanças explica o que estava diferente antes. Faltando um deles, a investigação volta a ser tentativa e erro com testemunha.

Topologia e mapa de dependências

A topologia declara a relação entre serviço de negócio, aplicação, host, banco de dados e enlace. Sem ela, o correlacionador agrupa eventos apenas por proximidade temporal. Com ela, agrupa por causalidade: quando o nó pai cai, os filhos deixam de abrir incidente próprio.

Manter esse desenho vivo é o trabalho que ninguém vê. Um mapa de dependências entre serviços desatualizado produz correlação errada com a mesma confiança de uma correlação certa. Por isso a reconciliação precisa vir de discovery automático, nunca de planilha revisada uma vez por trimestre.

Um teste rápido de maturidade: pergunte ao painel quais serviços de negócio param se o cluster de banco X sair. Se a resposta depender de alguém lembrar, a topologia existe na cabeça de duas pessoas, não no sistema.

Telemetria nas quatro camadas

Cada camada responde por um tipo de causa. A régua abaixo serve para o plantão saber o que abrir primeiro e, principalmente, o que já pode ser descartado.

A disciplina de eliminar hipóteses camada a camada está descrita no capítulo de troubleshooting do SRE Book. Vale como referência de método para quem está montando o roteiro de plantão.

Na operação do Instituto Butantan, o SESuite parava de 3 a 5 minutos por operação e o reflexo padrão era reiniciar o serviço ou pedir mais hardware. Instrumentamos consumo por processo, captura da query exata no SQL Server e traces de requisição.

Isso trocou a pergunta “qual servidor está lento” pela pergunta “qual chamada está lenta”. A causa apareceu na query e no consumo de memória do Java, sem comprar infraestrutura. O projeto de observabilidade no Instituto Butantan detalha a stack usada.

A trilha de mudanças

Boa parte dos incidentes tem resposta curta: alguma coisa mudou. Deploy, alteração de regra em firewall, atualização de firmware, expiração de certificado, ajuste de limite em pool de conexão. Quando o painel de incidente não mostra a janela de mudança, o time reconstrói essa informação no grupo de mensagens, gastando minutos caros.

Correlacionar evento com registro de gestão de mudanças é o ganho mais barato desse arranjo. Basta que a ferramenta de monitoramento consulte a janela das últimas 24 horas para o item afetado e exiba isso junto do alerta.

Onde essa integração ainda não existe, uma alternativa barata resolve boa parte do problema. Exporte o log de deploy e o log de alteração de rede para a mesma linha do tempo do painel de incidente. Nenhum projeto de CMDB completo precisa terminar antes disso começar a valer.

Correlação de eventos: de centenas de alertas para um incidente

A correlação transforma volume em hipótese. Ela agrupa eventos por três critérios combinados: proximidade no tempo, relação na topologia e repetição de padrão histórico. O resultado é um incidente com um pai declarado, os filhos suprimidos e a evidência anexada.

Três regras entregam a maior parte do valor, antes de qualquer modelo estatístico:

Supressão por dependência, para o filho não abrir chamado quando o pai já está fora. Agrupamento por janela, para 40 eventos do mesmo item em 2 minutos virarem um. Deduplicação por assinatura, para o mesmo defeito reincidente não gerar fila nova.

Quem quiser ver isso aplicado em um incidente real encontra em correlação de eventos aplicada à operação o desenho das regras. Ednilson Corrêa, engenheiro sênior da OpServices, também reconstrói um incidente de PDV e pagamento até a origem em um estudo de caso gravado.

Vale separar o que a correlação decide do que ela apenas sugere. Suprimir alerta de filho é decisão segura, porque o pai já está aberto. Fechar o filho automaticamente quando o pai é resolvido esconde falha independente que começou na mesma janela.

Um contra-exemplo comum ilustra o risco. O enlace principal cai, a aplicação entra em erro, o time restaura o enlace. Se a regra fechar tudo junto, ninguém percebe que o pool de conexão da aplicação continua saturado. O incidente volta em 20 minutos com outra assinatura.

Por isso a supressão precisa ter prazo. Passada a janela definida, o evento filho que continuar ativo volta a competir por atenção, sem depender de alguém lembrar de conferir.

Onde o monitoramento de causa raiz falha

Quatro armadilhas aparecem com regularidade em ambientes que já investiram na camada de coleta.

A primeira é confiar em topologia estática. O ambiente muda toda semana enquanto o desenho fica parado. Dessa forma, a correlação passa a apontar um pai que já foi desativado. Sintoma típico: incidente fechado com “causa não identificada” enquanto o painel mostrava tudo verde.

A segunda é instrumentar o que é fácil. Coletar o hipervisor inteiro custa pouco, coletar a aplicação legada custa negociação com o fornecedor. Como resultado, a camada onde a falha nasce fica cega. O diagnóstico para no host.

A terceira é tratar causa raiz como evento único. Falha recorrente com a mesma assinatura é problema, não incidente, então a saída passa por gestão de problemas, com registro de causa conhecida. Sem esse ciclo, a operação reabre o mesmo diagnóstico todo mês.

A quarta é avaliar a correlação pelo total de agrupamentos. O número agregado sobe rápido, embora o erro que importa fique concentrado nos poucos serviços que sustentam receita. Amostre a qualidade do agrupamento por serviço crítico, nunca pelo total do mês.

Como medir se o arranjo funciona

Quatro indicadores dizem se a instrumentação está entregando causa ou apenas sintoma. Meça-os por trimestre, sempre com a mesma janela de apuração.

O MTTD mostra o atraso entre a falha começar e o monitoramento perceber. Ele é o número que mais engana, porque não aparece no relatório de SLA. A proporção de incidentes fechados com causa identificada revela quantos casos terminaram em “reiniciamos e voltou”. A taxa de reincidência em 30 dias denuncia causa tratada pela metade.

Por fim, o tempo médio de recuperação fecha a leitura. Quando MTTD cai e MTTR não acompanha, o gargalo saiu da detecção e foi para o diagnóstico, o que costuma indicar topologia incompleta.

Registrar causa exige campo obrigatório no fechamento do chamado, com lista fechada de categorias. Uma lista que funciona bem: mudança, capacidade, defeito de software, falha de hardware, dependência externa e causa não identificada. Categoria em texto livre vira base inútil já no terceiro mês.

A opção “causa não identificada” merece leitura separada. Ela não é vergonha operacional, é o indicador mais honesto de cobertura da instrumentação. Quando passa de um quinto dos incidentes do trimestre, o problema está na coleta, nunca na equipe de plantão.

Operações que rodam monitoramento em tempo real com plantão dedicado comparam esses quatro números entre turnos. A leitura por turno expõe diferença de processo antes de diferença de ferramenta.

O que muda quando a causa chega junto com o alerta

A diferença entre uma operação que apaga incêndio e outra que resolve incidente raramente está na ferramenta. Está em três dados alinhados no tempo: topologia declarada, telemetria nas quatro camadas, registro de mudanças ao alcance do plantão.

Com esse tripé, a correlação deixa de ser recurso de marketing e vira redução real de triagem. O caminho de adoção é incremental. Comece pela topologia dos cinco serviços de negócio que mais doem, ligue a supressão por dependência, traga a janela de mudança para dentro do alerta.

Só depois avalie modelos de detecção de anomalia, porque eles amplificam a qualidade dos dados existentes, sem substituí-los.

O ganho aparece rápido no indicador certo. Menos eventos abertos por incidente, mais casos fechados com causa identificada, menos reincidência no mês seguinte. Se quiser revisar como sua operação coleta, correlaciona e prova causa, converse com um especialista da OpServices para uma avaliação do arranjo atual.