Pular para o conteúdo principal

Laboratório de Troubleshooting: Configure HTTP Settings

Cenários de Diagnóstico​

Cenário 1 — Causa Raiz​

Um Application Gateway em produção roteia tráfego para um backend hospedado no Azure App Service. A aplicação funcionava normalmente até que o time de segurança renovou o certificado TLS do App Service, substituindo um certificado emitido por uma CA privada interna por um certificado emitido pela DigiCert. Após a renovação, o gateway passou a retornar HTTP 502 Bad Gateway para todos os usuários.

O time verifica os logs do Application Gateway e encontra a seguinte entrada:

BackendHttpStatusCode: 0
BackendResponseLatency: 0ms
Reason: BackendConnectionError
BackendServer: myapp.azurewebsites.net:443

Durante a investigação, o time observa também que:

  • O SKU do Application Gateway é Standard V2
  • O Request timeout no HTTP Setting está configurado para 20 segundos
  • O HTTP Setting usa protocolo HTTPS na porta 443
  • A opção Use well-known CA certificate está desabilitada
  • Um certificado de autenticação da CA privada anterior ainda está carregado no HTTP Setting
  • O App Service responde normalmente quando acessado diretamente pelo navegador

Qual é a causa raiz do erro 502 observado?

A) O timeout de 20 segundos é insuficiente para estabelecer conexões TLS com o App Service após a renovação do certificado

B) O Application Gateway está tentando validar o certificado do backend usando o certificado da CA privada anterior, que não corresponde ao novo certificado emitido pela DigiCert

C) O SKU Standard V2 não suporta comunicação HTTPS com backends do Azure App Service

D) A renovação do certificado no App Service alterou a porta de escuta de 443 para uma porta não padrão, causando falha de conexão

Cenário 2 — Decisão de Ação​

A equipe de operações identificou a causa de um incidente em produção: o campo Override backend path em um HTTP Setting está configurado com o valor /legacy/, sobrescrevendo o caminho correto que a nova versão da API espera receber. A aplicação retorna HTTP 404 para todas as requisições porque o endpoint /legacy/ foi removido na última implantação.

O contexto do incidente é o seguinte:

  • O Application Gateway está em produção e processa aproximadamente 800 requisições por minuto
  • Não há janela de manutenção programada para as próximas 4 horas
  • A alteração do HTTP Setting causa um breve período de re-provisionamento do gateway, estimado entre 1 e 3 minutos
  • O time possui permissão de escrita no recurso do Application Gateway
  • Um ambiente de staging idêntico está disponível, mas não está recebendo tráfego real no momento
  • O SLA de disponibilidade contratado é de 99,9%

Qual é a ação correta a tomar neste momento?

A) Aplicar a correção do Override backend path imediatamente no ambiente de produção, pois o re-provisionamento de 1 a 3 minutos representa impacto menor do que manter o HTTP 404 ativo

B) Corrigir primeiro no ambiente de staging, validar o comportamento e aguardar a janela de manutenção programada para aplicar em produção

C) Criar um novo HTTP Setting com o caminho correto e associá-lo às regras de roteamento sem remover o HTTP Setting atual, eliminando o re-provisionamento

D) Reverter a implantação da API para restaurar o endpoint /legacy/ enquanto a correção definitiva é planejada com janela de manutenção

Cenário 3 — Causa Raiz​

Uma equipe migrou um conjunto de microsserviços para backends separados no Application Gateway. Cada microsserviço tem seu próprio pool de backend e seu próprio HTTP Setting. Após a migração, o serviço de autenticação começa a apresentar falhas intermitentes, enquanto os demais serviços operam normalmente.

Os logs do Application Gateway para o serviço de autenticação mostram:

BackendHttpStatusCode: 200
BackendResponseLatency: 4200ms
Reason: Timeout
BackendServer: auth-service.internal:8443

O time coleta as seguintes informações adicionais:

  • O HTTP Setting do serviço de autenticação tem Request timeout configurado para 30 segundos
  • O serviço de autenticação realiza consultas a um diretório LDAP externo que, sob carga, pode levar até 45 segundos para responder
  • O Cookie-based affinity está habilitado no HTTP Setting do serviço de autenticação
  • Os demais HTTP Settings têm timeout configurado para 60 segundos
  • O Health probe associado ao HTTP Setting usa o protocolo HTTP, enquanto o backend escuta em HTTPS

O time conclui que o Cookie-based affinity está causando sobrecarga em instâncias específicas do pool. Essa hipótese está correta?

A) Sim, o Cookie-based affinity concentra requisições em instâncias específicas, causando latência elevada e timeouts intermitentes

B) Não. A causa raiz é que o Request timeout de 30 segundos é inferior ao tempo máximo de resposta do backend sob carga, causando o encerramento prematuro das requisições

C) Não. A causa raiz é que o Health probe usa HTTP enquanto o backend escuta em HTTPS, fazendo com que instâncias saudáveis sejam marcadas como indisponíveis

D) Sim. O Cookie-based affinity combinado com HTTPS no backend impede o balanceamento correto entre as instâncias do pool

Cenário 4 — Sequência de Diagnóstico​

Um engenheiro recebe um alerta indicando que o Application Gateway está retornando HTTP 502 para requisições destinadas a um backend específico. O ambiente é composto por um Application Gateway com HTTP Setting configurado para HTTPS na porta 443, uma Custom probe associada e um pool de backend com três instâncias.

Os passos de investigação disponíveis são:

  1. Verificar se as instâncias do pool de backend estão marcadas como Unhealthy na visão de integridade do backend no portal do Azure
  2. Acessar diretamente uma das instâncias do backend pela porta 443 para confirmar se o serviço está respondendo
  3. Verificar o protocolo e o caminho configurados na Custom probe para garantir que coincidem com o que o backend espera receber
  4. Verificar se o certificado TLS do backend é válido e se o Application Gateway está configurado para confiar nele
  5. Revisar os logs de diagnóstico do Application Gateway para identificar o código de erro específico retornado na tentativa de conexão com o backend

Qual é a sequência correta de investigação?

A) 2, 1, 5, 3, 4

B) 1, 5, 2, 3, 4

C) 5, 1, 3, 4, 2

D) 1, 2, 5, 4, 3

Gabarito e Explicações​

Gabarito — Cenário 1​

Resposta: B

Explicação:

  • A pista decisiva está na combinação de dois fatos: o HTTP Setting tem a opção Use well-known CA certificate desabilitada e ainda carrega o certificado da CA privada anterior. Isso significa que o Application Gateway continua tentando validar o certificado do backend contra aquela CA privada, mas o novo certificado do App Service foi emitido pela DigiCert. A validação falha antes mesmo de qualquer dado HTTP ser trocado, resultando em BackendConnectionError com latência zero, exatamente o que os logs mostram.
  • A informação sobre o timeout de 20 segundos é propositalmente irrelevante neste cenário. Quando a falha ocorre na camada TLS antes do estabelecimento da conexão, o timeout de requisição nunca é atingido, o que é confirmado pelo BackendResponseLatency: 0ms.
  • A alternativa C é tecnicamente incorreta: o SKU Standard V2 suporta plenamente HTTPS com App Service.
  • Agir com base na alternativa A (aumentar o timeout) seria o distrator mais perigoso, pois levaria o time a modificar configurações irrelevantes enquanto o 502 persiste.

Gabarito — Cenário 2​

Resposta: A

Explicação:

  • A restrição crítica do cenário é que a aplicação está retornando HTTP 404 para todas as requisições neste exato momento, em produção, com 800 requisições por minuto. Manter o estado atual significa impacto contínuo e mensurável no SLA. O re-provisionamento de 1 a 3 minutos é um impacto finito e controlado, enquanto o 404 é um impacto indefinido e crescente.
  • A alternativa B ignora a restrição mais importante: aguardar 4 horas com 404 ativo é incompatível com o SLA de 99,9%.
  • A alternativa C representa um equívoco técnico relevante: não é possível associar dois HTTP Settings diferentes às mesmas regras simultaneamente de forma atômica; a transição ainda causaria re-provisionamento.
  • A alternativa D é a mais perigosa, pois propõe reverter a aplicação como solução para um problema de configuração do gateway, criando débito técnico e ignorando a causa real.

Gabarito — Cenário 3​

Resposta: B

Explicação:

  • O log mostra BackendResponseLatency: 4200ms com status de Timeout, e a entrada de timeout do HTTP Setting está em 30 segundos. O enunciado informa explicitamente que o backend pode levar até 45 segundos para responder sob carga. A causa é direta: o gateway encerra a conexão antes que o backend conclua o processamento.
  • A hipótese do Cookie-based affinity é o distrator principal e representa um erro de raciocínio clássico: concentrar-se em uma configuração visível e diferente dos demais serviços, ignorando a correlação quantitativa entre o timeout configurado e o tempo de resposta do backend.
  • A alternativa C é plausível em outro contexto, mas o enunciado indica que as falhas são intermitentes e correlacionadas com carga, não com indisponibilidade constante de instâncias, o que afasta a hipótese do probe incorreto como causa raiz neste cenário.
  • A informação sobre os demais HTTP Settings terem timeout de 60 segundos é relevante por contraste, não irrelevante: ela confirma que o timeout de 30 segundos é atipicamente baixo para este ambiente.

Gabarito — Cenário 4​

Resposta: B

Explicação:

  • A sequência correta segue a lógica de diagnóstico progressivo: do mais abrangente para o mais específico, e do sintoma visível para a causa subjacente.
  • Passo 1 (verificar integridade no portal) responde imediatamente à pergunta mais importante: o gateway sabe que o backend está inacessível? Se todas as instâncias estiverem marcadas como Unhealthy, a investigação segue pelo caminho do probe e da conectividade. Se estiverem Healthy, o problema é de configuração de roteamento.
  • Passo 5 (logs de diagnóstico) refina o diagnóstico com o código de erro específico, que distingue falha de TLS, timeout, recusa de conexão ou erro HTTP do backend.
  • Passo 2 (acesso direto ao backend) valida se o problema é do gateway ou do backend em si.
  • Passo 3 (verificar probe) e passo 4 (verificar certificado TLS) são investigações específicas que só fazem sentido após confirmar que o problema está na camada de conectividade entre o gateway e o backend.
  • A alternativa A, ao começar pelo acesso direto ao backend, consome tempo em verificação de infraestrutura antes de sequer confirmar como o gateway está interpretando o estado do pool.

Árvore de Troubleshooting: Configure HTTP Settings​

100%
Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

Legenda de cores:

CorTipo de nó
Azul escuroSintoma inicial (raiz)
AzulPergunta diagnóstica
VermelhoCausa identificada
VerdeAção recomendada ou resolução
LaranjaValidação ou verificação intermediária

Para usar esta árvore diante de um problema real, comece pelo nó raiz identificando o sintoma observado (502 ou 404). Siga a primeira pergunta diagnóstica e responda com o estado observável no ambiente, sem presumir a causa. A cada ramificação, você elimina uma classe de hipóteses e estreita o espaço de diagnóstico. Quando atingir um nó vermelho, a causa está identificada; o nó verde imediatamente seguinte indica a ação corretiva. Os nós laranjas sinalizam que uma verificação intermediária é necessária antes de seguir adiante, evitando ações baseadas em diagnóstico incompleto.