Auto Heal no App Service: Reiniciar Automaticamente em Falhas

Toda aplicação eventualmente trava — um memory leak, uma thread presa, um pico de erro 500 que não se resolve sozinho. A pergunta não é se vai acontecer, é o que a plataforma faz quando acontece às 3h da manhã e ninguém está olhando. O Auto Heal do App Service responde por você: monitora condições específicas e recicla o processo automaticamente, sem esperar um alerta acordar alguém.

Neste guia rápido você vai configurar regras de Auto Heal baseadas em taxa de erro, requisições lentas e uso de memória, e entender o parâmetro que evita reciclagem em loop logo após o start.

Sumário

• Como o Auto Heal funciona
• Configurando as regras via Azure CLI
• Entendendo cada gatilho
• O parâmetro que evita reciclagem em loop
• Validando a configuração
• Quando o Auto Heal não é a solução
• Troubleshooting comum
• Conclusão
• Referências oficiais

Como o Auto Heal funciona

O Auto Heal monitora o processo do worker em busca de condições que você define — quantidade de requisições num intervalo, requisições lentas, códigos de status específicos ou uso de memória privada — e, quando a condição bate, executa uma ação: reciclar o processo (o mais comum), registrar um evento ou disparar uma ação customizada. A configuração vive nas propriedades autoHealEnabled e autoHealRules do site, e dá pra setar direto via CLI sem precisar editar web.config.

Configurando as regras via Azure CLI

O exemplo abaixo recicla o processo se ele acumular 20 respostas HTTP 500 em 5 minutos, ou se 50 requisições levarem mais de 10 segundos no mesmo intervalo:

az webapp config set \
    --name meuapp-prod \
    --resource-group rg-appservice-lab \
    --generic-configurations '{
      "autoHealEnabled": true,
      "autoHealRules": {
        "triggers": {
          "statusCodes": [
            { "status": 500, "count": 20, "timeInterval": "00:05:00" }
          ],
          "slowRequests": {
            "timeTaken": "00:00:10",
            "count": 50,
            "timeInterval": "00:05:00"
          }
        },
        "actions": {
          "actionType": "Recycle",
          "minProcessExecutionTime": "00:01:00"
        }
      }
    }'

Entendendo cada gatilho

O parâmetro que evita reciclagem em loop

Sem o minProcessExecutionTime, uma aplicação com boot lento pode entrar num ciclo vicioso: o Auto Heal recicla porque o app “demorou” a responder, o app reinicia, demora de novo pra subir, e é reciclado outra vez — nunca chega a estabilizar. Esse parâmetro define um tempo mínimo de vida do processo antes de qualquer ação de reciclagem valer, dando espaço pro app terminar de subir:

"actions": {
  "actionType": "Recycle",
  "minProcessExecutionTime": "00:01:00"
}

Um minuto costuma ser um piso seguro pra a maioria dos apps; se a sua aplicação tem cold start mais pesado, vale aumentar esse valor.

Validando a configuração

az webapp config show \
    --name meuapp-prod \
    --resource-group rg-appservice-lab \
    --query "{autoHealEnabled:autoHealEnabled, autoHealRules:autoHealRules}"

Depois de aplicar, os eventos de reciclagem disparados pelo Auto Heal aparecem no Log Stream e no Event Viewer do site (acessível via Kudu), marcados com a origem Auto-Healing — vale acompanhar nos primeiros dias pra calibrar os limiares antes de confiar cegamente na regra.

Quando o Auto Heal não é a solução

Auto Heal trata o sintoma, não a causa. Se um memory leak volta toda semana, reciclar o processo é um curativo, não o tratamento — vale abrir um profiling de memória em paralelo. E se o app depende de estado em memória (sessão local, cache não distribuído), reciclagens frequentes derrubam esse estado junto — nesses casos, mover a sessão pra um cache externo (Redis, por exemplo) antes de habilitar regras agressivas.

Troubleshooting comum

Conclusão

O Auto Heal não substitui investigar a causa raiz de uma instabilidade, mas compra tempo — mantém a aplicação respondendo enquanto a causa real é investigada com calma, em vez de acordar alguém às 3h pra reiniciar manualmente. Combinado com um minProcessExecutionTime bem calibrado, é uma rede de segurança barata pra qualquer App Service em produção.

Referências oficiais

• Monitoramento proativo de falhas e Auto-Healing no App Service (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.