Health Check Path no App Service com Múltiplas Instâncias

Com mais de uma instância, o App Service já faz balanceamento de carga — mas, sem um Health Check Path configurado, ele só sabe se o processo está de pé, não se a aplicação está de fato respondendo. Uma instância travada (deadlock, pool de conexão esgotado) continua recebendo tráfego normalmente até você notar pelos logs — e por essa altura já é cliente reclamando.

Neste guia rápido você vai configurar um endpoint de health check, entender como o App Service decide remover uma instância de rotação e ajustar a tolerância a falhas via app setting.

Sumário

• Pré-requisito: por que só faz sentido com 2+ instâncias
• O que o endpoint de health check precisa fazer
• Configurando via Azure CLI
• Como a exclusão de instâncias funciona
• Ajustando a tolerância a falhas
• Troubleshooting comum
• Conclusão
• Referências oficiais

Pré-requisito: por que só faz sentido com 2+ instâncias

Com uma única instância, não existe pra onde redirecionar o tráfego — o health check ainda funciona (e reporta o status), mas não tem efeito prático de balanceamento. O ganho real do Health Check Path aparece a partir de 2 instâncias, quando o App Service passa a ter escolha de rota.

O que o endpoint de health check precisa fazer

O endpoint deve retornar HTTP 200 quando a aplicação está saudável, e qualquer coisa diferente (erro 4xx/5xx, timeout) quando não está. A recomendação é ir além de um “hello world” estático — validar dependências críticas de verdade, como a conexão com o banco:

# Exemplo conceitual de handler (pseudo-código), não literal de nenhum framework:
GET /health
  → testa conexão com o banco (timeout curto, ex: 2s)
  → testa dependência crítica (ex: cache)
  → 200 OK se tudo passou
  → 503 Service Unavailable se algo falhou

Evite, porém, checar dependências não-críticas nesse endpoint — se um serviço de terceiro não essencial cair e isso derrubar o health check de todas as instâncias, você tira a aplicação inteira do ar por uma dependência que talvez nem devesse bloquear o funcionamento.

Configurando via Azure CLI

az webapp config set \
    --name meuapp-prod \
    --resource-group rg-appservice-lab \
    --generic-configurations '{"healthCheckPath": "/health"}'

Não precisa de mais nada — a partir daqui, cada instância passa a ser testada nesse caminho periodicamente pelo próprio App Service, sem depender de um serviço de monitoramento externo.

Como o Health Check Path decide excluir uma instância

Cada instância é verificada individualmente. Depois de falhar pings consecutivos além do limite configurado, ela é marcada como não saudável e retirada da rotação de tráfego — sem afetar as instâncias saudáveis. Se a instância voltar a responder normalmente, ela reentra na rotação sozinha, sem precisar de intervenção manual.

Ajustando a tolerância a falhas

Por padrão, uma instância precisa acumular 10 falhas consecutivas de ping antes de ser considerada não saudável. Pra aplicações mais sensíveis (ou mais tolerantes), esse número é ajustável via app setting, aceitando de 1 a 100:

az webapp config appsettings set \
    --name meuapp-prod \
    --resource-group rg-appservice-lab \
    --settings WEBSITE_HEALTHCHECK_MAXPINGFAILURES=4

Baixar esse número reage mais rápido a uma instância ruim, mas aumenta o risco de falso positivo (remover uma instância só porque teve uma lentidão pontual). Subir o número dá mais tolerância a picos passageiros, ao custo de deixar uma instância ruim recebendo tráfego por mais tempo.

Não existe valor certo universal pro Health Check Path — o ponto de partida razoável é o padrão (10 falhas) e ajustar só depois de observar o comportamento real da aplicação por alguns dias, em vez de adivinhar um número na primeira configuração.

Troubleshooting comum

Conclusão

Um Health Check Path bem calibrado transforma o App Service de “sempre manda tráfego pra qualquer instância viva” em “só manda tráfego pra quem está de fato funcionando” — e isso só custa um endpoint e uma linha de configuração. Combinado com o Auto Heal do artigo anterior, você fecha o ciclo: instância travada sai de rotação pelo health check, e o Auto Heal cuida de reciclar o processo problemático.

Referências oficiais

• Monitorar instâncias do App Service com Health Check (Microsoft Learn)
• az webapp config — referência da CLI (Microsoft Learn)

Interessado em saber mais sobre artigos relacionados ao Microsoft Azure CLIQUE AQUI

Este guia técnico é exclusivo do Blog do Castilho. Explore mais conteúdos sobre Cloud e DevOps.