No post anterior, contei como diagnosticamos e resolvemos SNAT Port Exhaustion implementando NAT Gateway com VNet Integration. Foi uma vitória. Os timeouts sumiram, os usuários pararam de reclamar, e seguimos em frente.

Algumas semanas de paz. Até que o alerta voltou.

SNAT Connection Failed Count apareceu novamente no Azure Monitor. Não com a mesma intensidade de antes, mas estava lá. Intermitente, teimoso.

Se você já passou por isso — resolver um problema e vê-lo voltar — sabe a frustração. Será que o NAT Gateway não funcionou? Será que tem algo errado na configuração?

A Investigação

Minha primeira reação foi duvidar da solução. Será que o WEBSITE_VNET_ROUTE_ALL=1 estava configurado corretamente? Será que o NAT Gateway estava associado à subnet certa?

Verifiquei tudo. Configuração perfeita.

Então fui para as métricas. No Azure Monitor, acessei as métricas do App Service e adicionei SNAT Connection Failed Count. Os erros estavam lá, mas algo não batia: o volume era muito menor do que antes.

Foi quando lembrei de uma funcionalidade que raramente uso: Split by Instance.

No gráfico de métricas, cliquei em Apply splitting → Instance. E ali estava a resposta.

De duas instâncias rodando, apenas uma estava gerando erros SNAT. A outra estava completamente limpa.

"O problema não é o NAT Gateway. O problema é uma instância específica."

BINGO.

O Teste: Escalando para Isolar

Antes de agir, precisávamos ter certeza. Uma instância com problema poderia ser coincidência — talvez ela estivesse recebendo mais tráfego, talvez houvesse algo específico nas requisições que ela processava.

Decidimos escalar de 2 para 4 instâncias. Não por capacidade, mas por diagnóstico.

Aguardamos alguns minutos para as novas instâncias entrarem em operação e começarem a receber tráfego.

Voltamos ao Azure Monitor com o split por instância. O resultado foi claro:

• 3 instâncias: zero erros SNAT
• 1 instância: continuava falhando

Não era o código. Não era a configuração. Era a instância.

Por que uma instância pode falhar isoladamente?

Cada instância do App Service roda em uma VM (ou container, no caso de Linux) na infraestrutura do Azure. Embora o Azure abstraia isso de nós, essas VMs são máquinas reais com componentes reais que podem apresentar problemas:

• Problemas de conectividade de rede no host subjacente
• Configuração de rede corrompida no container
• Estado inconsistente após uma atualização de plataforma
• Problemas no roteamento para o NAT Gateway através da VNet

O NAT Gateway estava funcionando perfeitamente — para as instâncias que conseguiam rotear corretamente até ele. A instância problemática, por algum motivo, não estava conseguindo utilizar o NAT Gateway corretamente, caindo de volta no pool SNAT limitado.

A Solução: Repair no App Service Linux

O App Service Linux tem uma funcionalidade poderosa e pouco conhecida: o Repair (ou Linux Repair em algumas documentações).

Diferente de um simples Restart, que apenas reinicia sua aplicação, o Repair substitui a infraestrutura subjacente — o container e potencialmente o host onde sua instância roda.

Como usar o Repair

1. No portal do Azure, acesse seu App Service
2. No menu lateral, clique em Diagnose and solve problems
3. Na barra de pesquisa, digite "Repair"
4. Selecione Linux Repair nos resultados
5. O Azure mostrará as instâncias disponíveis — selecione a instância problemática
6. Clique em Repair e confirme

O processo leva alguns minutos. O Azure irá:

• Criar uma nova infraestrutura para a instância
• Migrar sua aplicação para a nova infraestrutura
• Remover a infraestrutura antiga

Durante o processo, as outras instâncias continuam operando normalmente, então não há downtime para seus usuários (desde que você tenha mais de uma instância).

Alternativa: Reiniciar instância específica

Se você preferir tentar um restart antes do repair, pode reiniciar uma instância específica via REST API ou usando o Advanced Tools (Kudu). Mas na nossa experiência, quando o problema é de infraestrutura, o Repair é mais efetivo porque substitui o ambiente completamente.

Para referência, veja como reiniciar instâncias específicas:

• How to restart Azure App Service instance — Discussão no Stack Overflow sobre métodos de reinício

O Resultado

Após executar o Repair na instância problemática, voltamos ao Azure Monitor.

SNAT Connection Failed Count: 0

Desde então, nenhuma falha SNAT ocorreu. A nova instância está roteando corretamente através do NAT Gateway, como deveria.

Após confirmar a estabilidade, reduzimos o scale de volta para o número de instâncias adequado para nossa carga.

Lições Aprendidas

1. A infraestrutura também pode ser a culpada. Quando código e configuração estão corretos, considere que o problema pode estar na camada que você não controla — o host, o container, a rede subjacente.

2. Métricas por instância revelam problemas escondidos. Sempre use Split by Instance quando estiver investigando problemas intermitentes. Uma média saudável pode esconder uma instância doente.

3. Escalar pode ser ferramenta de diagnóstico. Às vezes você escala não por capacidade, mas para isolar e confirmar onde está o problema.

4. Repair > Restart para problemas persistentes. Se um restart não resolve, o Repair substitui a infraestrutura completa. É mais invasivo, mas mais efetivo para problemas de plataforma.

Referências

Para se aprofundar no tema:

Diagnóstico por Instância

• Troubleshoot instance-related issues on Azure App Service — Guia oficial para diagnosticar problemas específicos de instância

App Service Linux

• FAQs for App Service on Linux — Perguntas frequentes incluindo informações sobre Repair

Reinício de Instâncias

• How to restart Azure App Service instance — Discussão sobre métodos para reiniciar instâncias específicas

Post Anterior

• O Timeout que funcionava na minha máquina: como diagnosticamos SNAT Port Exhaustion no Azure — Parte 1: diagnóstico e solução com NAT Gateway

Já teve problemas com instâncias específicas do App Service? O Repair resolveu? Compartilhe sua experiência nos comentários.