Laboratório de Troubleshooting: Troubleshoot Load Balancing
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
A equipe de operações relata que uma aplicação web exposta via Azure Application Gateway começou a retornar HTTP 502 para todos os usuários às 14h32. O time de infraestrutura verifica que as VMs do backend pool estão em execução, respondem ao ping interno e servem páginas corretamente quando acessadas diretamente pelo IP privado na porta 8080.
O Application Gateway foi configurado há três semanas e operava normalmente. Nenhuma alteração de infraestrutura foi registrada no dia do incidente. O certificado TLS do listener foi renovado ontem pela equipe de segurança.
A configuração relevante do backend é a seguinte:
Backend Settings:
Protocol: HTTP
Port: 80
Cookie-based affinity: Disabled
Request timeout: 20s
Health Probe (custom):
Protocol: HTTP
Host: app.contoso.internal
Path: /healthz
Interval: 30s
Threshold: 3
Match status codes: 200-399
O log do Application Gateway registra o seguinte:
ResourceId: /subscriptions/.../applicationGateways/agw-prod
Category: ApplicationGatewayFirewallLog
TimeGenerated: 2024-11-12T14:32:07Z
BackendPool: pool-web
BackendSettingName: settings-web
BackendHttpStatusCode: (none)
Reason: UnhealthyBackend
Qual é a causa raiz do problema?
A) O certificado TLS renovado ontem é incompatível com o listener do Application Gateway, causando falha no handshake com o backend
B) A health probe está tentando conectar na porta 80 conforme as Backend Settings, mas os servidores estão escutando na porta 8080, marcando todas as instâncias como não saudáveis
C) O timeout de requisição de 20 segundos é insuficiente para o endpoint /healthz responder, causando falha intermitente que escalou para falha total
D) O log UnhealthyBackend indica que o NSG da subnet do Application Gateway foi alterado e está bloqueando o tráfego de retorno dos backends
Cenário 2 — Decisão de Ação
A causa de uma falha foi identificada: o Azure Load Balancer Standard de um ambiente de produção tem sua health probe configurada para TCP na porta 443, mas os servidores do backend pool encerraram o serviço nessa porta após uma atualização de aplicação que migrou o HTTPS para a porta 8443. O Load Balancer marcou todas as instâncias como não saudáveis e o tráfego está interrompido há 12 minutos.
O ambiente possui as seguintes restrições:
- A janela de manutenção oficial é às 22h; atualmente são 15h45
- O time de segurança exige aprovação formal para qualquer alteração de regra de firewall ou NSG
- A alteração da porta da health probe no Load Balancer não requer aprovação de segurança e pode ser feita imediatamente pelo administrador Azure
- Reverter a atualização da aplicação exigiria redeployment completo com tempo estimado de 45 minutos e perda dos dados de sessão ativos
Qual é a ação correta a tomar neste momento?
A) Aguardar a janela de manutenção das 22h para realizar a alteração com segurança e documentação adequada
B) Iniciar imediatamente o redeployment da versão anterior da aplicação para restaurar o serviço na porta 443
C) Alterar a health probe do Load Balancer para monitorar a porta 8443, restaurando o tráfego sem necessidade de aprovação adicional
D) Criar uma nova regra no NSG liberando a porta 8443 e submeter aprovação ao time de segurança antes de qualquer outra ação
Cenário 3 — Causa Raiz
Um desenvolvedor reporta que sua aplicação, que consome uma API exposta por um Azure Load Balancer interno Standard, experimenta falhas de conexão esporádicas. As falhas ocorrem exclusivamente em chamadas que demoram mais de dois minutos para completar, como operações de processamento de lote. Chamadas rápidas funcionam sem problemas.
O administrador verifica que todas as VMs do backend pool estão saudáveis, a health probe TCP na porta 443 retorna sucesso em todas as instâncias, e não há alertas de CPU ou memória nas VMs. Os logs da aplicação cliente mostram:
[ERROR] 2024-11-12 16:04:33 - Connection reset by peer
[ERROR] 2024-11-12 16:04:33 - Socket closed unexpectedly after 120s
[ERROR] 2024-11-12 16:04:33 - Retry attempt 1 of 3 failed
O Load Balancer foi implantado há seis meses com todas as configurações padrão. Recentemente a equipe adicionou uma segunda NIC nas VMs para tráfego de storage, mas essa NIC usa uma subnet diferente e não está associada ao backend pool.
Qual é a causa raiz das falhas?
A) A segunda NIC adicionada às VMs está causando conflito de roteamento, fazendo o tráfego de retorno sair pela interface errada e quebrando o fluxo TCP
B) O idle timeout padrão do Load Balancer é de 4 minutos, mas conexões longas sem tráfego ativo nas primeiras etapas do processamento atingem esse limite e são encerradas
C) A health probe TCP não valida o estado real da aplicação, apenas a disponibilidade da porta, permitindo que instâncias degradadas recebam tráfego
D) O Load Balancer Standard interno não suporta conexões com duração superior a 120 segundos por limitação de design da camada 4
Cenário 4 — Sequência de Diagnóstico
Um administrador recebe um alerta de que o Azure Application Gateway de um ambiente de produção está retornando HTTP 504 (Gateway Timeout) para uma parcela das requisições. O problema é intermitente e afeta apenas alguns usuários, não todos.
Os seguintes passos de investigação estão disponíveis, fora de ordem:
- Verificar os logs do Application Gateway no Log Analytics para identificar quais instâncias do backend pool estão sendo selecionadas nas requisições que falham
- Confirmar se a health probe está marcando alguma instância como não saudável e quantas instâncias permanecem ativas no pool
- Verificar nos logs do servidor backend se as requisições problemáticas chegam e qual é o tempo de processamento registrado
- Checar a configuração de request timeout nas Backend Settings do Application Gateway e compará-la com o tempo médio de resposta do backend
- Reproduzir o problema fazendo requisições manuais ao endpoint afetado e registrar o tempo de resposta
Qual é a sequência correta de investigação?
A) 5 → 1 → 2 → 3 → 4
B) 2 → 1 → 3 → 4 → 5
C) 2 → 5 → 1 → 3 → 4
D) 1 → 2 → 5 → 3 → 4
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
A pista decisiva está na descrição direta: os servidores respondem corretamente na porta 8080, mas a Backend Settings define a porta 80 para comunicação. A health probe customizada herda a porta definida nas Backend Settings quando não especifica uma porta própria, de modo que todas as sondagens chegam na porta 80, não encontram resposta e marcam todas as instâncias como não saudáveis. O resultado é o UnhealthyBackend registrado no log.
A informação sobre a renovação do certificado TLS é propositalmente irrelevante: o backend usa HTTP, não HTTPS, e o problema ocorre na comunicação entre o gateway e o backend, não no listener externo. Focar no certificado é o erro de diagnóstico mais provável de acontecer sob pressão, pois é a mudança mais recente registrada no ambiente.
A alternativa C é plausível em teoria, mas um timeout de 20 segundos causaria falhas graduais e intermitentes, não uma falha total e abrupta às 14h32 sem histórico anterior. A alternativa D inverte a lógica: alterações de NSG deixariam rastro no histórico de mudanças e afetariam também acessos diretos às VMs, o que o enunciado descarta explicitamente.
O distrator mais perigoso é A: agir sobre o certificado sem validar a porta do backend atrasaria a resolução e introduziria uma mudança desnecessária em produção.
Gabarito — Cenário 2
Resposta: C
A causa já está identificada no enunciado: a porta da health probe não corresponde mais à porta em que o serviço está ativo. Alterar a porta de monitoramento de 443 para 8443 resolve o problema diretamente, não requer aprovação do time de segurança conforme explicitado no enunciado, e pode ser executado imediatamente pelo administrador.
A alternativa A ignora a gravidade de um serviço de produção interrompido há 12 minutos. Aguardar seis horas quando existe uma ação corretiva disponível imediatamente e sem restrições é a decisão errada. A alternativa B é tecnicamente válida mas desnecessariamente custosa: 45 minutos de downtime adicional e perda de sessões quando a causa real não exige redeployment. A alternativa D bloqueia a resolução em um processo de aprovação antes de agir, quando a ação necessária não envolve NSG.
O erro de raciocínio central dos distratores é tratar restrições como obstáculos absolutos sem verificar quais se aplicam à ação específica disponível.
Gabarito — Cenário 3
Resposta: B
O padrão das falhas é a pista definitiva: todas ocorrem após exatamente dois minutos de conexão ativa sem tráfego no fluxo. O idle timeout padrão do Azure Load Balancer é de 4 minutos, mas operações de processamento de lote frequentemente estabelecem a conexão TCP e ficam sem tráfego enquanto processam no backend antes de enviar a resposta. Se o Load Balancer não detecta tráfego no fluxo por tempo suficiente, encerra a conexão, o que o cliente registra como "Connection reset by peer".
A segunda NIC adicionada às VMs é a informação irrelevante inserida propositalmente. Ela está em uma subnet diferente, não associada ao backend pool, e não tem relação com o fluxo de tráfego do Load Balancer. Focar nela seria um erro clássico de confundir mudança recente com causa do problema.
A alternativa C descreve uma limitação real de health probes TCP, mas não explica o padrão de falha em exatamente 120 segundos. A alternativa D é tecnicamente falsa: o Load Balancer Standard não tem limite fixo de duração de conexão por design.
O distrator mais perigoso é A: investigar conflito de roteamento na segunda NIC consumiria tempo considerável e não levaria à resolução.
Gabarito — Cenário 4
Resposta: B
A sequência correta é: 2 → 1 → 3 → 4 → 5.
O raciocínio diagnóstico progressivo parte do nível mais alto de observabilidade disponível antes de descer para detalhes específicos. O passo 2 (verificar status das instâncias no pool) determina se o problema é de disponibilidade de backend, o que mudaria toda a direção do diagnóstico. Com o status das instâncias confirmado, o passo 1 (identificar quais instâncias recebem as requisições que falham) isola se o problema está em uma instância específica ou no comportamento geral. O passo 3 (logs do servidor) verifica se as requisições chegam ao backend e quanto tempo levam. O passo 4 (comparar request timeout com tempo real de resposta) formula a hipótese mais provável para o 504. O passo 5 (reprodução manual) valida a hipótese com dados concretos.
A sequência A começa pela reprodução manual, que não acrescenta informação diagnóstica antes de entender o estado do ambiente. A sequência C intercala a reprodução antes de consultar logs, invertendo a ordem de custo versus informação. A sequência D começa pela identificação de instâncias específicas sem primeiro verificar o estado geral do pool, o que pode desperdiçar tempo investigando a instância errada.
A disciplina central desta sequência é: validar o estado do ambiente antes de tentar reproduzir ou hipotecar causas.
Árvore de Troubleshooting: Troubleshoot Load Balancing
Legenda de cores:
| Cor | Tipo de nó |
|---|---|
| Azul escuro | Sintoma inicial (ponto de entrada) |
| Azul médio | 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 descrevendo o sintoma observado e responda cada pergunta com base no que é verificável diretamente no portal, nos logs ou via CLI. Em cada bifurcação, escolha o caminho que corresponde ao estado observado, não ao estado esperado. Siga as ramificações até alcançar um nó de causa identificada (vermelho) e então aplique a ação correspondente (verde). Se a ação não resolver o problema, retorne ao último nó de verificação intermediária (laranja) e revise o estado real antes de seguir outro caminho.