Laboratório de Troubleshooting: Implement a load balancing rule
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
A equipe de operações recebe alertas de que uma aplicação web está intermitentemente indisponível. O ambiente consiste em um Azure Load Balancer Standard público com três VMs no backend pool, todas executando a mesma aplicação na porta 443. O Load Balancer foi implantado há duas semanas e funcionava normalmente até ontem.
Ao investigar, o engenheiro coleta as seguintes informações:
Load Balancer SKU: Standard
Frontend IP: 20.10.5.100 (estático)
Regra de balanceamento:
- Protocol: TCP
- Frontend port: 443
- Backend port: 443
- Session persistence: None
- Floating IP: Disabled
Health Probe:
- Protocol: HTTPS
- Port: 443
- Path: /healthz
- Interval: 15s
- Unhealthy threshold: 2
Backend Pool:
- vm-app-01: marcada como Degraded pelo probe
- vm-app-02: marcada como Degraded pelo probe
- vm-app-03: marcada como Degraded pelo probe
Certificado TLS das VMs: renovado ontem às 23h14
Ao acessar diretamente o IP de cada VM via navegador, a aplicação responde normalmente. O endpoint /healthz também retorna HTTP 200 quando acessado diretamente.
Qual é a causa raiz da indisponibilidade?
A) O health probe está configurado com threshold insuficiente, marcando instâncias saudáveis como degradadas após duas falhas consecutivas
B) O certificado TLS renovado nas VMs não é reconhecido pelo probe HTTPS do Load Balancer, que não valida o novo certificado corretamente
C) O probe HTTPS falha porque o Load Balancer Standard não suporta o protocolo HTTPS em health probes; apenas HTTP e TCP são aceitos
D) As regras de Network Security Group associadas às NICs das VMs foram alteradas durante a renovação do certificado, bloqueando o tráfego originado dos endereços IP de probe do Azure
Cenário 2 — Decisão de Ação
Um Load Balancer interno (ILB) Standard está distribuindo tráfego para um cluster de quatro instâncias de um serviço de processamento de pedidos em produção. A equipe identificou que a causa raiz de uma falha parcial é a seguinte: a regra de balanceamento está configurada com Session persistence definida como Client IP and Protocol, o que está concentrando todo o tráfego de um sistema de integração externo em uma única instância sobrecarregada, enquanto as demais permanecem ociosas.
O ambiente possui as seguintes restrições:
- O sistema de integração externo realiza chamadas em lote a cada 5 minutos
- A janela de manutenção programada é às 02h00 do dia seguinte
- Alterar a configuração da regra de balanceamento causa uma interrupção breve das conexões ativas existentes
- A instância sobrecarregada está processando um lote crítico iniciado há 3 minutos
Qual é a ação correta a tomar neste momento?
A) Alterar imediatamente a Session persistence para None na regra de balanceamento, aceitando a interrupção das conexões ativas para redistribuir a carga
B) Aguardar a conclusão do lote em andamento e realizar a alteração da Session persistence para None antes da próxima janela de chamada do integrador, sem esperar a janela de manutenção
C) Aguardar a janela de manutenção programada às 02h00 para realizar a alteração, pois qualquer mudança em produção deve seguir o processo de change management
D) Adicionar uma segunda regra de balanceamento sem Session persistence e remover a regra atual, de forma a evitar qualquer interrupção de conexões existentes
Cenário 3 — Causa Raiz
Um desenvolvedor reporta que após a criação de uma nova regra de balanceamento, nenhum tráfego está chegando às VMs do backend pool. O engenheiro responsável inspeciona a configuração e coleta os dados abaixo:
az network lb rule show \
--resource-group rg-producao \
--lb-name lb-api \
--name rule-http
{
"backendAddressPool": { "id": "...pools/pool-api-vms" },
"backendPort": 80,
"enableFloatingIp": false,
"frontendPort": 80,
"loadDistribution": "Default",
"probe": null,
"protocol": "Tcp",
"provisioningState": "Succeeded"
}
O engenheiro verifica que as VMs estão em execução, respondem na porta 80 diretamente via IP privado, e o NSG permite tráfego na porta 80 de qualquer origem. O backend pool contém duas VMs com status listado como 0 of 2 instances are serving traffic.
O Load Balancer foi criado há menos de uma hora. Nenhuma outra regra existe neste Load Balancer.
Qual é a causa raiz do problema?
A) O Load Balancer foi criado recentemente e ainda está em processo de provisionamento; o tráfego será encaminhado automaticamente após a propagação completa
B) O campo probe está com valor null na regra de balanceamento, indicando que nenhum health probe foi associado, e o SKU Standard não encaminha tráfego sem probe ativo
C) O loadDistribution definido como Default causa conflito com o backend pool quando há menos de três instâncias disponíveis
D) O protocolo Tcp é incompatível com aplicações HTTP no SKU Standard; o protocolo correto seria Http para tráfego na porta 80
Cenário 4 — Sequência de Diagnóstico
Um engenheiro recebe o seguinte relato: "O Load Balancer Standard público está respondendo na porta 80, mas os clientes relatam que algumas requisições retornam erros HTTP 502 de forma aleatória, enquanto outras são bem-sucedidas."
O engenheiro tem acesso ao portal do Azure, aos logs de diagnóstico do Load Balancer, ao console das VMs e às métricas do backend pool.
Os passos de investigação disponíveis são:
- Verificar o status de saúde de cada instância individualmente nas métricas do backend pool
- Acessar os logs de aplicação em cada VM para identificar erros durante o período de falha
- Confirmar se o health probe está configurado com o protocolo e o path corretos para o endpoint da aplicação
- Verificar nas métricas do Load Balancer se o contador
Health Probe Statusapresenta oscilação por instância - Testar o endpoint de probe diretamente em cada VM a partir de uma máquina na mesma rede
Qual é a sequência correta de investigação?
A) 2 -> 1 -> 4 -> 3 -> 5
B) 3 -> 5 -> 4 -> 1 -> 2
C) 1 -> 4 -> 3 -> 5 -> 2
D) 4 -> 1 -> 3 -> 5 -> 2
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: D
A pista central está na coincidência de tempo: o certificado TLS foi renovado às 23h14, e os problemas começaram logo após. No entanto, a causa não é o certificado em si, pois o acesso direto às VMs funciona normalmente, inclusive o endpoint /healthz. O que muda durante uma renovação de certificado em ambientes automatizados é frequentemente a execução de scripts de automação que podem alterar configurações adjacentes, como regras de NSG.
O health probe do Azure Load Balancer Standard origina tráfego a partir de endereços IP no prefixo 168.63.129.16. Se uma regra de NSG foi alterada durante o processo de renovação e bloqueou esse endereço de origem nas NICs das VMs, os probes falharão sistematicamente, mesmo que a aplicação esteja saudável.
A alternativa C é o distrator mais perigoso: o Load Balancer Standard suporta sim o protocolo HTTPS em health probes. Agir com base nessa hipótese levaria o engenheiro a alterar o probe para HTTP desnecessariamente.
A informação sobre o threshold de 2 falhas (alternativa A) é irrelevante para o diagnóstico, pois o comportamento observado é de todas as instâncias marcadas como degradadas simultaneamente, não de oscilação.
Gabarito — Cenário 2
Resposta: B
O cenário apresenta uma causa já identificada e restrições precisas. A ação correta é aguardar a conclusão do lote em andamento (iniciado há 3 minutos) e realizar a alteração antes da próxima janela de chamada do integrador, que ocorre a cada 5 minutos. Isso minimiza o impacto sobre conexões ativas sem esperar a janela de manutenção, que é desnecessária para uma alteração de configuração de regra de balanceamento.
A alternativa A ignora a restrição crítica: o lote em andamento seria interrompido imediatamente, causando impacto direto em produção sem necessidade.
A alternativa C aplica um processo correto no contexto errado. Aguardar até às 02h00 prolonga a condição de sobrecarga por horas quando uma janela natural de baixo impacto existe em menos de 2 minutos.
A alternativa D é tecnicamente inválida: não é possível ter duas regras de balanceamento para o mesmo frontend IP e porta simultaneamente, e a remoção da regra ativa interromperia o tráfego.
Gabarito — Cenário 3
Resposta: B
O campo "probe": null na saída do comando é a evidência direta e definitiva. No Azure Load Balancer SKU Standard, uma regra de balanceamento sem health probe associado resulta em nenhuma instância do backend pool sendo considerada disponível para receber tráfego. O status 0 of 2 instances are serving traffic confirma exatamente esse comportamento.
O fato de as VMs responderem diretamente e o NSG permitir tráfego são informações relevantes para eliminar outras hipóteses, mas não mudam o diagnóstico, pois o problema está na camada de configuração do Load Balancer, não na conectividade das VMs.
A alternativa A representa o erro de diagnóstico mais perigoso: atribuir o problema ao tempo de provisionamento levaria a uma espera indefinida sem ação corretiva. O provisioningState: Succeeded já confirma que o provisionamento concluiu.
As alternativas C e D são distratores que introduzem restrições inexistentes: loadDistribution: Default não tem relação com o número de instâncias, e o protocolo Tcp é perfeitamente válido para tráfego HTTP no SKU Standard.
Gabarito — Cenário 4
Resposta: C
A sequência correta parte do nível mais agregado e avança progressivamente até o nível mais granular e específico.
O passo 1 (status de saúde por instância) revela imediatamente se o problema é de balanceamento ou de aplicação, estabelecendo o contexto. O passo 4 (métrica Health Probe Status) confirma se o Load Balancer está removendo instâncias do pool ativamente, o que explicaria os erros 502 aleatórios. O passo 3 (verificar configuração do probe) identifica se o probe está testando o endpoint correto. O passo 5 (teste direto do endpoint de probe) valida a hipótese antes de qualquer alteração. O passo 2 (logs de aplicação nas VMs) é o mais granular e só deve ser executado após confirmar que instâncias específicas estão falhando.
A sequência D é o distrator mais plausível, mas inverte a ordem dos passos 4 e 1. Começar pelo Health Probe Status agregado antes de verificar o status individual por instância é menos eficiente, pois a oscilação no agregado já seria visível no status por instância.
Iniciar pelos logs de aplicação (alternativa A) é o erro clássico de ir ao nível mais profundo sem antes confirmar em qual camada o problema ocorre, consumindo tempo desnecessário.
Árvore de Troubleshooting: Implement a load balancing rule
Legenda:
- Azul escuro: sintoma inicial ou ponto de entrada do diagnóstico
- Azul: pergunta diagnóstica com resposta sim ou não
- Laranja: verificação ou coleta de evidência intermediária
- Vermelho: causa identificada
- Verde: ação recomendada ou resolução
Para usar esta árvore diante de um problema real, comece pelo nó raiz e responda cada pergunta com base no que é observável diretamente no portal, na CLI ou nas métricas do Load Balancer. Siga o caminho que corresponde ao estado encontrado, sem pular etapas. Ao atingir um nó vermelho, a causa está identificada; o nó verde imediatamente abaixo indica a ação corretiva. Resista à tentação de ir direto aos logs de aplicação antes de esgotar as verificações de configuração do Load Balancer e do probe, pois a maioria das falhas neste objetivo tem origem na camada de configuração, não na aplicação em si.