APRENDER. PRATICAR. EVOLUIR.Preparar uma comparação controlada
O laboratório usa NGINX 1.30.5 compilado localmente, um worker e dois servidores HTTP fictícios, A e B, em loopback. Os backends registam método, caminho e corpo recebido. Cada teste de falha tem o seu grupo upstream para não herdar a exclusão causada pelo teste anterior. Esta separação é importante: se A já estiver excluído, um POST pode ir diretamente para B e deixar de testar a proteção pretendida. Antes de interpretar o resultado, identifica configuração, sequência de pedidos e estado inicial de cada grupo.
Ler as duas perspetivas do mesmo pedido
No primeiro GET de falha, A responde 503 e B responde 200. O cliente recebe 200, enquanto o log do proxy conserva upstream_status igual a 503, 200 e os dois endereços pela mesma ordem. Assim, a consulta ficou disponível através de recuperação, mas A não ficou saudável por o estado final ser positivo. Num portal fictício de posições, recolhe também latência e procura por destino. Um indicador global de sucesso pode permanecer bom enquanto cada recuperação acrescenta trabalho e reduz a margem do backend que responde.
Observar a exclusão sem inventar recuperação
O grupo configura A com max_fails=1 e fail_timeout=60s, B como backup e http_503 como condição de retry. O GET seguinte chega apenas a B. O runner observa essa consequência imediata, mas não espera a reentrada de A. Registar “recuperação automática validada” excederia a evidência. A pergunta operacional seguinte é verificar quando A volta a ser escolhido e se consegue executar a consulta funcional. O estado passivo também não representa restart da aplicação, check periódico ou prova de que todas as dependências estão novamente disponíveis.
Comparar POST protegido e repetição explícita
Dois grupos independentes recebem o mesmo corpo sintético. Sem non_idempotent, A recebe o POST e devolve 503; B não o recebe. No outro grupo, a opção permite repetir e os eventos mostram o corpo em A e B, terminando com 200. Os servidores apenas registam receções e respondem, sem implementar movimentos financeiros. Logo, foram observadas duas receções HTTP, não dois movimentos nem execução única. Para uma API real, revê identificadores, efeitos persistidos e reconciliação antes de transformar este resultado numa política de retry.
Contar tentativas e delimitar a distribuição
Num terceiro grupo de falha, proxy_next_upstream_tries 1 permite observar só A, com resposta final 503. Neste ensaio, um significa uma tentativa total, não uma adicional. Um teste separado envia oito GET curtos com pesos três para A e um para B, obtendo seis respostas de A e duas de B. Isto confirma a distribuição dessa amostra controlada. Não mede capacidade máxima, concorrência, sessões longas ou comportamento quando um destino fica inelegível. Mantém o cálculo de participação separado de qualquer compromisso de capacidade em produção.
Aplicar o diagnóstico numa reunião de incidente
Num incidente fictício, o gestor vê os 200 finais e pergunta se pode encerrar. Explica a sequência A503, B200, a exclusão observada e o que falta provar sobre recuperação. Propõe avaliar capacidade restante e conter a instância com falha sem provocar uma cascata. Entrega os eventos ordenados, a configuração e os limites do ensaio. O resumo é distinguir disponibilidade recuperada de saúde de cada destino, receção HTTP de efeito de negócio e distribuição de capacidade. Usa as perguntas para decidir que evidência recolher antes da próxima alteração.
# Synthetic local observations in content/labs/lb-upstream/evidence.json
# retryThenExclusion: A -> B; next request B only
# attemptLogs: upstreamStatus "503, 200" then "200"
# postGuard: A only; explicitReplay: A and B
# attemptLimit: tries=1, one observed backend attemptCaso fictício: as consultas terminam em B depois de 503 em A. A equipa mantém o incidente aberto, confirma capacidade restante e investiga A usando a sequência de tentativas.
Armadilhas comuns
Confundir 200 final com todos os destinos saudáveis, max_fails com restart, receção com efeito e oito pedidos sequenciais com um teste de carga.
Tópicos relacionados: Health checks e prontidão · Retries, limites e origem do cliente · Retirada, release e operação
Reconstrói estados e destinos por tentativa antes de concluir saúde, recuperação ou segurança de uma repetição. O laboratório delimita exatamente o que foi observado.
Referência: NGINX HTTP proxy module · DR load balancing 2026-09; selected NGINX, HAProxy 3.2, Kubernetes and AWS ALB behavior