Laboratório de Troubleshooting: Configure and interpret monitoring of virtual machines, storage accounts, and networks by using Azure Monitor Insights
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
A equipe de operações abriu um chamado relatando que o painel do VM Insights de uma VM Windows Server 2022 não exibe dados na aba Performance há aproximadamente duas horas. A VM está respondendo normalmente a pings e conexões RDP. O administrador acessa o portal e verifica o seguinte:
VM: prod-win-app01
Região: East US
OS: Windows Server 2022 Datacenter
VM Insights: habilitado há 3 semanas
Log Analytics Workspace: la-prod-eastus (East US)
Extensões instaladas na VM:
- AzureMonitorWindowsAgent | Status: Provisioning succeeded
- DependencyAgentWindows | Status: Provisioning succeeded
Últimos logs no workspace (KQL):
Heartbeat
| where Computer == "prod-win-app01"
| order by TimeGenerated desc
| take 5
Resultado: 0 registros nos últimos 3 horas
O administrador também observa que a VM possui um Data Collection Rule (DCR) associado criado há três semanas. O grupo de recursos da VM foi movido para outra assinatura ontem à tarde como parte de uma reorganização administrativa. A Storage Account usada para diagnóstico de boot da VM está em uma região diferente, mas esse recurso nunca foi usado pelo VM Insights.
Qual é a causa raiz da ausência de dados no VM Insights?
A) O Dependency Agent entrou em estado de falha silenciosa após a movimentação do grupo de recursos, interrompendo apenas a coleta de métricas de desempenho.
B) A movimentação do grupo de recursos para outra assinatura desvinculou a associação entre a VM e o Data Collection Rule, interrompendo o envio de dados ao workspace.
C) O Log Analytics Workspace está em uma região diferente da nova assinatura, e restrições de conformidade regional bloquearam a ingestão de dados automaticamente.
D) A extensão AzureMonitorWindowsAgent precisa ser reinstalada manualmente sempre que uma VM é movida entre grupos de recursos.
Cenário 2 — Decisão de Ação
O time de segurança identificou que logs de acesso a blobs de uma Storage Account crítica não estão chegando ao Log Analytics Workspace vinculado. A causa foi confirmada pelo administrador: os Diagnostic Settings da Storage Account foram configurados apenas para métricas agregadas, sem inclusão de nenhuma categoria de log de recurso.
O ambiente possui as seguintes restrições:
- A Storage Account está em uso ativo por uma aplicação de pagamentos em produção, com SLA de 99,9%
- A configuração de Diagnostic Settings é uma operação de plano de controle e não afeta o plano de dados da Storage Account
- O time de auditoria exige que os logs comecem a ser coletados dentro de no máximo 4 horas
- O administrador possui a role Monitoring Contributor no escopo da Storage Account
Qual é a ação correta a tomar neste momento?
A) Criar um novo Diagnostic Setting na Storage Account adicionando as categorias StorageRead, StorageWrite e StorageDelete direcionadas ao workspace, sem interromper a aplicação.
B) Recriar a Storage Account em um novo grupo de recursos com as configurações corretas de diagnóstico desde o início, migrando os dados existentes para não perder o histórico.
C) Solicitar ao time de segurança uma janela de manutenção para o fim de semana, pois alterações em Diagnostic Settings de recursos em produção exigem aprovação e podem causar instabilidade.
D) Habilitar o Microsoft Defender for Storage como alternativa temporária, pois ele gera logs de acesso automaticamente sem necessidade de alterar os Diagnostic Settings existentes.
Cenário 3 — Causa Raiz
Uma analista está investigando por que o Network Insights não exibe dados de fluxo de tráfego para um Network Security Group específico, mesmo que a topologia de rede apareça corretamente no painel. Ela compartilha o seguinte levantamento:
NSG: nsg-prod-backend
Região: Brazil South
Network Watcher: habilitado em Brazil South
NSG Flow Logs:
Status: Enabled
Storage Account: stflowlogsprod (Brazil South)
Retention: 7 days
Flow Log Version: Version 2
Traffic Analytics:
Status: Disabled
Workspace vinculado ao Network Insights: la-prod-brazilsouth
Workspace criado há: 6 meses
Última consulta KQL no workspace: retornou dados de outras fontes normalmente
A analista também menciona que o Network Watcher foi recriado na região há duas semanas após uma exclusão acidental, e que a Storage Account de Flow Logs foi criada no mesmo dia. O workspace está íntegro e recebendo dados de outras fontes sem problemas.
Qual é a causa raiz da ausência de dados de fluxo no Network Insights?
A) O Network Watcher foi recriado há pouco tempo e ainda está em período de inicialização, o que impede a exibição de dados de fluxo no Network Insights por até 30 dias.
B) O NSG Flow Log está configurado com Version 2, que não é compatível com o Network Insights na região Brazil South.
C) O Traffic Analytics está desabilitado, e sem ele os dados do NSG Flow Log não são processados nem enviados ao workspace para exibição no Network Insights.
D) A Storage Account de Flow Logs foi criada recentemente e ainda não acumulou dados suficientes para que o Network Insights gere visualizações agregadas.
Cenário 4 — Sequência de Diagnóstico
Um administrador recebe o seguinte relato: a aba Map do VM Insights de uma VM Linux está vazia, mas a aba Performance exibe dados normalmente. O administrador precisa diagnosticar o problema seguindo uma sequência lógica e eficiente.
Os passos de investigação disponíveis são:
- Verificar no portal se o Dependency Agent está instalado e com status de provisionamento bem-sucedido na VM
- Confirmar que o VM Insights está habilitado e que a VM está associada a um Log Analytics Workspace
- Consultar o workspace com KQL para verificar se a tabela VMConnection contém registros recentes da VM
- Verificar se o sistema operacional Linux da VM é uma distribuição suportada pelo Dependency Agent
- Acessar a VM via SSH e verificar o status do processo do Dependency Agent diretamente no sistema operacional
Qual sequência representa o raciocínio diagnóstico mais eficiente e progressivo?
A) 2, 1, 4, 3, 5
B) 1, 2, 5, 3, 4
C) 3, 1, 4, 5, 2
D) 5, 4, 2, 1, 3
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
A pista definitiva no enunciado é a ausência de registros de Heartbeat nas últimas três horas, combinada com o evento ocorrido na tarde anterior: a movimentação do grupo de recursos para outra assinatura. Quando uma VM é movida entre assinaturas, as associações de Data Collection Rules são desvinculadas automaticamente porque o DCR é um recurso escoped à assinatura de origem. Sem o DCR associado, o Azure Monitor Agent não sabe para onde enviar os dados, mesmo que a extensão esteja com status "Provisioning succeeded" no portal.
A informação irrelevante do cenário é a Storage Account de diagnóstico de boot em região diferente. Esse recurso não tem relação alguma com o VM Insights ou com o Azure Monitor Agent, e foi incluído propositalmente para desviar o diagnóstico.
O distrator mais perigoso é o D, que induziria o administrador a reinstalar a extensão sem antes investigar o DCR, gastando tempo sem resolver o problema real. O distrator C é plausível superficialmente, mas restrições de conformidade regional não são aplicadas automaticamente pela plataforma com base em movimentação de recursos.
A consequência de agir com base no distrator D seria reinstalar a extensão, verificar que ela provisiona corretamente, e continuar sem dados, pois o problema real (vínculo do DCR) permaneceria intacto.
Gabarito — Cenário 2
Resposta: A
O enunciado declara explicitamente a causa: ausência de categorias de log de recurso nos Diagnostic Settings. A ação correta é adicionar as categorias necessárias diretamente no Diagnostic Setting existente ou criar um novo, operação que é não disruptiva para o plano de dados da Storage Account. O próprio enunciado confirma isso ao informar que "a configuração de Diagnostic Settings é uma operação de plano de controle e não afeta o plano de dados".
O distrator B seria correto em um cenário de criação do zero, mas recriar a Storage Account em produção causaria interrupção severa à aplicação de pagamentos, violando o SLA. O distrator C representa o erro de superestimar o risco de uma operação não disruptiva e perderia o prazo de 4 horas imposto pelo time de auditoria. O distrator D é tecnicamente plausível como camada adicional de segurança, mas o Defender for Storage não substitui os logs de diagnóstico para auditoria detalhada de operações individuais.
A role Monitoring Contributor possui permissão suficiente para criar e modificar Diagnostic Settings, portanto não há bloqueio de permissão que justifique qualquer outra abordagem.
Gabarito — Cenário 3
Resposta: C
A tabela de levantamento deixa explícito que o Traffic Analytics está com status Disabled. Esse é o componente que processa os dados brutos do NSG Flow Log armazenados na Storage Account e os envia ao workspace do Log Analytics em um formato consultável pelo Network Insights. Sem o Traffic Analytics ativo, o fluxo de dados simplesmente não chega ao workspace, independentemente de todos os outros componentes estarem corretos.
A informação irrelevante é a recriação do Network Watcher há duas semanas. Esse evento não afeta a exibição de dados no Network Insights quando o Traffic Analytics está corretamente configurado. O Network Watcher recriado já está funcional, como evidenciado pelo fato de o NSG Flow Log estar habilitado.
O distrator A é o mais perigoso porque cria uma falsa expectativa de que o problema se resolverá sozinho com o tempo, fazendo o administrador aguardar sem tomar ação. Não existe período de inicialização de 30 dias para o Network Watcher. O distrator B é factualmente incorreto: Version 2 é a versão recomendada e suportada em todas as regiões. O distrator D confunde a ausência de Traffic Analytics com ausência de dados na Storage Account, que são problemas completamente distintos.
Gabarito — Cenário 4
Resposta: A
A sequência correta é 2, 1, 4, 3, 5, que segue o princípio de diagnóstico progressivo: partir do nível mais externo e visível antes de avançar para verificações mais invasivas ou específicas.
Passo 2 confirma o estado básico: o VM Insights está habilitado e o workspace está vinculado. Sem isso, todos os passos seguintes são irrelevantes.
Passo 1 verifica a presença e o status do Dependency Agent no portal, identificando rapidamente se o componente está ausente ou com falha de provisionamento.
Passo 4 verifica a compatibilidade da distribuição Linux com o Dependency Agent, pois uma instalação aparentemente bem-sucedida pode estar inativa em uma distro não suportada.
Passo 3 consulta a tabela VMConnection no workspace para confirmar se algum dado está chegando, validando o diagnóstico de forma objetiva antes de acessar a VM.
Passo 5 é o último passo porque exige acesso direto à VM via SSH, o que é mais invasivo, demanda credenciais e é desnecessário se os passos anteriores já localizaram o problema.
A sequência B comete o erro de ir ao SSH (passo 5) antes de verificar compatibilidade de SO (passo 4), queimando tempo em uma verificação operacional quando o problema pode ser arquitetural. A sequência C começa pela consulta KQL, que só faz sentido após confirmar que o ambiente básico está configurado. A sequência D começa pelo passo mais invasivo, invertendo completamente a lógica de diagnóstico progressivo.
Árvore de Troubleshooting: Configure and interpret monitoring of virtual machines, storage accounts, and networks by using Azure Monitor Insights
Legenda:
| Cor | Significado |
|---|---|
| Azul escuro | Sintoma inicial (ponto de entrada) |
| Azul | Pergunta diagnóstica (decisão de caminho) |
| Vermelho | Causa identificada |
| Verde | Ação recomendada ou resolução |
| Laranja | Validação ou verificação intermediária |
Diante de um problema real, comece pelo nó raiz identificando qual recurso está sem dados: VM, rede ou storage. A partir daí, siga as perguntas de cor azul respondendo com base no que você observa no portal ou nos logs. Cada resposta elimina um conjunto de hipóteses e estreita o caminho até um nó vermelho de causa ou verde de ação. Nós laranja indicam que é necessário aguardar ou validar antes de concluir o diagnóstico. Nunca pule níveis: o diagnóstico progressivo evita ações corretivas aplicadas no componente errado.