Compartilhar via


Solucionando problemas de status degradado do Gerenciador de Tráfego do Azure

Este artigo descreve como solucionar problemas de um perfil do Gerenciador de Tráfego do Azure que mostra um estado degradado. A primeira etapa para solucionar problemas de um estado degradado do Gerenciador de Tráfego do Azure é habilitar o registro em log. Veja Habilitar logs de recursos para obter mais informações. Neste cenário, imagine que você configurou um perfil do Gerenciador de Tráfego que aponta para alguns dos serviços hospedados no cloudapp.net. Se a integridade do seu Gerenciador de Tráfego exibe um status Degradado, o status de um ou mais pontos de extremidade pode ser Degradado:

status do ponto de extremidade degradado

Se a integridade do seu Gerenciador de Tráfego exibe um status Inativo, ambos os pontos de extremidade podem ser Desabilitado:

Status do Gerenciador de Tráfego Inativo

Noções básicas sobre as investigações do Gerenciador de Tráfego

  • O Gerenciador de Tráfego considera um ponto de extremidade como estando ONLINE somente quando a investigação recebe uma resposta HTTP 200 do caminho de investigação. Se o aplicativo retornar qualquer outro código de resposta HTTP, será preciso adicioná-lo aos intervalos de códigos de status esperados no perfil do Gerenciador de Tráfego.
  • Uma resposta de redirecionamento 30x é tratada como falha, a menos que você especifique isso como um código de resposta válido em Intervalos de código de status esperados no perfil do Gerenciador de Tráfego. O Gerenciador de Tráfego não investiga o destino de redirecionamento.
  • Para investigações de HTTPs, os erros de certificado são ignorados.
  • O conteúdo real do caminho de investigação não importa, contanto que uma resposta 200 seja retornada. A investigação de uma URL para algum conteúdo estático como “/favicon.ico” é uma técnica comum. O conteúdo dinâmico, como as páginas ASP, nem sempre poderá retornar a resposta 200, mesmo quando o aplicativo estiver íntegro.
  • Uma prática recomendada é definir o caminho de investigação como algo que tenha lógica suficiente para determinar se o site está ativo ou inativo. No exemplo anterior, ao definir o caminho como "/favicon.ico", a única coisa que você faz é testar se w3wp.exe está respondendo. Essa investigação pode não indicar que o aplicativo Web está íntegro. Uma opção melhor seria definir um caminho para algo como “/Probe.aspx”, que tem lógica para determinar a integridade do site. Por exemplo, você poderá usar contadores de desempenho para a utilização da CPU ou medir o número de solicitações com falha. Se preferir, você poderá tentar acessar os recursos de banco de dados ou o estado de sessão para verificar se o aplicativo Web está funcionando.
  • Se todos os pontos de extremidade em um perfil estiverem degradados, o Gerenciador de Tráfego tratará todos os pontos de extremidade como íntegros e encaminhará o tráfego para todos eles. Esse comportamento garante que problemas com o mecanismo de sondagem não resultem em uma interrupção completa do serviço.

Solução de problemas

Para solucionar uma falha de investigação, você precisa de uma ferramenta que mostra o retorno de código de status HTTP da URL de investigação. Há várias ferramentas disponíveis que mostram a resposta HTTP bruta.

Além disso, você pode usar a guia Rede das Ferramentas de Depuração F12 no Internet Explorer para exibir as respostas HTTP.

Neste exemplo, queremos ver a resposta de nossa URL de investigação: http://watestsdp2008r2.cloudapp.net:80/Probe. O exemplo do PowerShell a seguir ilustra o problema.

Invoke-WebRequest 'http://watestsdp2008r2.cloudapp.net/Probe' -MaximumRedirection 0 -ErrorAction SilentlyContinue | Select-Object StatusCode,StatusDescription

Saída de exemplo:

StatusCode StatusDescription
---------- -----------------
        301 Moved Permanently

Observe que recebemos uma resposta de redirecionamento. Como mencionamos anteriormente, qualquer StatusCode diferente de 200 é considerado uma falha. O Gerenciador de Tráfego altera o status do ponto de extremidade para Offline. Para resolver o problema, verifique a configuração do site para garantir que o StatusCode apropriado pode ser retornado do caminho de investigação. Reconfigure a investigação do Gerenciador de Tráfego para que ela aponte para um caminho que retorna uma resposta 200.

Se a investigação estiver usando o protocolo HTTPS, talvez seja necessário desabilitar a verificação de certificado, para evitar erros de SSL/TLS durante o teste. As seguintes instruções do PowerShell desabilitam a validação de certificado na sessão atual do PowerShell:

add-type @"
using System.Net;
using System.Security.Cryptography.X509Certificates;
public class TrustAllCertsPolicy : ICertificatePolicy {
    public bool CheckValidationResult(
    ServicePoint srvPoint, X509Certificate certificate,
    WebRequest request, int certificateProblem) {
    return true;
    }
}
"@
[System.Net.ServicePointManager]::CertificatePolicy = New-Object TrustAllCertsPolicy

Próximas etapas

Sobre os métodos de roteamento de tráfego do Gerenciador de Tráfego

O que é o Gerenciador de Tráfego

Serviços de Nuvem

Serviço de Aplicativo do Azure

Operações no Gerenciador de Tráfego (referência de API REST)

Cmdlets do Gerenciador de Tráfego do Azure