O Que É um Health Check? Explicado
Um health check é uma sonda periódica que testa se um serviço está funcionando, para que o sistema possa contornar ou reiniciar qualquer coisa que não esteja.
Sistemas distribuídos precisam saber quais de suas partes estão funcionando. Um health check responde isso automaticamente: ele sonda um serviço, interpreta a resposta e permite que a plataforma aja, enviando tráfego apenas para instâncias saudáveis e recuperando as não saudáveis. A mesma ideia importa em CI quando jobs dependem de service containers.
O que um health check faz
Um health check envia uma requisição, uma chamada HTTP, uma conexão TCP ou um comando, e decide se o serviço está saudável a partir do resultado. Se ele passa repetidamente, o serviço é considerado no ar; se falha, a plataforma para de confiar naquela instância e toma uma ação corretiva.
Liveness vs readiness
Dois tipos são comuns. Um check de liveness pergunta "este processo está vivo, ou travado e precisando de um restart?" Um check de readiness pergunta "esta instância já está pronta para receber tráfego?" Eles respondem perguntas diferentes, e confundi-los causa loops de restart ou tráfego enviado para serviços que não estão prontos.
Por que importa em CI
Jobs frequentemente sobem service containers, um banco de dados, um cache, um message broker, e então rodam testes contra eles. Se o teste começa antes de o serviço estar saudável, você tem uma falha instável, por condição de corrida. Um health check pelo qual o job espera remove essa corrida ao garantir que a dependência esteja pronta primeiro.
Projetando bons checks
- Faça o check barato e rápido para que ele não adicione carga ou latência.
- Verifique a readiness real (ele consegue atender?), não apenas que a porta está aberta.
- Defina thresholds sensatos para que um único soluço não faça o serviço oscilar.
- Espere pela readiness antes de rodar steps de teste dependentes.
O ângulo Latchkey
Health checks fazem parte de como você escreve jobs resilientes, e combinam bem com infraestrutura de autocorreção. Quando uma falha transitória ainda escapa, os managed runners de autocorreção da Latchkey automaticamente fazem retry, para que um soluço pontual, como um serviço que ficou brevemente lento para subir, não quebre seu build.
Principais conclusões
- Um health check sonda se um serviço está funcionando.
- Liveness pergunta se um processo está vivo; readiness pergunta se ele pode atender tráfego.
- Esperar pela readiness evita flakiness por condição de corrida em CI.
- Bons checks são baratos, reais e têm thresholds sensatos.