Pular para o conteúdo principal

Laboratório de Troubleshooting: Implement Azure Traffic Manager

Cenários de Diagnóstico​

Cenário 1 — Causa Raiz​

A equipe de operações recebeu um alerta às 14h32 informando que o endpoint api-westeurope foi marcado como Degraded no perfil do Traffic Manager. O perfil utiliza o método de roteamento Performance e possui três endpoints ativos. O SLA do serviço exige disponibilidade de 99,9%.

O engenheiro de plantão verificou o seguinte no portal:

Perfil: tm-api-global.trafficmanager.net
Método: Performance
Protocolo de probe: HTTPS
Porta: 443
Caminho: /health
Intervalo de probe: 30 segundos
Tolerância a falhas: 3
Tempo limite por probe: 10 segundos

Status dos endpoints:
  api-eastus        → Online
  api-westeurope    → Degraded
  api-southeastasia → Online

O engenheiro acessou https://api-westeurope.azurewebsites.net/health diretamente pelo navegador e recebeu HTTP 200. O endpoint respondeu em 180 ms. A equipe de infraestrutura confirmou que não houve nenhuma alteração de configuração no App Service nas últimas 6 horas. O certificado TLS do endpoint está válido por mais 11 meses.

Qual é a causa raiz mais provável para o endpoint estar marcado como Degraded?

A) O certificado TLS do endpoint está configurado incorretamente e o probe HTTPS rejeita a conexão por falha de handshake
B) O tempo limite de 10 segundos por probe é insuficiente para a latência entre os servidores de probe da Microsoft e a região West Europe
C) A rota /health retorna HTTP 200 no navegador, mas retorna um código diferente quando acessada pelos agentes de probe do Traffic Manager
D) O método Performance não é compatível com probes HTTPS em endpoints do tipo App Service

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

A causa de uma interrupção foi identificada: o perfil do Traffic Manager tem o TTL configurado em 300 segundos e um endpoint crítico ficou indisponível. O Traffic Manager removeu o endpoint corretamente da rotação, mas usuários em diversas regiões continuaram recebendo erros por até 5 minutos após a remoção, pois seus resolvers DNS ainda tinham o registro em cache.

A equipe concluiu que o TTL precisa ser reduzido. O ambiente possui as seguintes restrições:

  • O perfil está em produção e atende a 40.000 requisições por minuto
  • A equipe de DNS corporativo alertou que valores de TTL muito baixos aumentam significativamente a carga nos resolvers e no próprio Traffic Manager
  • O objetivo é reduzir o tempo de propagação de failover sem comprometer a estabilidade do serviço
  • Uma janela de manutenção está disponível em 48 horas

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

A) Reduzir o TTL para 0 imediatamente, pois elimina o problema de cache de DNS sem necessidade de janela de manutenção
B) Aguardar a janela de manutenção e reduzir o TTL gradualmente, avaliando o impacto na carga de resolução antes de definir o valor final
C) Substituir o Traffic Manager pelo Azure Front Door, que não depende de TTL de DNS para roteamento
D) Manter o TTL em 300 segundos e compensar reduzindo o intervalo de probe para 10 segundos, acelerando a detecção da falha

Cenário 3 — Causa Raiz​

Um desenvolvedor reportou que, ao testar o comportamento de failover do Traffic Manager, percebeu que usuários em São Paulo continuam sendo direcionados para o endpoint app-brazil mesmo após ele ter sido desativado manualmente no portal há 20 minutos. O perfil utiliza o método Geographic com o Brasil mapeado para app-brazil.

O seguinte teste foi executado em uma máquina na rede corporativa em São Paulo:

$ nslookup tm-app.trafficmanager.net
Server:  10.0.0.1
Address: 10.0.0.1#53

Non-authoritative answer:
Name:    tm-app.trafficmanager.net
Address: 20.201.28.100

O endereço 20.201.28.100 corresponde ao IP público do endpoint app-brazil. O desenvolvedor confirma que o status do endpoint no portal está como Disabled. O TTL do perfil está configurado em 60 segundos. A equipe de rede informa que o resolver DNS interno (10.0.0.1) tem um cache de TTL fixo de 1800 segundos, independentemente do valor declarado no registro.

Qual é a causa raiz do comportamento observado?

A) O método Geographic não respeita desativações manuais de endpoint; ele exige que o endpoint falhe no health check para ser removido da rotação
B) O resolver DNS interno está ignorando o TTL declarado pelo Traffic Manager e mantendo o registro em cache por 1800 segundos
C) O TTL de 60 segundos no perfil é insuficiente para o método Geographic e deveria ser de no mínimo 300 segundos
D) O Traffic Manager leva até 30 minutos para propagar mudanças de estado de endpoint para regiões fora dos Estados Unidos

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

Um engenheiro recebeu o seguinte relato: usuários na Europa estão sendo direcionados para um endpoint nos Estados Unidos, mesmo com um endpoint em West Europe configurado no perfil e marcado como Online. O perfil utiliza o método Performance.

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

  1. Verificar se o endpoint de West Europe está respondendo ao path de probe com HTTP 200
  2. Confirmar o método de roteamento configurado no perfil do Traffic Manager
  3. Comparar a tabela de latência da Microsoft para os IPs de origem dos usuários europeus
  4. Verificar o status do endpoint de West Europe no portal (Online, Degraded ou Disabled)
  5. Testar a resolução DNS a partir de um cliente europeu usando nslookup ou dig

Qual é a sequência de diagnóstico mais lógica e eficiente?

A) 2 → 4 → 1 → 5 → 3
B) 5 → 4 → 1 → 2 → 3
C) 4 → 1 → 2 → 5 → 3
D) 2 → 5 → 4 → 1 → 3

Gabarito e Explicações​

Gabarito — Cenário 1​

Resposta: C

A pista decisiva no enunciado é a combinação de dois fatos: o endpoint responde HTTP 200 quando acessado pelo navegador, mas está marcado como Degraded pelo Traffic Manager. Isso indica que o problema não está na disponibilidade do serviço em si, mas na resposta percebida pelos agentes de probe da Microsoft, que operam a partir de pontos de presença específicos e usam critérios estritos.

Os agentes de probe do Traffic Manager avaliam o código de resposta HTTP retornado pelo caminho configurado. Se a rota /health redireciona para uma página de login, retorna um código 3xx, ou exige autenticação, o probe interpretará isso como falha, mesmo que o serviço esteja operacional para usuários humanos.

A alternativa B é plausível, mas o tempo de resposta de 180 ms no teste manual indica que a latência não seria problema com um limite de 10 segundos. A alternativa A é descartada porque o enunciado informa que o certificado é válido. A alternativa D é tecnicamente falsa: probes HTTPS são plenamente suportados com App Services.

O distrator mais perigoso é B, pois induz o engenheiro a alterar o tempo limite sem investigar o conteúdo da resposta, o que não resolveria o problema.

Gabarito — Cenário 2​

Resposta: B

O cenário apresenta restrições explícitas: ambiente em produção com alta carga e alerta da equipe de DNS sobre impacto de TTLs muito baixos. A única ação que respeita todas as restrições é aguardar a janela de manutenção disponível em 48 horas e executar a redução de forma gradual e monitorada.

A alternativa A viola duas restrições: o TTL mínimo suportado pelo Traffic Manager é 0 segundos, mas isso causa aumento severo de consultas DNS e pode sobrecarregar o serviço em produção com 40.000 RPM. A alternativa C é uma decisão arquitetural válida em outros contextos, mas não resolve o problema imediato e está fora do escopo de uma ação de emergência pontual. A alternativa D confunde dois mecanismos independentes: o intervalo de probe afeta a velocidade de detecção da falha pelo Traffic Manager, mas não reduz o tempo de propagação do failover para os clientes, que é controlado pelo TTL.

O erro de raciocínio central dos distratores é tratar TTL e intervalo de probe como equivalentes, ou ignorar as restrições do ambiente ao escolher a ação.

Gabarito — Cenário 3​

Resposta: B

A informação decisiva está explícita no enunciado e não deve ser ignorada: o resolver DNS interno possui cache de TTL fixo de 1800 segundos, independentemente do valor declarado pelo Traffic Manager. Isso significa que, mesmo que o Traffic Manager pare de retornar o IP do endpoint desativado imediatamente, o resolver corporativo continuará respondendo com o valor em cache por até 30 minutos.

O TTL de 60 segundos no perfil é irrelevante neste cenário porque o resolver intermediário não o respeita. Essa é exatamente a informação que deveria ser filtrada como irrelevante para o diagnóstico.

A alternativa A é falsa: desativações manuais têm o mesmo efeito que falhas de health check para fins de roteamento. A alternativa C inverte a lógica: um TTL menor seria melhor para failover, não um valor maior. A alternativa D é um distrator sem base técnica; o Traffic Manager propaga mudanças globalmente em segundos, não em minutos ou horas.

O risco real aqui é o engenheiro focar no TTL do perfil (60 segundos) como causa, sem perceber que o resolver corporativo é o obstáculo real.

Gabarito — Cenário 4​

Resposta: A

A sequência correta é 2 → 4 → 1 → 5 → 3.

O raciocínio diagnóstico eficiente parte do mais amplo para o mais específico:

  1. Confirmar o método de roteamento (passo 2): Antes de qualquer investigação de endpoint, é necessário confirmar que o método é realmente Performance. Uma misconfiguration aqui explicaria tudo imediatamente.
  2. Verificar o status do endpoint (passo 4): Se o endpoint de West Europe está Degraded ou Disabled, o Traffic Manager corretamente direciona para outro endpoint. Esse passo elimina ou confirma a hipótese mais comum.
  3. Verificar a resposta do probe (passo 1): Se o status está Online mas o comportamento é inesperado, investigar se o probe está realmente recebendo respostas válidas.
  4. Testar a resolução DNS (passo 5): Verificar o que o cliente europeu de fato recebe, confirmando que o Traffic Manager está retornando o endpoint americano.
  5. Comparar a tabela de latência (passo 3): Somente se todos os passos anteriores não revelarem a causa, investigar se a tabela de latência da Microsoft classifica a origem europeia como mais próxima dos EUA, o que seria incomum mas possível em redes corporativas com saída via proxy nos EUA.

A alternativa B começa pelo DNS antes de entender o estado do endpoint, o que pode gerar conclusões precipitadas. A alternativa C verifica o probe antes de confirmar o status, invertendo a prioridade. A alternativa D é similar à correta mas posterga a verificação de status para o final, perdendo eficiência.

Árvore de Troubleshooting: Implement Azure Traffic Manager​

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

Legenda de cores:

  • Azul escuro: sintoma inicial, ponto de entrada do diagnóstico
  • Azul: pergunta diagnóstica, verificação objetiva a ser feita
  • Vermelho: causa identificada
  • Verde: ação recomendada ou resolução

Para usar esta árvore diante de um problema real, comece pelo nó raiz descrevendo o sintoma de roteamento inesperado e siga as ramificações respondendo cada pergunta com base no que você pode observar diretamente no portal, nos logs de DNS ou nos testes de probe. Cada resposta elimina hipóteses e estreita o caminho até a causa. Ao chegar a um nó vermelho, a causa está identificada; o nó verde imediatamente associado indica a ação corretiva correspondente.