APRENDER. PRATICAR. EVOLUIR.Conceito e mecanismo
Um check TCP mostra que uma ligação pode ser aberta; não executa automaticamente uma consulta funcional. Um check HTTP também pode ser demasiado superficial se só observar uma página estática. Define critérios representativos e baratos, evitando que a própria monitorização agrave sobrecarga. Health checking passivo usa resultados do tráfego real; mecanismos ativos executam observações periódicas próprias. Em NGINX, max_fails e fail_timeout num grupo com vários servidores participam na contagem e exclusão temporária conforme as condições configuradas. Não os confundas com um prazo total do pedido ou com toda a funcionalidade de checks ativos, cuja disponibilidade depende da edição e implementação.
Aplicação guiada
Em Kubernetes, readiness controla prontidão para tráfego regular; liveness pode desencadear restart. Falhar liveness por indisponibilidade de uma dependência partilhada pode reiniciar muitas instâncias sem resolver a causa. Startup probes dão margem a uma inicialização normal antes de liveness e readiness. Critérios e tolerâncias devem refletir o serviço observado. A consequência de todos os destinos falharem também varia: AWS ALB documenta fail-open quando todos os targets estão unhealthy em todas as zonas ativadas. Não assumes ausência total de tráfego só pelo rótulo. Num exercício, contém o backend que falha consultas, confirma capacidade restante e corrige o check que não detetava essa incapacidade.
Uma porta aberta não prova consulta funcional; unhealthy no ALB não garante isolamento quando todos falham.
Armadilhas comuns
Check como prova de todas as dependências; liveness como readiness; falha externa como restart universal; estado como semântica universal.
Tópicos relacionados: Encaminhamento e fronteiras TLS · Algoritmos, afinidade e estado · Retries, limites e origem do cliente
Liga cada check a uma hipótese concreta e a uma reação conhecida.
Referência: Kubernetes startup, liveness and readiness probes · DR load balancing 2026-09; selected NGINX, HAProxy 3.2, Kubernetes and AWS ALB behavior