Laboratório de Troubleshooting: Create a Backend Pool
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
A equipe de operações relata que o Azure Application Gateway de uma aplicação web em produção começou a retornar erros HTTP 502 para todos os usuários. O gateway foi implantado há três semanas e funcionava normalmente até ontem à tarde.
O engenheiro responsável acessa o painel de health probes e encontra o seguinte estado:
Backend Pool: pool-webapp
Target: webapp-prod.azurewebsites.net
Status: Unhealthy
Probe response: TCP connect OK | HTTP 200 received | Host header mismatch
Backend Settings: bs-webapp
Protocol: HTTPS
Port: 443
Pick hostname from backend target: Disabled
Host name override: appgw-internal.contoso.com
Informações adicionais coletadas durante a investigação:
- O App Service está respondendo normalmente quando acessado diretamente via navegador
- O certificado TLS do App Service é válido e não está expirado
- A subnet do Application Gateway tem NSG associado, mas as regras de entrada na porta 65200-65535 estão corretamente configuradas
- O App Service Plan está na camada Standard S2
Qual é a causa raiz do erro 502?
A) O NSG da subnet do Application Gateway está bloqueando a comunicação com o backend
B) A configuração de backend settings está enviando um host header incorreto, que o App Service rejeita por não corresponder ao seu hostname configurado
C) O App Service Plan na camada Standard não suporta integração com Application Gateway
D) O protocolo HTTPS na backend setting exige que o certificado do App Service seja carregado manualmente no gateway
Cenário 2 — Decisão de Ação
Durante uma revisão de arquitetura, foi identificado que um Azure Load Balancer Standard interno está com o backend pool configurado no modo NIC, associando diretamente as NICs de quatro VMs localizadas em VNet-Producao. A causa identificada é que duas novas VMs precisam ser adicionadas ao pool, mas essas VMs estão em VNet-DR, conectada via VNet Peering ativo e funcional.
O ambiente possui as seguintes restrições:
- O Load Balancer é crítico e processa transações financeiras em tempo real
- A janela de manutenção disponível é de 30 minutos, iniciando em 10 minutos
- Reconfigurar o backend pool no modo IP requer remoção e recriação do pool existente, com breve interrupção
- Adicionar as VMs de
VNet-DRdiretamente no modo NIC atual não é tecnicamente possível
Qual é a ação correta a tomar neste momento?
A) Iniciar imediatamente a recriação do backend pool no modo IP para incluir as VMs de VNet-DR dentro da janela de manutenção disponível
B) Adicionar as VMs de VNet-DR via endereço IP diretamente no modo NIC atual, aproveitando o peering ativo
C) Adiar a alteração para uma janela de manutenção planejada com mais tempo, documentando o risco e mantendo o pool atual em operação
D) Remover as quatro VMs atuais do pool, recriar o pool em modo IP e readicionar todas as seis VMs durante a janela de 30 minutos
Cenário 3 — Causa Raiz
Um engenheiro está configurando um novo Azure Load Balancer Standard público para distribuir tráfego entre três VMs. Após concluir a configuração, ele executa um teste de conectividade a partir de uma máquina externa e não obtém resposta. Ao investigar, coleta as seguintes informações:
# Teste de conectividade
$ curl -v http://52.178.45.10:80
* Trying 52.178.45.10:80...
* Connection timed out after 30000 milliseconds
* Closing connection 0
# Estado do backend pool
$ az network lb address-pool show \
--resource-group rg-producao \
--lb-name lb-frontend \
--name pool-vms \
--query "loadBalancerBackendAddresses"
[
{ "name": "vm01-ip", "ipAddress": "10.0.1.4" },
{ "name": "vm02-ip", "ipAddress": "10.0.1.5" },
{ "name": "vm03-ip", "ipAddress": "10.0.1.6" }
]
# Health probe
Probe: probe-http-80
Status: All backends Unhealthy
Protocol: HTTP | Port: 80 | Path: /healthcheck
Informações adicionais:
- As três VMs têm IIS instalado e o site padrão ativo na porta 80
- O NSG associado às NICs das VMs permite entrada na porta 80 a partir de qualquer origem
- O Load Balancer foi criado com SKU Standard e IP público de SKU Standard
- As VMs não possuem IP público individual associado
- O engineer configurou o backend pool no modo endereço IP usando os IPs privados das VMs
Qual é a causa raiz da falha?
A) O health probe está configurado com o caminho /healthcheck, que não existe nas VMs, fazendo com que o Load Balancer marque todos os backends como unhealthy e não encaminhe tráfego
B) VMs sem IP público não podem ser membros de backend pool em Load Balancers públicos no modo endereço IP
C) O NSG das NICs das VMs bloqueia o tráfego proveniente do Load Balancer, pois o IP de origem das sondas de saúde é o IP do frontend público
D) O SKU Standard do Load Balancer requer que o backend pool no modo endereço IP esteja associado a uma VNet explicitamente declarada na configuração do pool
Cenário 4 — Sequência de Diagnóstico
Um Azure Application Gateway com WAF habilitado apresenta o seguinte comportamento: requisições legítimas de usuários estão sendo intermitentemente bloqueadas com HTTP 403, enquanto o backend pool reporta todos os membros como Healthy. O ambiente inclui um backend pool com duas instâncias de App Service e health probes configurados corretamente.
O engenheiro recebe os seguintes passos de investigação disponíveis:
- Verificar os logs do WAF no Log Analytics para identificar quais regras estão disparando e para quais URIs
- Confirmar que os health probes estão retornando HTTP 200 para todos os membros do backend pool
- Verificar se o backend pool está configurado com FQDN ou endereço IP como destino
- Analisar os cabeçalhos das requisições bloqueadas para identificar padrões comuns entre elas
- Verificar se o modo do WAF está definido como Detection ou Prevention
Qual é a sequência correta de investigação para esse sintoma?
A) 2 -> 1 -> 5 -> 4 -> 3
B) 5 -> 1 -> 4 -> 2 -> 3
C) 3 -> 2 -> 1 -> 4 -> 5
D) 2 -> 3 -> 5 -> 1 -> 4
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
A pista central está no log do health probe: HTTP 200 received | Host header mismatch. O backend está respondendo com sucesso na camada TCP e até retornando HTTP 200, mas o Application Gateway registra uma incompatibilidade de host header. O App Service, por ser uma plataforma multitenancy, roteia requisições com base no header Host. Quando a backend setting envia appgw-internal.contoso.com como host header, o App Service não reconhece esse hostname e rejeita a requisição de forma que o gateway interpreta como falha no backend, gerando 502.
A informação irrelevante propositalmente inserida é o estado das regras do NSG na porta 65200-65535: essa configuração é necessária para o funcionamento da infraestrutura interna do Application Gateway, mas não tem relação com a falha descrita, já que o probe está chegando ao backend e recebendo resposta. Focar no NSG seria um erro de diagnóstico clássico de confundir verificação de infraestrutura com causa real.
O distrator mais perigoso é o D, pois leva o engenheiro a procurar um problema de certificado TLS quando o próprio log indica que a camada TLS funcionou e o HTTP 200 foi recebido.
Gabarito — Cenário 2
Resposta: C
A restrição crítica que define a resposta correta é o tempo disponível. Recriar o backend pool no modo IP é a solução tecnicamente correta, mas exige remoção e recriação com interrupção de serviço. Com apenas 10 minutos até o início da janela e 30 minutos de duração, o risco de não concluir a operação dentro do prazo em um ambiente de transações financeiras é alto demais para ser aceito sem planejamento adequado.
A alternativa A falha por ignorar a restrição de tempo e o risco de interrupção em produção. A alternativa B é tecnicamente impossível: o modo NIC não aceita recursos fora da VNet local do Load Balancer, e o peering ativo não altera essa limitação de associação. A alternativa D agrava o risco ao incluir a remoção das quatro VMs existentes antes de garantir que a recriação será concluída no prazo.
A consequência real de executar a alternativa A ou D com falha na conclusão seria deixar o Load Balancer sem backend pool operacional, interrompendo o processamento de transações financeiras por tempo indeterminado.
Gabarito — Cenário 3
Resposta: A
O conjunto de informações aponta para uma única causa: o caminho /healthcheck configurado no health probe não existe nas VMs, que executam apenas o site padrão do IIS. O IIS retorna HTTP 404 para esse caminho, e o Load Balancer Standard interpreta qualquer resposta diferente de 2xx ou 3xx como falha, marcando todos os backends como Unhealthy. Com todos os backends marcados como unhealthy, o Load Balancer Standard para de encaminhar tráfego, resultando em timeout nas conexões de clientes externos.
A informação irrelevante é que as VMs não possuem IP público individual. No modo de backend pool por endereço IP, o Load Balancer Standard não exige IP público nas VMs de destino; a comunicação ocorre via rede interna. Essa informação foi incluída para induzir o leitor à alternativa B, que representa um equívoco comum sobre o funcionamento do modo IP.
O distrator mais perigoso é o C, pois o comportamento do NSG em relação às sondas de saúde é uma área de confusão real. No entanto, o próprio enunciado informa que o NSG permite entrada na porta 80 de qualquer origem, eliminando essa hipótese com base nas informações disponíveis.
Gabarito — Cenário 4
Resposta: A
A sequência correta é: 2 -> 1 -> 5 -> 4 -> 3.
O raciocínio diagnóstico progressivo parte do estado mais básico para o mais específico:
Primeiro confirma-se que o backend pool está saudável (passo 2), eliminando a hipótese de que os 403 sejam causados por falha no backend e não no WAF. Em seguida, analisa-se os logs do WAF (passo 1), que é a fonte direta de evidência para bloqueios 403. Com os logs em mãos, verifica-se o modo do WAF (passo 5), pois um WAF em modo Prevention bloqueia ativamente, enquanto em Detection apenas registra. Com o modo confirmado, analisa-se os padrões nas requisições bloqueadas (passo 4) para identificar a regra disparada. O passo 3, verificar se o destino é FQDN ou IP, é relevante para outros tipos de falha, mas não para bloqueios 403 gerados pelo WAF, sendo o passo de menor prioridade neste contexto.
A alternativa B começa pelo modo do WAF antes de consultar os logs, perdendo a oportunidade de já ter a evidência concreta antes de formular hipóteses. A alternativa C inicia verificando o tipo de destino do backend pool, que é irrelevante para o sintoma de bloqueio por WAF. O erro de raciocínio comum nos distratores é iniciar a investigação por hipóteses sem primeiro coletar a evidência mais direta disponível, que neste caso são os próprios logs do WAF.
Árvore de Troubleshooting: Create a Backend Pool
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, comece pelo nó raiz identificando se o sintoma é de backends marcados como unhealthy ou de tráfego não encaminhado mesmo com backends saudáveis. Siga as ramificações respondendo cada pergunta com base no que é observável diretamente no portal ou via CLI, sem pular etapas. Cada caminho vermelho indica uma causa que deve ser confirmada antes de executar a ação verde correspondente. Nós laranja indicam pontos onde uma verificação adicional é necessária antes de concluir o diagnóstico.