Laboratório de Troubleshooting: Manage sizing and scaling for containers, including Azure Container Instances and Azure Container Apps
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Uma equipe de operações reporta que um container group no Azure Container Instances foi implantado com sucesso, mas a aplicação dentro do container encerra após alguns segundos e o container reinicia em loop. O time verificou que a imagem está correta e foi testada localmente sem problemas.
O ambiente possui as seguintes configurações:
{
"name": "processador-relatorios",
"properties": {
"restartPolicy": "Always",
"containers": [
{
"name": "app",
"properties": {
"image": "meuregistry.azurecr.io/processador:v2",
"resources": {
"requests": {
"cpu": 0.5,
"memoryInGB": 0.3
}
},
"environmentVariables": [
{ "name": "ENV", "value": "production" }
]
}
}
]
}
}
O operador executou o seguinte comando para verificar os eventos:
az container show \
--name processador-relatorios \
--resource-group rg-producao \
--query "containers[0].instanceView.events" \
--output table
Saída:
Name Count FirstTimestamp LastTimestamp Message
------- ----- -------------------- -------------------- ----------------------------------
Pulling 1 2024-11-10T10:00:01Z 2024-11-10T10:00:01Z Pulling image from registry
Pulled 1 2024-11-10T10:00:04Z 2024-11-10T10:00:04Z Successfully pulled image
Started 12 2024-11-10T10:00:05Z 2024-11-10T10:04:47Z Started container
Killed 11 2024-11-10T10:00:07Z 2024-11-10T10:04:49Z OOMKilled
O time também informa que a variável ENV=production é necessária e está corretamente configurada. O registro de container está acessível e a imagem foi puxada sem erros.
Qual é a causa raiz do comportamento observado?
A) A imagem está corrompida no registro, pois foi puxada mas o container não consegue inicializar corretamente.
B) A restart policy Always está forçando reinicializações desnecessárias mesmo quando o container encerra normalmente.
C) A quantidade de memória alocada é insuficiente para a aplicação, fazendo com que o kernel encerre o processo por estouro de memória.
D) A variável de ambiente ENV=production está ativando um modo de execução mais pesado que consome mais CPU do que o alocado.
Cenário 2 — Decisão de Ação
A equipe de plataforma identificou a causa de um problema em um ambiente de produção: uma revisão ativa de um Azure Container Apps está com o valor de maxReplicas definido como 2, enquanto a carga atual exige pelo menos 8 réplicas para processar as mensagens dentro do SLA. A regra de escalonamento baseada em KEDA está funcional e os logs confirmam que o escalonador está tentando criar novas réplicas, mas é impedido pelo limite configurado.
O ambiente possui as seguintes restrições:
- A aplicação está em produção e processando transações financeiras ativas
- Alterar a revisão ativa exige a criação de uma nova revisão no modo multiple revisions
- O ambiente está configurado em modo single revision, o que significa que qualquer nova implantação substitui a revisão atual imediatamente
- A equipe tem permissão de
Contributorno resource group - Não há janela de manutenção programada para as próximas 4 horas
Qual é a ação correta a tomar neste momento?
A) Excluir o Container App e reimplantá-lo com maxReplicas: 8, pois o serviço não permite atualização de configuração de escalonamento sem recriação.
B) Atualizar a configuração de escalonamento da revisão ativa via az containerapp update para elevar maxReplicas para 8, sem criar uma nova revisão.
C) Ativar o modo multiple revisions, implantar uma nova revisão com maxReplicas: 8 e migrar o tráfego gradualmente.
D) Aguardar a janela de manutenção para aplicar a alteração, pois modificar configurações de escalonamento em produção sem janela representa risco operacional.
Cenário 3 — Causa Raiz
Um time de engenharia configurou uma aplicação no Azure Container Apps para escalar com base em mensagens em uma fila do Azure Service Bus. Durante a semana, o sistema funcionou corretamente. Na segunda-feira seguinte, após uma atualização de infraestrutura realizada pelo time de segurança, o escalonamento parou de funcionar: a fila acumula mensagens mas nenhuma réplica adicional é criada.
O time de engenharia verificou os seguintes pontos:
- A imagem do container não foi alterada
- A configuração da regra de escalonamento KEDA está idêntica à semana anterior
- O número atual de réplicas está fixo em
1, que é o valor deminReplicas - O Azure Monitor não registra erros de aplicação
- O time de segurança informa que rotacionou os segredos do Key Vault e atualizou as políticas de rede dos recursos
A configuração de escalonamento relevante é:
{
"scale": {
"minReplicas": 1,
"maxReplicas": 10,
"rules": [
{
"name": "servicebus-rule",
"custom": {
"type": "azure-servicebus",
"metadata": {
"queueName": "fila-pedidos",
"messageCount": "5"
},
"auth": [
{
"secretRef": "sb-connection-string",
"triggerParameter": "connection"
}
]
}
}
]
}
}
Qual é a causa raiz do problema?
A) A propriedade messageCount foi descontinuada no KEDA e deve ser substituída por queueLength para que o trigger funcione corretamente.
B) O segredo referenciado em secretRef: sb-connection-string no Container App não foi atualizado após a rotação, fazendo com que o KEDA não consiga autenticar na fila.
C) As políticas de rede atualizadas bloquearam o tráfego de saída do Container App para o Azure Monitor, impedindo a coleta de métricas de escalonamento.
D) O valor de minReplicas: 1 impede o KEDA de criar novas réplicas, pois o escalonador interpreta a réplica existente como carga máxima suportada.
Cenário 4 — Sequência de Diagnóstico
Um operador recebe o seguinte alerta: uma aplicação implantada no Azure Container Apps está respondendo com latência 10 vezes acima do normal durante horários de pico. O operador suspeita de um problema de escalonamento.
Os passos de investigação disponíveis são:
- Passo P: Verificar os logs da aplicação no Log Analytics para identificar erros internos que possam explicar a lentidão independentemente do escalonamento
- Passo Q: Confirmar se o número atual de réplicas ativas está abaixo do valor de
maxReplicasconfigurado - Passo R: Inspecionar a configuração de escalonamento para verificar os valores de
minReplicas,maxReplicase as regras de trigger ativas - Passo S: Verificar as métricas de CPU e memória das réplicas ativas para confirmar se estão saturadas
- Passo T: Testar manualmente o endpoint da aplicação com uma ferramenta de carga para reproduzir o comportamento e confirmar o sintoma
Qual é a sequência correta de investigação?
A) T, S, R, Q, P
B) R, Q, S, P, T
C) T, P, R, S, Q
D) P, T, S, R, Q
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: C
O evento OOMKilled no log de eventos é a pista definitiva. Esse evento indica que o kernel do sistema operacional encerrou o processo do container porque ele tentou utilizar mais memória do que o limite alocado, que neste caso é 0.3 GB (aproximadamente 307 MB). Esse valor é extremamente baixo para uma aplicação de processamento de relatórios em ambiente de produção.
A informação sobre a variável ENV=production é propositalmente irrelevante para o diagnóstico: ela está presente no enunciado para distrair e induzir a alternativa D. O fato de a imagem ter sido puxada com sucesso (evento Pulled) elimina a alternativa A. A restart policy Always (alternativa B) explica por que o container reinicia após ser morto, mas não é a causa do encerramento em si.
O distrator mais perigoso é a alternativa D: um operador menos experiente pode associar ENV=production a um comportamento diferente da aplicação e direcionar o diagnóstico para variáveis de ambiente, ignorando o OOMKilled que está explicitamente nos logs.
Gabarito — Cenário 2
Resposta: B
O Azure Container Apps permite atualizar configurações de escalonamento, incluindo maxReplicas, diretamente via az containerapp update sem necessidade de criar uma nova revisão. No modo single revision, essa atualização é aplicada à revisão ativa imediata e silenciosamente, sem downtime.
A alternativa A está incorreta: o serviço não exige recriação para alterar escalonamento. A alternativa C seria válida em um contexto de implantação gradual ou teste A/B, mas introduz complexidade desnecessária e não é aplicável em modo single revision sem antes alterar o modo do ambiente, o que aumenta o risco em produção. A alternativa D ignora que o problema está causando impacto ativo no SLA agora, tornando a espera injustificável quando existe uma ação segura disponível imediatamente.
A restrição crítica que elimina C é exatamente o modo single revision já ativo: mudar para multiple revisions durante um incidente em produção é uma ação de maior risco do que aplicar az containerapp update diretamente.
Gabarito — Cenário 3
Resposta: B
A pista central está na linha do tempo: o problema começou após a equipe de segurança rotacionar os segredos. A configuração do KEDA referencia o segredo sb-connection-string para autenticar na fila do Service Bus. Quando o segredo é rotacionado no Key Vault ou na string de conexão original, o valor armazenado como secret no Container App fica desatualizado. O KEDA passa a usar uma credencial inválida e não consegue consultar a fila, portanto não detecta mensagens acumuladas e não aciona o escalonamento.
A alternativa A é incorreta: messageCount é um parâmetro válido no scaler do KEDA para Service Bus. A alternativa C é um distrator plausível, mas o Azure Monitor não é o mecanismo pelo qual o KEDA consulta a fila; o KEDA acessa o Service Bus diretamente via conexão autenticada. A alternativa D representa um equívoco sobre como minReplicas funciona: ele define o piso de réplicas, não um limite de carga.
A informação sobre as políticas de rede está presente como dado irrelevante para induzir o diagnóstico à alternativa C. O fato de não haver erros no Azure Monitor reforça que o problema não está na execução da aplicação, mas sim na capacidade do escalonador de observar a fila.
Gabarito — Cenário 4
Resposta: A
A sequência correta é: T, S, R, Q, P.
O raciocínio parte do sintoma observado: alta latência durante pico. O primeiro passo é reproduzir e confirmar o sintoma (T), evitando investigar um problema que pode não estar mais ocorrendo. Em seguida, verificar se as réplicas ativas estão saturadas em CPU e memória (S) confirma se o problema é de capacidade de processamento. Com a saturação confirmada, inspecionar a configuração de escalonamento (R) revela se os parâmetros de trigger e limites estão corretos. Verificar se o número de réplicas está abaixo do maxReplicas (Q) determina se há espaço para escalonamento ou se o teto já foi atingido. Por último, investigar os logs da aplicação (P) cobre a hipótese de que a lentidão tem causa interna, não relacionada a escalonamento.
A sequência B comete o erro de começar pela configuração antes de confirmar o sintoma e o estado das réplicas. As sequências C e D colocam a investigação de logs de aplicação antes de validar as métricas de infraestrutura, o que inverte a prioridade diagnóstica para um problema tipicamente operacional como saturação de réplicas.
Árvore de Troubleshooting: Manage sizing and scaling for containers, including Azure Container Instances and Azure Container Apps
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 | Validação ou verificação intermediária |
Para usar esta árvore diante de um problema real, comece pelo nó raiz identificando o sintoma observado: container encerrando em loop ou ausência de escalonamento. Siga as perguntas fechadas respondendo com o que você consegue observar diretamente, seja via az container show, logs do Log Analytics ou inspeção da configuração do Container App. Cada bifurcação elimina uma classe de causas até chegar ao nó vermelho que nomeia a causa raiz, seguido da ação verde correspondente. Não pule perguntas intermediárias: o distrator mais comum nesses cenários é agir sobre o sintoma mais visível antes de validar a causa real.