Monitorização do ponto final do Gestor de Tráfego

O Gestor de Tráfego do Azure inclui a monitorização do ponto final incorporado e a ativação pós-falha automática do ponto final. Esta funcionalidade ajuda a proporcionar aplicações de alta disponibilidade que são resistentes à falha no ponto final, incluindo falhas na região do Azure.

Configure a monitorização do ponto final

Para configurar a monitorização do ponto final, deve especificar as seguintes definições no perfil do Gestor de Tráfego:

  • O protocolo. Escolha HTTP, HTTPS ou TCP como o protocolo que o Gestor de Tráfego utiliza ao sondar o seu ponto final para verificar a sua saúde. A monitorização HTTPS não verifica se o seu certificado TLS/SSL é válido -- apenas verifica a presença do certificado.

  • Porto, porto. Escolha a porta utilizada para o pedido.

  • O caminho. Esta definição de configuração é válida apenas para os protocolos HTTP e HTTPS, para os quais é necessária especificar a definição do percurso. Desde que esta definição para o protocolo de monitorização TCP resulte num erro. Para protocolo HTTP e HTTPS, forneça o caminho relativo e o nome da página web ou do ficheiro a que a monitorização acede. Uma barra inclinada (/) é uma entrada válida para o caminho relativo. Este valor implica que o ficheiro está no diretório de raiz (predefinição).

  • Configurações personalizadas do cabeçalho. Esta definição de configuração ajuda-o a adicionar cabeçalhos HTTP específicos às verificações de saúde que o Traffic Manager envia para pontos finais sob um perfil. Os cabeçalhos personalizados podem ser especificados a um nível de perfil para serem aplicáveis a todos os pontos finais nesse perfil e/ou a um nível de ponto final aplicável apenas a esse ponto final. Você pode usar cabeçalhos personalizados para verificações de saúde de pontos finais em um ambiente multi-inquilino. Desta forma, pode ser encaminhado corretamente para o seu destino especificando um cabeçalho anfitrião. Também pode utilizar esta definição adicionando cabeçalhos únicos que podem ser usados para identificar pedidos HTTP(S originados http(S) originados e processá-los de forma diferente. Pode especificar até oito pares de cabeçalho:valor separados por uma vírgula. Por exemplo, "header1:value1, header2:value2".

    NOTA: A utilização de caracteres asteriscos (*) em cabeçalhos personalizados Host não é suportada.

  • Os intervalos esperados de código de estado. Esta definição permite especificar vários intervalos de código de sucesso no formato 200-299, 301-301. Se estes códigos de estado forem recebidos como resposta de um ponto final quando um exame de saúde é feito, o Gestor de Tráfego assinala esses pontos finais como saudáveis. Pode especificar um máximo de oito intervalos de código de estado. Esta definição é aplicável apenas ao protocolo HTTP e HTTPS e a todos os pontos finais. Esta definição está ao nível do perfil do Gestor de Tráfego e, por predefinição, o valor 200 é definido como o código de estado de sucesso.

  • Intervalo de sondagem. Este valor especifica a frequência com que um ponto final é verificado para a sua saúde a partir de um agente de sondagem do Traffic Manager. Pode especificar dois valores aqui: 30 segundos (sondagem normal) e 10 segundos (sondagem rápida). Se não forem fornecidos valores, o perfil define-se para um valor predefinido de 30 segundos. Visite a página de preços do Gestor de Tráfego para saber mais sobre preços rápidos de sondagem.

  • Número tolerado de falhas. Este valor especifica quantas falhas um agente de sondagem do Traffic Manager tolera antes de marcar esse ponto final como insalubre. O seu valor pode variar entre 0 e 9. Um valor de 0 significa que uma única falha de monitorização pode fazer com que esse ponto final seja marcado como insalubre. Se não for especificado qualquer valor, utiliza o valor predefinido de 3.

  • Tempo de tempo de sonda. Esta propriedade especifica a quantidade de tempo que o agente de sondagem do Traffic Manager deve esperar antes de considerar uma sonda de saúde verificar para um ponto final uma falha. Se o intervalo de sondagem estiver definido para 30 segundos, então pode definir o valor do intervalo entre 5 e 10 segundos. Se não for especificado qualquer valor, utiliza um valor predefinido de 10 segundos. Se o intervalo de sondagem estiver definido para 10 segundos, pode definir o valor do intervalo entre 5 e 9 segundos. Se não for especificado nenhum valor de tempo limite, utiliza um valor predefinido de 9 segundos.

    Monitorização do ponto final do Gestor de Tráfego

    Figura: Monitorização do ponto final do Gestor de Tráfego

Como funciona a monitorização do ponto final

Quando o protocolo de monitorização é definido como HTTP ou HTTPS, o agente de sondagem do Gestor de Tráfego faz um pedido GET ao ponto final utilizando o protocolo, porta e caminho relativo dado. Um ponto final é considerado saudável se o agente de sondagem receber uma resposta de 200 OK, ou qualquer uma das respostas configuradas nas gamas de códigos de estado esperados. Se a resposta for um valor diferente ou nenhuma resposta for recebida dentro do período de tempo limite, o agente de sondagem do Gestor de Tráfego reatteça de acordo com a definição de Número Tolerado de Falhas. Não são feitas reattemptas se esta definição for 0. O ponto final é marcado como insalubre se o número de falhas consecutivas for superior ao número tolerado de falhas.

Quando o protocolo de monitorização é TCP, o agente de sondagem do Gestor de Tráfego cria um pedido de ligação TCP utilizando a porta especificada. Se o ponto final responder ao pedido com uma resposta para estabelecer a ligação, esse exame de saúde é marcado como um sucesso. O agente de sondagem do Gestor de Tráfego reinicia a ligação TCP. Nos casos em que a resposta é um valor diferente ou nenhuma resposta é recebida dentro do período de tempo limite, o agente de sondagem do Gestor de Tráfego recandidinha-se de acordo com a definição do Número Tolerado de Falhas. Não são feitas reattemptas se esta definição for 0. Se o número de falhas consecutivas for superior ao número tolerado de falhas, então esse ponto final não é saudável.

Em todos os casos, o Traffic Manager sonda de vários locais. A falha consecutiva determina o que acontece em cada região. É por isso que os pontos finais estão a receber sondas de saúde do Traffic Manager com uma frequência mais alta do que a configuração usada para o Intervalo de Sondagem.

Nota

Para o protocolo de monitorização HTTP ou HTTPS, uma prática comum no lado do ponto final é implementar uma página personalizada dentro da sua aplicação - por exemplo, /saúde.aspx. Utilizando este caminho para monitorização, pode efetuar verificações específicas da aplicação, tais como verificar contadores de desempenho ou verificar a disponibilidade da base de dados. Com base nestas verificações personalizadas, a página devolve um código de estado HTTP apropriado.

Todos os pontos finais de uma definição de monitorização de partilha de perfil do Gestor de Tráfego. Se precisar de utilizar diferentes definições de monitorização para diferentes pontos finais, pode criar perfis de Gestor de Tráfego aninhados.

Ponto final e estado de perfil

Pode ativar e desativar perfis e pontos finais do Gestor de Tráfego. No entanto, uma alteração no estado do ponto final também pode ocorrer devido às configurações e processos automatizados do Gestor de Tráfego.

Estado do ponto final

Pode ativar ou desativar um ponto final específico. O serviço subjacente, que ainda pode ser saudável, não é afetado. A alteração do estado do ponto final controla a disponibilidade do ponto final no perfil de Gestor de Tráfego. Quando um estado de ponto final é desativado, o Gestor de Tráfego não verifica a sua saúde e o ponto final não está incluído numa resposta ao DNS.

Estado do perfil

Utilizando a definição de estado de perfil, pode ativar ou desativar um perfil específico. Embora o estado do ponto final afete um único ponto final, o estado do perfil afeta todo o perfil, incluindo todos os pontos finais. Quando desativa um perfil, os pontos finais não são verificados para saúde e nenhum ponto final é incluído numa resposta dns. Um código de resposta NXDOMAIN é devolvido para a consulta DNS.

Estado do monitor de ponto final

O estado do monitor de ponto final é um valor gerado pelo Gestor de Tráfego que mostra o estado do ponto final. Não é possível alterar esta definição manualmente. O estado do monitor de ponto final é uma combinação dos resultados da monitorização do ponto final e do estado do ponto final configurado. Os valores possíveis do estado do monitor de ponto final são indicados no quadro seguinte:

Estado do perfil Estado do ponto final Estado do monitor de ponto final Notas
Desativado Ativado Inativa O perfil foi desativado. Embora o estado do ponto final esteja Ativado, o estado do perfil (Desativado) tem precedência. Os pontos finais nos perfis desativados não são monitorizados. Um código de resposta NXDOMAIN é devolvido para a consulta DNS.
<qualquer> Desativado Desativado O ponto final foi desativado. Os pontos finais desativados não são monitorizados. O ponto final não está incluído nas respostas do DNS, como tal não recebe tráfego.
Ativado Ativado Online O ponto final é monitorizado e é saudável. Está incluído nas respostas do DNS e pode receber tráfego.
Ativado Ativado Degradado Os controlos de saúde de monitorização do ponto final estão a falhar. O ponto final não está incluído nas respostas do DNS e não recebe tráfego.
Uma exceção é se todos os pontos finais estiverem degradados. Nesse caso, todos são considerados devolvidos na resposta à consulta).
Ativado Ativado VerificaçãoEndpoint O ponto final é monitorizado, mas os resultados da primeira sonda ainda não foram recebidos. CheckingEndpoint é um estado temporário que ocorre geralmente imediatamente após adicionar ou ativar um ponto final no perfil. Um ponto final neste estado está incluído nas respostas do DNS e pode receber tráfego.
Ativado Ativado Parada A aplicação web a que o ponto final aponta não está a funcionar. Verifique as definições da aplicação web. Este estado também pode acontecer se o ponto final for do tipo aninhado e o perfil da criança ficar incapacitado ou estiver inativo.
Um ponto final com um estado de paragem não é monitorizado. Não está incluído nas respostas do DNS e não recebe tráfego. Uma exceção é se todos os pontos finais estiverem degradados. Nesse caso, todos serão considerados devolvidos na resposta de consulta.

Para obter mais informações sobre como o estado do monitor de ponto final é calculado para pontos finais aninhados, consulte os perfis do Gestor de Tráfego aninhado.

Nota

Um estado de monitor de ponto final parado pode ocorrer no Serviço de Aplicações se a sua aplicação web não estiver a funcionar no nível Standard ou acima. Para mais informações, consulte a integração do Traffic Manager com Serviço de Aplicações.

Estado do monitor de perfil

O estado do monitor de perfil é uma combinação do estado de perfil configurado e dos valores de estado do monitor de ponto final para todos os pontos finais. Os valores possíveis são descritos no quadro seguinte:

Estado do perfil (conforme configurado) Estado do monitor de ponto final Estado do monitor de perfil Notas
Desativado <qualquer> ou um perfil sem pontos finais definidos. Desativado O perfil foi desativado.
Ativado O estado de pelo menos um ponto final está degradado. Degradado Reveja os valores de estado de ponto final individuais para determinar quais os pontos finais que requerem mais atenção.
Ativado O estado de pelo menos um ponto final é Online. Nenhum ponto final tem um estatuto degradado. Online O serviço está a aceitar o trânsito. Não são necessárias mais ações.
Ativado O estado de pelo menos um ponto final é CheckingEndpoint. Nenhum ponto final está em estado online ou degradado. Verificação Deendpoints Este estado de transição ocorre quando um perfil se criado ou ativado. A saúde do ponto final está a ser verificada pela primeira vez.
Ativado Os estados de todos os pontos finais no perfil são desativado ou parados, ou o perfil não tem pontos finais definidos. Inativa Nenhum ponto final está ativo, mas o perfil ainda está Ativado.

Falha e recuperação do ponto final

O Gestor de Tráfego verifica periodicamente a saúde de todos os pontos finais, incluindo pontos finais pouco saudáveis. O Gestor de Tráfego deteta quando um ponto final fica saudável e o traz de volta à rotação.

Um ponto final não é saudável quando ocorre qualquer um dos seguintes eventos:

  • Se o protocolo de monitorização for HTTP ou HTTPS:
    • Uma resposta não-200, ou uma resposta que não inclua o intervalo de estado especificado na definição de código de estado esperado . (Incluindo um código 2xx diferente, ou um redirecionamento 301/302).
  • Se o protocolo de monitorização for TCP:
    • Uma resposta diferente da ACK ou SYN-ACK é recebida em resposta ao pedido SYN enviado pelo Traffic Manager para tentar um estabelecimento de ligação.
  • Tempo limite.
  • Qualquer outro problema de ligação que resulte em que o ponto final não seja alcançável.

Para obter mais informações sobre a resolução de problemas de verificações falhadas, consulte o estado degradado da resolução de problemas no Gestor de Tráfego da Azure.

A cronologia no seguinte número é uma descrição detalhada do processo de monitorização do ponto final do Gestor de Tráfego que tem as seguintes definições:

  • O protocolo de monitorização é HTTP.
  • O intervalo de sondagem é de 30 segundos.
  • Número de falhas toleradas é 3.
  • O valor de tempo limite é de 10 segundos.
  • DNS TTL é de 30 segundos.

Falha no ponto final do gestor de tráfego e sequência de failback

Figura: Falha no ponto final do gestor de tráfego e sequência de recuperação

  1. VAI. Para cada ponto final, o sistema de monitorização do Gestor de Tráfego faz um pedido GET sobre o caminho especificado nas definições de monitorização.

  2. 200 OK ou gama de códigos personalizados especificadas definições de monitorização do perfil do Gestor de Tráfego. O sistema de monitorização espera que um HTTP 200 OK ou um código de estado na gama especificado nas definições de monitorização seja devolvido dentro de 10 segundos. Quando recebe esta resposta, reconhece que o serviço está disponível.

  3. 30 segundos entre cheques. O exame de saúde do ponto final é repetido a cada 30 segundos.

  4. Serviço indisponível. O serviço fica indisponível. O gerente de trânsito não saberá até ao próximo exame de saúde.

  5. Tentativas de acesso à via de monitorização. O sistema de monitorização faz um pedido GET, mas não recebe uma resposta dentro do período de tempo limite de 10 segundos. Em seguida, tenta mais três vezes, em intervalos de 30 segundos. Se uma das tentativas for bem sucedida, o número de tentativas é reiniciado.

  6. Estado definido para degradado. Após uma quarta falha consecutiva, o sistema de monitorização marca o estado de ponto final indisponível como Degradado.

  7. O trânsito é desviado para outros pontos finais. Os servidores de nome DNS do Gestor de Tráfego são atualizados e o Gestor de Tráfego já não devolve o ponto final em resposta a consultas dns. As novas ligações são direcionadas para outros pontos finais disponíveis. No entanto, as respostas anteriores do DNS que incluem este ponto final ainda podem ser cached por servidores DNS recursivos e clientes DNS. Os clientes continuam a utilizar o ponto final até que a cache DNS expire. À medida que a cache DNS expira, os clientes fazem novas consultas de DNS e são direcionados para diferentes pontos finais. A duração da cache é controlada pela definição de TTL no perfil de Gestor de Tráfego, por exemplo, 30 segundos.

  8. Os controlos de saúde continuam. O Gestor de Tráfego continua a verificar a saúde do ponto final enquanto tem um estado degradado. O Gestor de Tráfego deteta quando o ponto final volta à saúde.

  9. O serviço volta a estar online. O serviço fica disponível. O ponto final mantém o seu estado degradado no Gestor de Tráfego até que o sistema de monitorização faça o seu próximo exame de saúde.

  10. O trânsito para o serviço recomeça. O Gestor de Tráfego envia um pedido GET e recebe uma resposta de estado de 200 OK. O serviço regressou a um estado saudável. Os servidores de nome do Gestor de Tráfego são atualizados e começam a distribuir o nome DNS do serviço nas respostas dns. O tráfego regressa ao ponto final à medida que as respostas dns em cache que devolvem outros pontos finais expiram, e como as ligações existentes para outros pontos finais estão terminando.

    Importante

    O gestor de tráfego implementa várias sondas de vários locais para cada ponto final. As múltiplas sondas aumentam a resiliência para a monitorização do ponto final. O gestor de tráfego agrega a saúde média das sondas em vez de depender de uma instância de sonda singular. A redundância do sistema de sondagem é por design. Os valores do ponto final devem ser analisados de forma holisticamente e não por sonda. O número apresentado para a saúde da sonda é uma média. O estatuto só deve ser uma preocupação se menos de 50% (0,5) das sondas publicarem um estatuto ascendente.

    Nota

    Como o Gestor de Tráfego funciona ao nível do DNS, não pode influenciar as ligações existentes a qualquer ponto final. Quando direciona o tráfego entre pontos finais (quer por definições de perfil alteradas, quer durante o failover ou failback), o Gestor de Tráfego direciona novas ligações para os pontos finais disponíveis. Outros pontos finais podem continuar a receber tráfego através das ligações existentes até que essas sessões sejam encerradas. Para permitir que o tráfego escorra das ligações existentes, as aplicações devem limitar a duração da sessão utilizada com cada ponto final.

Métodos de encaminhamento de tráfego

Quando um ponto final tem um estatuto degradado, já não é devolvido em resposta a consultas de DNS. Em vez disso, um ponto final alternativo é escolhido e devolvido. O método de encaminhamento de tráfego configurado no perfil determina como o ponto final alternativo é escolhido.

  • Prioridade. Os pontos finais formam uma lista prioritária. O primeiro ponto final disponível na lista é sempre devolvido. Se um estado de ponto final for degradado, o próximo ponto final disponível é devolvido.
  • Ponderado. Todos os pontos finais disponíveis são escolhidos aleatoriamente com base nos seus pesos atribuídos e nos pesos dos outros pontos finais disponíveis.
  • Desempenho. O ponto final mais próximo do utilizador final é devolvido. Se esse ponto final não estiver disponível, o Gestor de Tráfego desloca o tráfego para os pontos finais na região de Azure mais próxima. Pode configurar planos alternativos de failover para o encaminhamento de tráfego de desempenho utilizando perfis de Gestor de Tráfego aninhados.
  • É geográfico. O ponto final mapeado para servir a localização geográfica com base no pedido de consulta IP's é devolvido. Se esse ponto final não estiver disponível, outro ponto final não será selecionado para falhar, uma vez que uma localização geográfica pode ser mapeada apenas para um ponto final num perfil. (Mais detalhes estão nas FAQ). Como uma boa prática, ao utilizar o encaminhamento geográfico, recomendamos que os clientes utilizem perfis de Gestor de Tráfego aninhados com mais de um ponto final como ponto final do perfil.
  • MultiValue Vários pontos finais mapeados para endereços IPv4/IPv6 são devolvidos. Quando uma consulta é recebida para este perfil, os pontos finais saudáveis são devolvidos com base na contagem máxima de registo no valor de resposta que especificou. O número predefinido de respostas é de dois pontos finais.
  • Sub-rede O ponto final mapeado para um conjunto de intervalos de endereços IP é devolvido. Quando um pedido é recebido a partir desse endereço IP, o ponto final devolvido é o mapeado para esse endereço IP. 

Para obter mais informações, consulte os métodos de encaminhamento de tráfego do Traffic Manager.

Nota

Uma exceção ao comportamento normal de encaminhamento de tráfego ocorre quando todos os pontos finais elegíveis têm um estatuto degradado. O Gestor de Tráfego faz uma tentativa de "melhor esforço" e responde como se todos os pontos finais de estado degradados estivessem realmente em um estado online. Este comportamento é preferível à alternativa, que seria não devolver nenhum ponto final na resposta ao DNS. Os pontos finais desativados ou parados não são monitorizados, pelo que não são considerados elegíveis para o tráfego.

Esta condição é geralmente causada por uma configuração inadequada do serviço, tais como:

  • Uma lista de controlo de acessos [ACL] bloqueando os controlos de saúde do Traffic Manager.
  • Uma configuração inadequada da porta de monitorização ou protocolo no perfil do gestor de tráfego.

A consequência deste comportamento é que se os controlos de saúde do Traffic Manager não estiverem configurados corretamente, pode parecer do encaminhamento de tráfego como se o Traffic Manager estivesse a funcionar corretamente. No entanto, neste caso, a falência do ponto final não pode acontecer, afetando a disponibilidade global de aplicações. É importante verificar se o perfil mostra um estado Online, não um estado degradado. Um estado online indica que os controlos de saúde do Gestor de Tráfego estão a funcionar como esperado.

Para obter mais informações sobre a resolução de problemas de verificação de saúde falhada, consulte o estado degradado da resolução de problemas no Gestor de Tráfego da Azure.

FAQs

Passos seguintes

Saiba como funciona o Gestor de Tráfego

Saiba mais sobre os métodos de encaminhamento de tráfego suportados pelo Traffic Manager

Saiba como criar um perfil de Gestor de Tráfego

Resolução de problemas Degradado estado num ponto final do Gestor de Tráfego