Laboratório de Troubleshooting: Configure monitoring, network diagnostics, and logs in Azure Network Watcher
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Uma equipe de segurança reporta que os NSG Flow Logs de uma sub-rede crítica pararam de ser gravados no Storage Account configurado. O ambiente foi verificado e as seguintes informações foram coletadas:
- O Storage Account existe e está na mesma região que o Network Watcher
- O NSG Flow Logs está habilitado no portal com status "Enabled"
- A retenção está configurada para 30 dias
- O Storage Account foi migrado para a camada de desempenho Premium (Block Blobs) há três dias, coincidindo com o início do problema
- O workspace do Log Analytics associado continua recebendo dados normalmente
- Nenhuma política de bloqueio de recurso foi aplicada ao Storage Account
Qual é a causa raiz da interrupção na gravação dos Flow Logs?
A) A retenção de 30 dias está em conflito com a camada Premium, que exige retenção mínima de 90 dias.
B) O NSG Flow Logs não é compatível com Storage Accounts na camada Premium Block Blobs; apenas contas de uso geral v2 (Standard) são suportadas.
C) O workspace do Log Analytics e o Storage Account não podem ser usados simultaneamente como destino para o mesmo NSG Flow Log.
D) O Network Watcher foi desabilitado automaticamente na região após a migração do Storage Account.
Cenário 2 — Decisão de Ação
A equipe de rede identificou que o Connection Monitor de um ambiente de produção está reportando falhas de conectividade entre um conjunto de VMs e um endpoint externo. A causa foi identificada: o agente do Network Watcher não está instalado nas VMs de origem porque uma política do Azure criada recentemente bloqueia a instalação de extensões de VM em máquinas do grupo de recursos de produção.
O ambiente tem as seguintes restrições:
- As VMs de produção não podem ser reiniciadas durante o horário comercial (07h às 20h)
- A política de bloqueio de extensões está atribuída no nível da assinatura e requer aprovação do time de governança para ser alterada
- O time de governança não está disponível nas próximas 4 horas
- Existe um ambiente de homologação com VMs idênticas, sem restrição de extensões, na mesma VNet
- O horário atual é 14h30
Qual é a ação correta a tomar neste momento?
A) Instalar manualmente o agente do Network Watcher via RDP nas VMs de produção, contornando a política de extensões.
B) Reiniciar as VMs de produção para forçar a reinstalação automática das extensões via Azure Update Manager.
C) Reconfigurar o Connection Monitor para usar as VMs de homologação como fonte, validando a conectividade da VNet a partir delas enquanto a aprovação de governança é aguardada.
D) Aguardar as 4 horas para que o time de governança esteja disponível e libere a política antes de tomar qualquer ação.
Cenário 3 — Causa Raiz
Um analista executa o IP Flow Verify para diagnosticar por que uma VM não consegue estabelecer conexão com um servidor de banco de dados interno na porta 1433. O resultado retornado é:
IP Flow Verify Result
---------------------
Direction: Outbound
Protocol: TCP
Local IP: 10.1.2.4
Local Port: *
Remote IP: 10.2.5.10
Remote Port: 1433
Access: Allow
Rule Applied: DefaultRule_AllowVnetOutBound
Mesmo com esse resultado, a aplicação continua falhando ao tentar conectar ao banco de dados. O analista verifica que:
- A VM e o servidor de banco de dados estão em VNets diferentes conectadas por VNet Peering
- O servidor de banco de dados tem um NSG associado à sua NIC
- O servidor de banco de dados está rodando SQL Server e o serviço está ativo
- A VM de origem tem o Windows Firewall desabilitado
- O VNet Peering está no estado "Connected" em ambas as VNets
Qual é a causa raiz da falha de conectividade?
A) O VNet Peering em estado "Connected" não garante roteamento bidirecional; é necessário verificar se o peering de retorno também está ativo.
B) O IP Flow Verify foi executado apenas na direção de saída da VM de origem; o NSG da NIC do servidor de banco de dados pode estar bloqueando o tráfego inbound na porta 1433.
C) A regra aplicada é uma regra padrão do Azure, o que indica que nenhuma regra de NSG personalizada foi criada, e o tráfego entre VNets distintas é bloqueado por padrão.
D) O SQL Server requer que o IP Flow Verify seja executado com protocolo UDP, pois a porta 1433 utiliza ambos os protocolos para estabelecer a sessão inicial.
Cenário 4 — Sequência de Diagnóstico
Uma VM de produção perdeu conectividade com a internet de forma abrupta. O time de operações precisa diagnosticar a causa usando as ferramentas disponíveis no Azure Network Watcher. Os passos de investigação disponíveis são:
- Executar Next Hop para verificar o roteamento efetivo da VM em direção à internet
- Executar IP Flow Verify (outbound, porta 80/443) para verificar se NSG está bloqueando
- Analisar o Topology da VNet para verificar se a VM ainda está associada à sub-rede correta
- Verificar nos NSG Flow Logs se há registros de Deny recentes saindo da NIC da VM
- Executar o Connection Monitor para validar conectividade contínua após a correção
Qual é a sequência correta de investigação?
A) 3 → 1 → 2 → 4 → 5
B) 2 → 1 → 4 → 3 → 5
C) 1 → 3 → 2 → 4 → 5
D) 4 → 2 → 1 → 3 → 5
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
O NSG Flow Logs exige que o Storage Account de destino seja do tipo General Purpose v2 (Standard). Contas na camada Premium Block Blobs não são suportadas como destino para Flow Logs, mesmo que o recurso apareça como "Enabled" no portal. O portal não valida ativamente a compatibilidade da camada ao salvar a configuração, o que torna esse erro silencioso e difícil de detectar sem conhecer a restrição.
A pista confirmadora no enunciado é a coincidência exata entre o início do problema e a migração da conta para a camada Premium, há três dias.
A informação irrelevante propositalmente incluída é o fato de o workspace do Log Analytics continuar recebendo dados. Isso não tem relação com a falha no Storage Account e pode induzir o leitor a descartar o Storage Account como causa, mas os dois destinos operam de forma independente.
O distrator mais perigoso é a alternativa C. Na prática, o Log Analytics e o Storage Account podem sim coexistir como destinos do mesmo Flow Log. Um analista que escolher C irá remover o Log Analytics desnecessariamente, perdendo dados de monitoramento sem resolver o problema real.
Gabarito — Cenário 2
Resposta: C
Dado o conjunto de restrições, a única ação que pode ser executada agora, dentro do horário comercial, sem reiniciar VMs de produção, sem contornar a política de governança e sem aguardar 4 horas, é usar as VMs de homologação como fonte temporária no Connection Monitor. Como elas estão na mesma VNet, os resultados validam o comportamento de rede no mesmo segmento lógico, o que é suficiente para avançar o diagnóstico enquanto a aprovação é obtida.
A alternativa A representa contorno de controle de segurança e governança, o que viola as restrições do ambiente independentemente de ser tecnicamente possível. A alternativa B viola explicitamente a restrição de não reiniciar VMs durante o horário comercial. A alternativa D é a ação mais conservadora, mas ignora que existe uma alternativa válida que pode ser executada agora sem violar nenhuma restrição.
Gabarito — Cenário 3
Resposta: B
O IP Flow Verify avalia as regras de NSG associadas a um recurso específico, em uma direção específica. Quando executado na VM de origem em direção outbound, ele verifica apenas o NSG da NIC e da sub-rede da VM de origem. Ele não avalia o NSG da NIC ou da sub-rede do destino. O servidor de banco de dados tem um NSG próprio associado à sua NIC, que pode estar bloqueando o tráfego inbound na porta 1433, e essa verificação simplesmente não foi feita.
A pista confirmadora é a combinação de dois fatos: o resultado "Allow" na saída e a menção explícita de que o servidor de banco de dados tem um NSG associado à sua NIC, dado que foi inserido no enunciado com propósito diagnóstico claro.
A alternativa A é o distrator mais sofisticado. O VNet Peering em estado "Connected" em ambas as VNets, conforme declarado no enunciado, indica que o roteamento bidirecional está estabelecido. Focar nisso seria ignorar a informação já fornecida. A alternativa C está errada porque a regra padrão AllowVnetOutBound inclui tráfego entre VNets em peering, e o resultado "Allow" confirma que o tráfego está sendo permitido na saída.
Gabarito — Cenário 4
Resposta: A
A sequência correta é 3 → 1 → 2 → 4 → 5, seguindo o princípio de diagnóstico progressivo: do mais simples e estrutural ao mais granular, e validação ao final.
O passo 3 (Topology) verifica primeiro se a VM ainda está na topologia esperada da VNet, o que descarta problemas de configuração estrutural antes de qualquer teste de tráfego. O passo 1 (Next Hop) verifica se há rota válida para a internet, identificando problemas de UDR ou ausência de gateway sem precisar testar tráfego. O passo 2 (IP Flow Verify) testa se NSG está bloqueando o fluxo específico, somente após confirmar que a rota existe. O passo 4 (NSG Flow Logs) analisa registros históricos para confirmar padrão de Deny, o que é mais lento e deve ocorrer após as hipóteses serem testadas ativamente. O passo 5 (Connection Monitor) é sempre o último, pois serve para validar continuamente após a correção, não para diagnosticar.
A sequência B começa com IP Flow Verify antes de verificar roteamento, o que pode levar a uma conclusão de "Allow" e ignorar um problema de rota. A sequência D começa pela análise de logs, que é rativa e lenta demais para ser o primeiro passo em uma falha ativa.
Árvore de Troubleshooting: Configure monitoring, network diagnostics, and logs in Azure Network Watcher
Legenda de cores:
| Cor | Tipo de nó |
|---|---|
| Azul escuro | Sintoma inicial (ponto de entrada) |
| Azul | Pergunta diagnóstica |
| Laranja | Verificação ou validação intermediária |
| Vermelho | Causa identificada |
| Verde | Ação recomendada ou resolução |
Diante de um problema real, inicie sempre pelo nó raiz e responda cada pergunta com base no que foi observado ou medido no ambiente, nunca por suposição. Perguntas com resposta "Sim" e "Não" levam a caminhos distintos: siga o ramo correspondente ao estado real observado. Os nós laranja indicam que uma verificação adicional é necessária antes de confirmar a causa. Ao atingir um nó vermelho, a causa está identificada; o nó verde imediatamente seguinte indica a ação corretiva. O nó final verde "Validar correcao com Connection Monitor continuo" é o ponto de encerramento de qualquer caminho, confirmando que a correção foi efetiva antes de fechar o incidente.