Laboratório de Troubleshooting: Query and Analyze Logs in Azure Monitor
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Uma equipe de operações monitora um conjunto de máquinas virtuais Windows conectadas a um Log Analytics Workspace. O agente Azure Monitor Agent (AMA) foi instalado em todas as VMs há três semanas e as Data Collection Rules (DCRs) foram associadas corretamente. O workspace tem 90 dias de retenção configurados.
Durante uma investigação de incidente, um analista executa a query abaixo e não encontra eventos do tipo 4625 (falha de autenticação) para uma VM específica chamada vm-prod-03, embora o time de segurança confirme que tentativas de login com falha ocorreram nessa máquina nas últimas duas horas:
SecurityEvent
| where Computer == "vm-prod-03"
| where EventID == 4625
| where TimeGenerated > ago(2h)
O analista verifica que outros eventos da mesma VM aparecem normalmente na tabela Heartbeat. A VM está ligada e responsiva. O workspace não apresenta alertas de ingestão. A equipe de rede informa que não houve mudanças de firewall recentes.
Qual é a causa raiz da ausência dos eventos 4625 na query?
A) A retenção de 90 dias não cobre eventos de segurança do tipo 4625, que exigem configuração de retenção estendida separada.
B) A Data Collection Rule associada à VM não inclui a coleta de eventos de segurança com o nível ou EventID correspondente ao canal Security do Windows Event Log.
C) O agente AMA está com falha silenciosa na VM vm-prod-03, pois a tabela Heartbeat usa um canal de comunicação diferente e não reflete o estado da coleta de eventos.
D) A query usa Computer == "vm-prod-03" com comparação case-sensitive, e o nome real registrado na tabela SecurityEvent usa capitalização diferente.
Cenário 2 — Decisão de Ação
A causa já foi identificada: um Alert Rule baseado em log no Azure Monitor está disparando alertas duplicados a cada ciclo de avaliação porque a query subjacente não usa o operador de deduplicação adequado. A query conta todas as ocorrências de um evento recorrente, e cada execução do alerta retorna um número crescente de resultados acima do limiar, gerando notificações repetidas para o time de operações.
O contexto é o seguinte:
- O alerta está em produção e monitora erros críticos de uma aplicação financeira
- O time de operações está sendo inundado com notificações e já ignorou dois incidentes reais nas últimas 24 horas por fadiga de alertas
- Você tem permissão para editar a query e a configuração do alerta
- Uma janela de manutenção está programada para daqui a 72 horas
- Desabilitar o alerta completamente remove a cobertura de monitoramento de erros críticos
Qual é a ação correta a tomar neste momento?
A) Aguardar a janela de manutenção em 72 horas para corrigir a query com segurança, evitando qualquer mudança em produção fora do processo estabelecido.
B) Desabilitar o alerta imediatamente para cessar o ruído, e reativar apenas após a janela de manutenção com a query corrigida.
C) Editar a query do alerta agora para corrigir a lógica de deduplicação e ajustar o limiar se necessário, mantendo o alerta ativo e funcional durante a correção.
D) Redirecionar as notificações do alerta para um canal secundário de baixa prioridade até a janela de manutenção, sem alterar a query.
Cenário 3 — Causa Raiz
Um administrador está investigando a lentidão de uma aplicação web hospedada no Azure App Service. Ele acessa o Log Analytics Workspace e executa a seguinte query para calcular o tempo médio de resposta por hora nas últimas 6 horas:
AppRequests
| where TimeGenerated > ago(6h)
| summarize AvgDuration = avg(DurationMs) by bin(TimeGenerated, 1h), Name
| order by TimeGenerated desc
Os resultados mostram valores de AvgDuration entre 200ms e 400ms em todos os períodos, sem nenhuma anomalia. O administrador conclui que não há problema de desempenho.
No entanto, o time de suporte continua recebendo reclamações de usuários sobre lentidão entre 14h e 15h. O App Service Plan foi escalado verticalmente ontem de P1v3 para P2v3. A aplicação usa autenticação via Microsoft Entra ID. Os logs do servidor web interno mostram requisições com mais de 8 segundos nesse intervalo.
Qual é a causa raiz da discrepância entre o que a query retorna e o que os usuários experimentaram?
A) A query usa avg() em vez de percentile(), e a média está sendo distorcida por um grande volume de requisições rápidas que encobrem os casos lentos sofridos por um subconjunto de usuários.
B) O escalonamento vertical do App Service Plan de P1v3 para P2v3 causou uma interrupção momentânea que apagou os logs do período entre 14h e 15h da tabela AppRequests.
C) A autenticação via Microsoft Entra ID adiciona latência que não é registrada na coluna DurationMs da tabela AppRequests, sendo invisível para a query.
D) A query filtra por TimeGenerated > ago(6h), mas o atraso de ingestão do Azure Monitor faz com que o intervalo entre 14h e 15h ainda não esteja disponível no workspace.
Cenário 4 — Sequência de Diagnóstico
Um administrador recebe a seguinte queixa: "Criamos um alerta de log no Azure Monitor há dois dias, mas ele nunca disparou, mesmo com as condições sendo atendidas."
O administrador tem acesso ao portal do Azure e ao Log Analytics Workspace. Os passos de investigação disponíveis são:
- Executar manualmente a query do alerta no Log Analytics Workspace para verificar se ela retorna resultados com os dados do período de avaliação configurado.
- Verificar o histórico de execuções do alerta na aba Alert Rule para confirmar se a query está sendo executada e qual resultado está sendo retornado.
- Confirmar se o Action Group associado ao alerta está corretamente configurado e se o canal de notificação está ativo.
- Verificar se o alerta está no estado Enabled e se não está em período de supressão ou dentro de uma janela de Maintenance.
- Revisar a condição de disparo (limiar, tipo de agregação e período de avaliação) para verificar se o critério configurado está matematicamente compatível com os valores retornados pela query.
Qual é a sequência correta de investigação?
A) 1 → 2 → 5 → 4 → 3
B) 4 → 1 → 2 → 5 → 3
C) 2 → 1 → 4 → 5 → 3
D) 4 → 2 → 1 → 5 → 3
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
A pista decisiva no enunciado é que a tabela Heartbeat contém dados normais da VM, enquanto SecurityEvent não contém os eventos esperados. O agente AMA, ao contrário do agente legado MMA, não coleta logs automaticamente por padrão. Toda coleta é governada pela Data Collection Rule. A DCR precisa especificar explicitamente quais canais do Windows Event Log serão coletados e com qual filtro de nível ou EventID. Se a DCR associada à VM não incluir o canal Security com escopo abrangente o suficiente para capturar eventos de nível "Audit Failure" (que corresponde ao EventID 4625), esses eventos simplesmente não serão ingeridos.
A informação sobre ausência de mudanças de firewall e o status da VM são irrelevantes para este diagnóstico e foram incluídos propositalmente para desviar a atenção para a camada de rede.
A alternativa A é falsa: a retenção afeta o quanto tempo os dados ficam disponíveis, não quais eventos são coletados. A alternativa C representa um equívoco comum, mas a tabela Heartbeat e os eventos de segurança usam o mesmo agente e o mesmo pipeline de envio; a presença de heartbeats confirma que o agente está funcional. A alternativa D é tecnicamente plausível em alguns contextos, mas o KQL usa comparação case-insensitive por padrão para strings em campos como Computer, tornando esse distrator inválido como causa raiz aqui.
O distrator mais perigoso é o C: agir com base nele levaria a reinstalar o agente em vez de revisar a DCR, o que não resolveria o problema e causaria interrupção desnecessária na VM.
Gabarito — Cenário 2
Resposta: C
O cenário apresenta uma causa identificada (query com lógica incorreta gerando alertas duplicados) e uma restrição crítica em andamento: o time já ignorou incidentes reais por fadiga de alertas nas últimas 24 horas. Isso transforma a situação em um risco operacional ativo, não em um problema a ser gerenciado com calma até a janela de manutenção.
A alternativa A ignora o impacto real em curso. Aguardar 72 horas mantém o estado degradado e prolonga o risco de incidentes reais serem ignorados. A alternativa B remove a cobertura de monitoramento de um sistema financeiro crítico, o que é pior do que o ruído atual. A alternativa D não resolve o problema: redirecionar notificações para canal de baixa prioridade apenas confirma que os alertas serão ignorados, aumentando o risco.
A alternativa C é a única que equilibra todas as restrições: mantém o alerta ativo, corrige a causa raiz imediatamente e não exige interrupção de serviço. Editar a query de um Alert Rule no Azure Monitor não requer janela de manutenção e pode ser feito com impacto zero sobre a aplicação monitorada.
O erro de raciocínio dos distratores é tratar o processo (janela de manutenção) como mais importante do que o risco operacional já materializado.
Gabarito — Cenário 3
Resposta: A
A query usa avg(DurationMs), que calcula a média aritmética de todas as requisições no intervalo. Se no período entre 14h e 15h houve um grande volume de requisições rápidas (200ms a 300ms) e um subconjunto menor de requisições extremamente lentas (8 segundos ou mais), a média pode facilmente resultar em um valor aparentemente normal, como 350ms, que não representa a experiência dos usuários afetados.
A pista crítica é que os logs do servidor web interno mostram requisições acima de 8 segundos no mesmo intervalo. Isso confirma que os dados existem e que o problema é a métrica de agregação escolhida, não ausência de dados. O uso de percentile(DurationMs, 95) ou percentile(DurationMs, 99) revelaria a anomalia.
A informação sobre o escalonamento do App Service Plan é irrelevante e propositalmente incluída para induzir o leitor a considerar a alternativa B. Escalonamento vertical no Azure App Service não apaga logs já ingeridos no workspace.
A alternativa C descreve um comportamento incorreto: a latência de autenticação do Microsoft Entra ID ocorre antes da requisição chegar à aplicação, e o tempo registrado em DurationMs representa o tempo de processamento no servidor de aplicação. A alternativa D seria plausível se os logs do servidor interno também não mostrassem o problema, mas o enunciado confirma que os dados existem.
Gabarito — Cenário 4
Resposta: D
A sequência correta é: 4 → 2 → 1 → 5 → 3.
O raciocínio diagnóstico correto segue do mais simples e verificável para o mais complexo:
O passo 4 deve ser o primeiro porque um alerta desabilitado ou em supressão não dispara por design. Verificar esse estado elimina imediatamente a causa mais trivial antes de qualquer análise de dados.
O passo 2 vem a seguir porque o histórico de execuções revela se o Azure Monitor está executando a query e qual valor ela está retornando. Se o histórico mostra execuções com resultados acima do limiar mas sem disparo, o problema está na condição. Se não há execuções registradas, o problema está no estado do alerta.
O passo 1 valida a query de forma isolada, confirmando que ela retorna dados reais no contexto do workspace, o que é necessário antes de analisar se o limiar é adequado.
O passo 5 analisa se a condição matemática de disparo está compatível com o que a query retorna, que só faz sentido após confirmar que a query funciona corretamente.
O passo 3 é o último porque o Action Group só é relevante se o alerta deveria ter disparado mas a notificação não chegou. Verificá-lo antes de confirmar que o disparo deveria ter ocorrido é desperdício de esforço diagnóstico.
A alternativa A comete o erro de executar a query antes de verificar se o alerta está ativo, potencialmente investigando dados quando o problema é puramente de configuração de estado.
Árvore de Troubleshooting: Query and Analyze Logs in Azure Monitor
Legenda de cores:
| Cor | Tipo de nó |
|---|---|
| Azul escuro | Sintoma inicial (ponto de entrada) |
| Azul | Pergunta diagnóstica |
| Vermelho | Causa identificada |
| Verde | Ação recomendada ou resolução |
| Laranja | Verificação ou validação intermediária |
Para usar esta árvore diante de um problema real, comece pelo nó raiz identificando se o problema é ausência de dados ou falha de alerta. Siga as perguntas fechadas respondendo com o que você observa no ambiente, sem pular etapas. Cada nó laranja representa uma verificação intermediária que deve ser concluída antes de avançar para a próxima pergunta. Os nós vermelhos indicam onde parar e agir. Se o caminho percorrido levar a uma causa que não resolve o problema após a correção, retorne ao nó de origem e siga o próximo ramo ainda não explorado.