Laboratório de Troubleshooting: Interpret Virtual Network Flow Logs
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Uma equipe de operações configurou o VNet Flow Logs em uma VNet de produção chamada vnet-core-prod e habilitou a Traffic Analytics com um intervalo de agregação de 10 minutos. O workspace do Log Analytics associado é o law-netops-prod. Após 48 horas, o time acessa o Traffic Analytics no portal e constata que nenhum dado de fluxo está sendo exibido. O mapa de tráfego aparece vazio e as consultas KQL no workspace retornam zero registros para a tabela NTANetAnalytics.
O analista verifica as configurações e coleta as seguintes informações:
VNet Flow Logs Status: Enabled
Storage Account: stflowlogsprod001 (LRS, região East US)
Retention (days): 30
Traffic Analytics: Enabled
Workspace: law-netops-prod (região Brazil South)
Aggregation Interval: 10 minutes
VNet: vnet-core-prod (região East US)
O analista também confirma que a conta de armazenamento stflowlogsprod001 está recebendo arquivos JSON normalmente no contêiner insights-logs-flowlogflowevent, e que o workspace law-netops-prod está ativo e respondendo a outras consultas de outros recursos.
Qual é a causa raiz do problema?
A) O intervalo de agregação de 10 minutos é muito curto para que o Traffic Analytics processe e exiba dados em VNets com alto volume de fluxo.
B) O workspace do Log Analytics está em uma região diferente da VNet e da conta de armazenamento, o que impede o Traffic Analytics de processar os dados corretamente.
C) A conta de armazenamento com replicação LRS não é suportada pelo VNet Flow Logs, e os arquivos JSON gravados são descartados antes de chegar ao Traffic Analytics.
D) O contêiner insights-logs-flowlogflowevent é o destino correto para NSG Flow Logs, não para VNet Flow Logs, indicando que o recurso configurado é do tipo errado.
Cenário 2 — Impacto Colateral
A equipe de segurança de uma organização identificou que os VNet Flow Logs de vnet-dmz-prod estavam sendo armazenados em uma conta de armazenamento com política de retenção definida para 7 dias. Para atender a um novo requisito de conformidade que exige retenção mínima de 90 dias, o administrador alterou o valor de retenção diretamente na configuração do VNet Flow Logs para 90 dias e confirmou a alteração no portal. A mudança foi aplicada com sucesso e o portal exibe o novo valor.
Qual consequência secundária essa alteração pode causar?
A) Os registros de fluxo dos 7 dias anteriores à alteração serão automaticamente replicados para uma camada de armazenamento fria, aumentando os custos de transação de forma imediata.
B) O custo de armazenamento da conta associada aumentará progressivamente à medida que os blobs de log acumulem por 90 dias sem exclusão automática, podendo exceder o orçamento provisionado para a conta.
C) O Traffic Analytics deixará de processar os dados de fluxo imediatamente após a alteração da retenção, pois o serviço requer que retenção e intervalo de agregação estejam sincronizados.
D) Os logs gerados antes da alteração da retenção serão excluídos imediatamente, pois a nova política sobrescreve retroativamente o ciclo de vida dos blobs existentes.
Cenário 3 — Decisão de Ação
A equipe de segurança de uma empresa precisa identificar com urgência se um endereço IP externo específico (198.51.100.42) estabeleceu conexões com qualquer VM na vnet-app-prod nas últimas 6 horas. O VNet Flow Logs está habilitado e os dados já estão disponíveis no workspace do Log Analytics law-security-prod. A equipe tem acesso ao portal do Azure e ao Log Analytics. O incidente está em andamento e cada minuto de atraso aumenta o risco.
A causa da investigação está identificada: tráfego suspeito de origem externa. O objetivo agora é confirmar ou descartar a presença desse IP nos registros de fluxo de forma rápida e precisa.
Qual é a ação correta a tomar neste momento?
A) Acessar o Traffic Analytics no portal e usar o filtro de IP na visualização do mapa de tráfego para localizar o endereço 198.51.100.42.
B) Executar uma consulta KQL diretamente no workspace law-security-prod filtrando pelo IP de origem nas tabelas de flow logs para o intervalo das últimas 6 horas.
C) Baixar os arquivos JSON brutos da conta de armazenamento referentes às últimas 6 horas e realizar a busca manual pelo IP nos registros.
D) Habilitar o diagnóstico de captura de pacotes em todas as VMs da vnet-app-prod para confirmar em tempo real se o IP ainda está ativo.
Cenário 4 — Causa Raiz
Um analista de rede está investigando por que uma VM chamada vm-api-01 na subnet-api da vnet-backend-prod não aparece nos registros de fluxo do VNet Flow Logs, enquanto todas as outras VMs da mesma subnet aparecem normalmente. O analista executa a seguinte consulta KQL e confirma ausência de registros para essa VM:
NTANetAnalytics
| where TimeGenerated > ago(24h)
| where SrcIp == "10.2.1.15" or DestIp == "10.2.1.15"
| project TimeGenerated, SrcIp, DestIp, FlowStatus, AllowedInFlows, DeniedInFlows
O resultado retorna zero linhas. O analista verifica que a VM está em execução, que sua NIC está associada à subnet correta e que o IP 10.2.1.15 é de fato o IP privado da vm-api-01. O VNet Flow Logs está habilitado no nível da VNet vnet-backend-prod. O Traffic Analytics está ativo com intervalo de 10 minutos. A VM foi recentemente migrada de vnet-legacy-prod para vnet-backend-prod há 36 horas.
Outras informações coletadas pelo analista:
- O NSG associado à NIC da
vm-api-01foi criado há mais de 6 meses e está ativo. - A VM possui um IP público associado configurado como Static.
- O workspace do Log Analytics está recebendo dados de todas as outras VMs normalmente.
Qual é a causa raiz do problema?
A) O IP público estático associado à vm-api-01 impede que o VNet Flow Logs registre o tráfego privado da VM, pois o serviço prioriza o rastreamento de fluxos com IP público dinâmico.
B) O VNet Flow Logs requer um período de propagação após a migração de uma VM entre VNets, e os 36 horas decorridos ainda estão dentro da janela esperada de até 72 horas para início do registro.
C) A consulta KQL está direcionada para a tabela NTANetAnalytics, que é populada pelo Traffic Analytics e possui latência de agregação. Como a VM foi migrada há 36 horas e o Traffic Analytics agrega em intervalos, os dados podem ainda não ter sido processados para esse IP.
D) O VNet Flow Logs foi habilitado na VNet antes da migração da VM, mas o serviço não detecta automaticamente novas NICs adicionadas à VNet após a habilitação, exigindo reabilitação do recurso.
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
O Traffic Analytics exige que o workspace do Log Analytics esteja na mesma região que a VNet monitorada ou em uma região suportada para o par. Quando o workspace está em uma região incompatível ou diferente da esperada para o processamento, o serviço falha silenciosamente na etapa de ingestão e agregação, sem exibir erros explícitos no portal. O resultado é exatamente o observado: a conta de armazenamento recebe os dados corretamente, mas o Traffic Analytics não os processa.
A pista decisiva está na combinação: vnet-core-prod e stflowlogsprod001 em East US, com o workspace em Brazil South. O fluxo de dados até a conta de armazenamento funciona de forma independente do Traffic Analytics, o que explica por que os JSONs chegam normalmente mas nenhum dado aparece no mapa.
O distrator A é irrelevante: o intervalo de 10 minutos é o menor disponível e não causa ausência total de dados, apenas maior latência de visualização em ambientes de baixo volume. O distrator C é factualmente incorreto: LRS é suportado pelo VNet Flow Logs. O distrator D representa confusão entre VNet Flow Logs e NSG Flow Logs, que são recursos distintos com contêineres de destino diferentes, mas o enunciado descreve VNet Flow Logs configurado corretamente quanto ao tipo de recurso.
Agir com base no distrator D levaria a reconfigurar um recurso que está funcionando corretamente, perdendo tempo e sem resolver o problema real.
Gabarito — Cenário 2
Resposta: B
A política de retenção configurada no VNet Flow Logs controla por quanto tempo os blobs de log são mantidos na conta de armazenamento antes de serem excluídos automaticamente. Ao aumentar de 7 para 90 dias, o volume acumulado de dados na conta crescerá continuamente ao longo do novo período de retenção. Para VNets com tráfego intenso, essa diferença pode representar um aumento significativo e progressivo no custo de armazenamento, especialmente se a conta não tiver políticas de ciclo de vida ou alertas de custo configurados.
Esse é o impacto colateral real e relevante: a mudança é tecnicamente correta para atender ao requisito de conformidade, mas tem consequência financeira direta que pode não ter sido prevista.
O distrator A é incorreto: a política de retenção do VNet Flow Logs não aciona replicação automática para camadas frias; blobs são simplesmente mantidos ou excluídos conforme o prazo. O distrator C é incorreto: a retenção e o intervalo de agregação são configurações independentes e não precisam estar sincronizadas. O distrator D é o mais perigoso: a nova política de retenção não é retroativa; ela altera apenas o comportamento de exclusão dos blobs futuros, não dos existentes.
Gabarito — Cenário 3
Resposta: B
Em um incidente ativo, velocidade e precisão são as restrições críticas. O workspace do Log Analytics já contém os dados de fluxo ingeridos, e uma consulta KQL direta permite filtrar pelo IP de origem, pela janela de tempo exata e pelos campos relevantes em segundos. Esse é o caminho mais rápido, mais preciso e mais auditável para confirmar ou descartar a presença do IP.
O distrator A parece razoável, mas o Traffic Analytics possui latência de agregação de até 60 minutos e a interface de mapa não oferece a granularidade e a exatidão de uma consulta KQL direta. Em um incidente com urgência, depender do mapa aumenta o risco de falso negativo por latência.
O distrator C é tecnicamente correto como método de último recurso, mas é extremamente lento e impraticável quando o workspace já está disponível com os dados processados.
O distrator D representa uma ação válida para investigação em tempo real, mas habilitar captura de pacotes em todas as VMs de uma VNet em produção é disruptivo, demorado e desnecessário quando os flow logs já contêm o histórico das últimas 6 horas. Além disso, não confirmaria o que já aconteceu, apenas o que está acontecendo agora.
Gabarito — Cenário 4
Resposta: C
A tabela NTANetAnalytics é populada pelo Traffic Analytics, não diretamente pelo VNet Flow Logs. O Traffic Analytics agrega os dados brutos dos flow logs em intervalos configurados (neste caso, 10 minutos) e depois os processa para a tabela. Para uma VM migrada há apenas 36 horas, é esperado que os dados ainda estejam em processo de agregação e ingestão no workspace, especialmente considerando que o Traffic Analytics pode levar até algumas horas para estabilizar a visualização de um novo endpoint.
A pista decisiva é a combinação de dois fatores: a migração recente (36 horas) e o uso da tabela NTANetAnalytics, que é a saída do Traffic Analytics e não dos flow logs brutos. Para confirmar se os dados brutos existem, o analista deveria consultar os JSONs na conta de armazenamento ou usar a tabela de flow logs brutos, se configurada.
O distrator A é factualmente incorreto: o tipo de IP público (estático ou dinâmico) não influencia o registro de tráfego privado pelo VNet Flow Logs.
O distrator B inventa um comportamento inexistente: não há documentação de janela de propagação de 72 horas para início de registro de novas VMs.
O distrator D representa o erro de raciocínio mais comum neste cenário: confundir a cobertura do VNet Flow Logs, que é no nível da VNet e cobre automaticamente todas as NICs associadas, com um comportamento de registro estático que exigiria reabilitação. O VNet Flow Logs detecta automaticamente NICs adicionadas à VNet após a habilitação.
Árvore de Troubleshooting: Interpret Virtual Network Flow Logs
Legenda de cores:
- Azul escuro: sintoma inicial, ponto de entrada na árvore
- Azul: nó de pergunta diagnóstica, exige observação ou verificação ativa
- Vermelho: causa identificada, raiz do problema confirmada
- Verde: ação recomendada ou resolução aplicável ao contexto
- Laranja: validação ou verificação intermediária após uma ação corretiva
Para usar esta árvore diante de um problema real, comece pelo nó raiz descrevendo o sintoma observado: ausência total de dados, dados parciais ou resultados inesperados nas consultas. Responda cada pergunta com base no que você observa no portal, na conta de armazenamento ou no workspace do Log Analytics. Cada ramificação elimina uma classe de causa e direciona para a próxima verificação mais específica. Não pule etapas: confirmar que os JSONs chegam à storage antes de investigar o Traffic Analytics é fundamental para não diagnosticar o componente errado.