Laboratório de Troubleshooting: Configure scaling for an App Service plan
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Uma aplicação web em produção está hospedada em um App Service plan Standard S2 na região East US. A equipe de operações configurou autoscale há duas semanas sem problemas. Na última segunda-feira, após um pico de tráfego, o time recebeu alertas de lentidão. Ao investigar, encontraram o seguinte no histórico de atividade do autoscale:
[2026-03-23 14:02] Autoscale evaluation triggered
[2026-03-23 14:02] Current instances: 3
[2026-03-23 14:02] Metric: CpuPercentage = 82%
[2026-03-23 14:02] Rule matched: scale out (threshold: 75%)
[2026-03-23 14:02] Maximum instance count reached: 3
[2026-03-23 14:02] Scale out action skipped
[2026-03-23 14:07] Autoscale evaluation triggered
[2026-03-23 14:07] Current instances: 3
[2026-03-23 14:07] Metric: CpuPercentage = 88%
[2026-03-23 14:07] Rule matched: scale out (threshold: 75%)
[2026-03-23 14:07] Maximum instance count reached: 3
[2026-03-23 14:07] Scale out action skipped
O administrador informa ainda que o plano foi migrado de S1 para S2 três dias antes do incidente, e que nenhuma outra configuração foi alterada no processo. A assinatura do Azure não apresenta alertas de cota.
Qual é a causa raiz da incapacidade de escalonamento horizontal durante o pico?
A) A migração de S1 para S2 reiniciou as regras de autoscale, que voltaram para os valores padrão de máximo 1 instância.
B) O perfil de autoscale tem o limite máximo de instâncias configurado como 3, impedindo novas adições independentemente da carga.
C) O período de cool down entre avaliações está muito curto, fazendo com que ações consecutivas sejam suprimidas antes de atingir o máximo real.
D) O tier S2 possui um limite de plataforma inferior ao S1 em termos de instâncias simultâneas suportadas por autoscale.
Cenário 2 — Decisão de Ação
A equipe de plataforma identificou que um App Service plan em produção está com autoscale configurado corretamente, mas as instâncias demoram cerca de 8 a 10 minutos para ficarem totalmente operacionais após um evento de scale out. Durante esse intervalo, a aplicação apresenta aumento de latência e erros HTTP 503.
A causa foi identificada: a aplicação realiza inicialização pesada no startup, carregando grandes volumes de dados em cache e estabelecendo conexões com múltiplos serviços externos. O ambiente usa plano Premium P2v3, com mínimo de 1 instância e máximo de 5.
São 11h de uma terça-feira. O sistema está em horário de pico. A equipe não tem acesso ao código da aplicação neste momento e não pode alterar a lógica de inicialização.
Qual é a ação correta a tomar agora?
A) Reduzir o threshold de CPU da regra de scale out de 70% para 40%, para que o escalonamento seja acionado antes da saturação e as instâncias fiquem prontas a tempo.
B) Habilitar o Always On no App Service para garantir que as instâncias existentes nunca sejam desligadas durante o período de pico.
C) Aumentar o número mínimo de instâncias no perfil de autoscale para um valor que cubra a demanda de pico sem depender de scale out reativo.
D) Configurar um perfil recorrente de autoscale para os horários de pico com mínimo de instâncias elevado, aplicável a partir do dia seguinte.
Cenário 3 — Causa Raiz
Um administrador recebe um chamado relatando que o portal do Azure não exibe a opção de Scale out (App Service plan) para uma aplicação específica. O administrador verifica a configuração e coleta as seguintes informações:
App Service plan: myapp-plan
Tier: Basic B2
Region: Brazil South
OS: Windows
Runtime: .NET 8
Instances: 1
O administrador nota também que a aplicação tem o Application Insights habilitado e que os logs de diagnóstico estão sendo enviados para um Log Analytics Workspace. Ele verifica se há algum lock de recurso na assinatura e não encontra nenhum. A conta utilizada tem a role Contributor no grupo de recursos.
Qual é a causa raiz da ausência da opção de scale out com autoscale?
A) A ausência de um Diagnostic Settings com destino a Storage Account impede a coleta de métricas necessárias para o autoscale.
B) O App Service plan está no tier Basic, que suporta escalonamento horizontal manual mas não suporta autoscale baseado em regras e métricas.
C) A região Brazil South possui restrições de capacidade que desabilitam o autoscale para planos de tier Basic e Standard.
D) A role Contributor não possui permissão suficiente para visualizar ou configurar autoscale em App Service plans.
Cenário 4 — Impacto Colateral
Um administrador identifica que o App Service plan de produção está constantemente no limite máximo de instâncias (5 de 5) durante o horário comercial, sem jamais escalar para baixo. A regra de scale in está configurada da seguinte forma:
Métrica: CPU Percentage
Operador: Less than
Threshold: 30%
Duration: 10 minutes
Action: Decrease count by 1
Cool down: 20 minutes
Após investigação, o administrador conclui que o threshold de scale in está alto demais para o padrão de uso da aplicação, que raramente cai abaixo de 40% de CPU mesmo com baixo tráfego. Para resolver, ele ajusta o threshold de scale in de 30% para 50%.
A aplicação não tem estado local em disco. O time aprova a mudança.
Qual consequência secundária essa alteração pode causar?
A) O autoscale passará a escalar para dentro com mais frequência, o que pode causar flapping se a CPU oscilar em torno de 50% durante períodos de carga moderada.
B) A regra de scale out deixará de funcionar corretamente porque as regras de scale in e scale out compartilham o mesmo threshold de avaliação internamente.
C) O cool down de 20 minutos será ignorado após a alteração do threshold, pois mudanças na regra reiniciam o ciclo de avaliação do autoscale.
D) O número mínimo de instâncias será automaticamente recalculado pelo autoscale com base no novo threshold, podendo reduzir o piso de instâncias abaixo do valor configurado.
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
O log é conclusivo: em ambas as avaliações, a mensagem Maximum instance count reached: 3 aparece explicitamente como razão para o bloqueio da ação. O autoscale detectou a necessidade de escalar, a regra foi correspondida, mas o limite máximo do perfil impediu a execução.
A pista decisiva está no log, não nas informações contextuais. A migração de S1 para S2 e a ausência de alertas de cota são informações irrelevantes propositalmente incluídas. A migração de tier não redefine configurações de autoscale, e a cota da assinatura não foi apontada como limitante nos logs.
O distrator C representa o erro de diagnóstico mais perigoso: confundir o comportamento do cool down com o bloqueio por limite máximo. O cool down controla o intervalo entre ações, mas os logs mostram avaliações em intervalos de 5 minutos sem nenhuma ação sendo executada, o que é consistente com bloqueio por limite, não por cool down ativo.
A consequência de agir com base no distrator C seria ajustar o cool down sem resolver o problema real, desperdiçando tempo enquanto a aplicação permanece degradada.
Gabarito — Cenário 2
Resposta: C
A causa é conhecida e não pode ser corrigida na origem (o código). O problema é que o scale out reativo sempre chegará tarde porque as instâncias demoram 8 a 10 minutos para ficar prontas. A única solução disponível dentro das restrições é garantir que instâncias suficientes já estejam rodando antes do pico, elevando o mínimo de instâncias no perfil.
A alternativa A é uma ação válida em geral, mas não resolve o problema de atraso de inicialização: mesmo acionando o scale out mais cedo, a instância ainda levará 8 a 10 minutos para estar pronta.
A alternativa D seria a solução correta em condições normais para picos previsíveis, mas a restrição de tempo é crítica: são 11h de um dia de pico ativo. Um perfil recorrente aplicável "a partir do dia seguinte" não resolve o problema imediato.
A alternativa B confunde conceitos: Always On mantém a aplicação aquecida em instâncias existentes, mas não afeta o tempo de inicialização de novas instâncias criadas pelo scale out.
Gabarito — Cenário 3
Resposta: B
O tier Basic suporta escalonamento horizontal, mas apenas de forma manual, sem suporte a autoscale baseado em regras e métricas. A opção de configurar regras de autoscale só está disponível a partir do tier Standard.
As informações sobre Application Insights, Log Analytics e locks de recurso são irrelevantes e foram incluídas para induzir o leitor a investigar caminhos de diagnóstico incorretos. A coleta de métricas pelo Application Insights não tem relação com a disponibilidade da funcionalidade de autoscale no portal.
O distrator A representa um erro clássico de correlação falsa: associar a ausência de um destino de diagnóstico específico com a indisponibilidade de uma funcionalidade que, na verdade, é restrita por tier.
O distrator D é tecnicamente falso: a role Contributor possui permissão completa para configurar autoscale. A ausência da opção no portal é determinada pelo tier do plano, não por RBAC.
Agir com base no distrator A levaria o administrador a configurar Diagnostic Settings desnecessários sem resolver o problema real, e possivelmente abrir um chamado de suporte desnecessário.
Gabarito — Cenário 4
Resposta: A
Aumentar o threshold de scale in de 30% para 50% faz com que a condição de redução de instâncias seja ativada com muito mais frequência, já que a CPU da aplicação costuma ficar entre 40% e 60% em carga moderada. Isso pode criar um ciclo de flapping: o autoscale reduz instâncias quando a CPU cai abaixo de 50%, a carga se redistribui e a CPU sobe novamente, acionando o scale out, e o ciclo se repete.
As alternativas B, C e D descrevem comportamentos que não existem no Azure Autoscale:
- Regras de scale in e scale out são independentes e possuem thresholds separados que não se influenciam.
- Alterar o threshold de uma regra não reinicia o ciclo de avaliação nem afeta o cool down em andamento.
- O número mínimo de instâncias é uma configuração explícita do perfil e nunca é recalculada automaticamente pelo mecanismo de autoscale.
O impacto real do flapping vai além do custo: instâncias sendo criadas e destruídas em ciclos rápidos podem causar instabilidade em conexões de longa duração e degradar a experiência do usuário, mesmo que a aplicação não tenha estado local.
Árvore de Troubleshooting: Configure scaling for an App Service plan
Legenda de cores:
| Cor | Tipo de nó |
|---|---|
| Azul escuro | Sintoma inicial (ponto de entrada) |
| Azul médio | Pergunta diagnóstica |
| Vermelho | Causa identificada |
| Verde | Ação recomendada ou resolução |
| Laranja | Verificação ou validação intermediária |
Para usar esta árvore diante de um problema real, comece pelo nó raiz identificando o sintoma observado. A cada nó de pergunta, responda com base no que é verificável diretamente no portal do Azure ou nos logs de atividade. Siga o caminho correspondente à resposta até alcançar um nó de causa ou ação. Nos nós de validação em laranja, colete as evidências indicadas antes de prosseguir para a próxima ramificação. Nunca pule etapas de verificação intermediária, pois sintomas idênticos podem ter causas distintas dependendo do caminho percorrido.