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. A monitorização de pontos finais está ativada por predefinição. Para desativar a monitorização, veja Ativar ou desativar as verificações de estado de funcionamento.
Configurar a monitorização de pontos finais
Para configurar a monitorização de pontos finais, tem de especificar as seguintes definições no perfil do Gestor de Tráfego:
- Protocolo. Selecione HTTP, HTTPS ou TCP como o protocolo que o Gestor de Tráfego utiliza ao sondar o ponto final para verificar o estado de funcionamento. A monitorização https não verifica se o certificado TLS/SSL é válido, apenas verifica se o certificado está presente.
- Porta. Escolha a porta utilizada para o pedido.
-
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 de caminho. Fornecer esta definição para o protocolo de monitorização TCP resulta num erro. Para o protocolo HTTP e HTTPS, atribua o caminho relativo e o nome da página Web ou o ficheiro ao qual a monitorização acede. Uma barra
/
para a frente é uma entrada válida para o caminho relativo. Este valor implica que o ficheiro está no diretório de raiz (predefinição). -
Definições de cabeçalho personalizadas. Esta definição de configuração ajuda-o a adicionar cabeçalhos HTTP específicos às verificações de estado de funcionamento que o Gestor de Tráfego envia para pontos finais num perfil. Os cabeçalhos personalizados podem ser especificados ao nível do perfil para serem aplicáveis a todos os pontos finais nesse perfil e/ou ao nível do ponto final aplicável apenas a esse ponto final. Pode utilizar cabeçalhos personalizados para verificações de estado de funcionamento de pontos finais num ambiente multi-inquilino. Dessa forma, pode ser encaminhado corretamente para o destino ao especificar um cabeçalho de anfitrião. Também pode utilizar esta definição ao adicionar cabeçalhos exclusivos que podem ser utilizados para identificar pedidos HTTP(S) com origem no Gestor de Tráfego e processá-los de forma diferente. Pode especificar até oito
header:value
pares separados por uma vírgula. Por exemplo,header1:value1, header2:value2
.
Nota
A utilização de carateres asteriscos (*) em cabeçalhos personalizados Host
não é suportada.
Intervalos de código de estado esperados. Esta definição permite-lhe especificar vários intervalos de código de êxito no formato 200-299, 301-301. Se estes códigos de estado forem recebidos como resposta de um ponto final quando uma verificação de estado de funcionamento estiver concluída, o Gestor de Tráfego marca esses pontos finais como estando em bom estado de funcionamento. 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 êxito.
Intervalo de pesquisa. Este valor especifica a frequência com que um ponto final é verificado relativamente ao seu estado de funcionamento a partir de um agente de pesquisa do Gestor de Tráfego. Pode especificar dois valores aqui: 30 segundos (pesquisa normal) e 10 segundos (pesquisa rápida). Se não forem fornecidos valores, o perfil define um valor predefinido de 30 segundos. Visite a página de preços do Gestor de Tráfego para saber mais sobre os preços de pesquisa rápida.
Número tolerado de falhas. Este valor especifica quantas falhas um agente de pesquisa do Gestor de Tráfego tolera antes de marcar esse ponto final como estando em mau estado de funcionamento. O respetivo 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 estando em mau estado de funcionamento. Se não for especificado nenhum valor, utiliza o valor predefinido de 3.
Tempo limite da sonda. Esta propriedade especifica a quantidade de tempo que o agente de pesquisa do Gestor de Tráfego deve aguardar antes de considerar uma verificação da sonda de estado de funcionamento para um ponto final como uma falha. Se o Intervalo de Pesquisa estiver definido como 30 segundos, pode definir o valor de Tempo Limite entre 5 e 10 segundos. Se não for especificado nenhum valor, utiliza um valor predefinido de 10 segundos. Se o Intervalo de Pesquisa estiver definido como 10 segundos, pode definir o valor tempo limite entre 5 e 9 segundos. Se não for especificado nenhum valor de Tempo Limite, utiliza um valor predefinido de 9 segundos.
Figura: Monitorização do ponto final do Gestor de Tráfego
Como funciona a monitorização de pontos finais
Quando o protocolo de monitorização é definido como HTTP ou HTTPS, o agente de pesquisa do Gestor de Tráfego faz um pedido GET ao ponto final com o protocolo, a porta e o caminho relativo fornecidos. Um ponto final é considerado em bom estado de funcionamento se o agente de pesquisa receber uma resposta 200-OK ou qualquer uma das respostas configuradas nos intervalos de código 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 pesquisa do Gestor de Tráfego reaja de acordo com a definição Número Tolerado de Falhas. Não são feitas reattempts se esta definição for 0. O ponto final será marcado como estando em mau estado de funcionamento se o número de falhas consecutivas for superior à definição Número tolerado de falhas .
Quando o protocolo de monitorização é TCP, o agente de pesquisa do Gestor de Tráfego cria um pedido de ligação TCP com a porta especificada. Se o ponto final responder ao pedido com uma resposta para estabelecer a ligação, essa verificação de estado de funcionamento será marcada como um êxito. O agente de pesquisa do Gestor de Tráfego repõe 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 pesquisa do Gestor de Tráfego reaja de acordo com a definição Número tolerado de falhas . Não são efetuadas reattempts se esta definição for 0. Se o número de falhas consecutivas for superior à definição Número tolerado de falhas , esse ponto final será marcado como em mau estado de funcionamento.
Em todos os casos, o Gestor de Tráfego sonda a partir de várias localizações. A falha consecutiva determina o que acontece em cada região. É por isso que os pontos finais estão a receber sondas de estado de funcionamento do Gestor de Tráfego com uma frequência superior à definição utilizada para o Intervalo de Pesquisa.
Nota
Para o protocolo de monitorização HTTP ou HTTPS, uma prática comum no lado do ponto final é implementar uma página personalizada na sua aplicação , por exemplo, /health.aspx. Com este caminho para monitorização, pode efetuar verificações específicas da aplicação, 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 adequado.
Todos os pontos finais nas definições de monitorização da partilha de perfis do Gestor de Tráfego. Se precisar de utilizar diferentes definições de monitorização para diferentes pontos finais, pode criar perfis aninhados do Gestor de Tráfego.
Estado do ponto final e do perfil
Pode ativar e desativar os perfis e pontos finais do Gestor de Tráfego. No entanto, também pode ocorrer uma alteração no estado do ponto final devido às definiçõ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 estar em bom estado de funcionamento, não é afetado. Alterar o estado do ponto final controla a disponibilidade do ponto final no perfil do Gestor de Tráfego. Quando um estado de ponto final é desativado, o Gestor de Tráfego não verifica o estado de funcionamento e o ponto final não está incluído numa resposta DNS.
Estado do perfil
Com a definição de estado do 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 quanto ao estado de funcionamento e não são incluídos pontos finais numa resposta DNS. É devolvido um código de resposta NXDOMAIN 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 pode 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 apresentados na tabela 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 seja Ativado, o estado do perfil (Desativado) tem precedência. Os pontos finais em perfis desativados não são monitorizados. É devolvido um código de resposta NXDOMAIN 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 DNS, uma vez que não recebe tráfego. |
Ativado | Ativado | Online | O ponto final é monitorizado e está em bom estado de funcionamento. Está incluído nas respostas DNS e pode receber tráfego. |
Ativado | Ativado | Degradado | As verificações de estado de funcionamento da monitorização de pontos finais estão a falhar. O ponto final não está incluído nas respostas DNS e não recebe tráfego. Uma exceção é se todos os pontos finais estiverem degradados. Nesse caso, todos eles são considerados como devolvidos na resposta da consulta. |
Ativado | Ativado | CheckEndpoint | O ponto final é monitorizado, mas os resultados da primeira sonda ainda não foram recebidos. CheckEndpoint é um estado temporário que normalmente ocorre imediatamente após adicionar ou ativar um ponto final no perfil. Um ponto final neste estado está incluído nas respostas DNS e pode receber tráfego. |
Ativado | Ativado | Parada | A aplicação Web para a qual o ponto final aponta não está em execução. Verifique as definições da aplicação Web. Este estado também pode ocorrer se o ponto final for do tipo ponto final aninhado e o perfil subordinado for desativado ou estiver inativo. Um ponto final com o estado Parado não é monitorizado. Não está incluído nas respostas DNS e não recebe tráfego. Uma exceção é se todos os pontos finais estiverem degradados. Nesse caso, todos eles são considerados como devolvidos na resposta da consulta. |
Ativado | Ativado | Não monitorizado | O ponto final está configurado para servir sempre o tráfego. As verificações de estado de funcionamento não estão ativadas. |
Para obter detalhes sobre como o estado do monitor de ponto final é calculado para pontos finais aninhados, veja Perfis aninhados do Gestor de Tráfego.
Nota
Um estado do monitor de Ponto Final Parado pode ocorrer no Serviço de Aplicações se a aplicação Web não estiver em execução no escalão Standard ou superior. Para obter mais informações, veja Integração do Gestor de Tráfego com Serviço de Aplicações.
Estado do monitor de perfil
O estado do monitor de perfil é uma combinação do estado do perfil configurado e dos valores de estado do monitor de ponto final para todos os pontos finais. Os valores possíveis estão descritos na seguinte tabela:
Estado do perfil (conforme configurado) | Estado do monitor de ponto final | Estado do monitor de perfil | Notas |
---|---|---|---|
Desativado | <qualquer> um ou um perfil sem pontos finais definidos. | Desativado | O perfil foi desativado. |
Ativado | O estado de, pelo menos, um ponto final é Degradado. | Degradado | Reveja os valores de estado do ponto final individual 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 estado Degradado. | Online | O serviço está a aceitar tráfego. Não são necessárias mais ações. |
Ativado | O estado de, pelo menos, um ponto final é CheckEndpoint. Não existem pontos finais no estado Online ou Degradado. | CheckEndpoints | Este estado de transição ocorre quando um perfil é criado ou ativado. O estado de funcionamento do ponto final está a ser verificado pela primeira vez. |
Ativado | Os estados de todos os pontos finais no perfil são Desativado ou Parado ou o perfil não tem pontos finais definidos. | Inativa | Não existem pontos finais ativos, mas o perfil ainda está Ativado. |
Ativação pós-falha e recuperação de pontos finais
O Gestor de Tráfego verifica periodicamente o estado de funcionamento de todos os pontos finais, incluindo pontos finais em mau estado de funcionamento. O Gestor de Tráfego deteta quando um ponto final fica em bom estado de funcionamento e o coloca novamente em rotação.
Um ponto final está em mau estado de funcionamento quando ocorre um dos seguintes eventos:
- Se o protocolo de monitorização for HTTP ou HTTPS:
- É recebida uma resposta não 200 ou uma resposta que não inclua o intervalo de estado especificado na definição Intervalos de código de estado esperados . (Incluindo um código 2xx diferente ou um redirecionamento 301/302).
- Se o protocolo de monitorização for TCP:
- Uma resposta diferente de ACK ou SYN-ACK é recebida em resposta ao pedido SYN enviado pelo Gestor de Tráfego para tentar um estabelecimento de ligação.
- Tempo limite.
- Qualquer outro problema de ligação que resulte na indisponibilidade do ponto final.
Para obter mais informações sobre a resolução de problemas de verificações falhadas, veja Resolver problemas de estado degradado no Gestor de Tráfego do Azure.
A linha cronológica na figura seguinte é 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 pesquisa é de 30 segundos.
- O número de falhas toleradas é 3.
- O valor do tempo limite é de 10 segundos.
- O TTL DNS é de 30 segundos.
Figura: Sequência de recuperação e ativação pós-falha do ponto final do gestor de tráfego
GET. Para cada ponto final, o sistema de monitorização do Gestor de Tráfego faz um pedido GET no caminho especificado nas definições de monitorização.
200 OK ou intervalo de código personalizado 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 no intervalo especificado nas definições de monitorização sejam devolvidos dentro de 10 segundos. Quando recebe esta resposta, reconhece que o serviço está disponível.
30 segundos entre verificações. A verificação do estado de funcionamento do ponto final é repetida a cada 30 segundos.
Serviço indisponível. O serviço fica indisponível. O Gestor de Tráfego não saberá até à próxima verificação de estado de funcionamento.
Tenta aceder ao caminho 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 será reposto.
Estado definido como Degradado. Após uma quarta falha consecutiva, o sistema de monitorização marca o estado do ponto final indisponível como Degradado.
O tráfego é desviado para outros pontos finais. Os servidores de nomes 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 DNS anteriores que incluem este ponto final podem ainda ser colocadas em cache por servidores DNS recursivos e clientes DNS. Os clientes continuam a utilizar o ponto final até a cache DNS expirar. À medida que a cache DNS expira, os clientes fazem novas consultas DNS e são direcionados para diferentes pontos finais. A duração da cache é controlada pela definição de TTL no perfil do Gestor de Tráfego, por exemplo, 30 segundos.
As verificações de estado de funcionamento continuam. O Gestor de Tráfego continua a verificar o estado de funcionamento do ponto final enquanto tem um estado Degradado. O Gestor de Tráfego deteta quando o ponto final regressa ao estado de funcionamento.
O serviço volta a estar online. O serviço fica disponível. O ponto final mantém o estado Degradado no Gestor de Tráfego até que o sistema de monitorização faça a próxima verificação do estado de funcionamento.
O tráfego para o serviço é retomado. O Gestor de Tráfego envia um pedido GET e recebe uma resposta de estado 200 OK. O serviço regressou a um bom estado de funcionamento. Os servidores de nomes do Gestor de Tráfego são atualizados e começam a distribuir o nome DNS do serviço em respostas DNS. O tráfego regressa ao ponto final à medida que as respostas DNS em cache que devolvem outros pontos finais expiram e à medida que as ligações existentes a outros pontos finais estão a terminar.
Importante
O gestor de tráfego implementa várias sondas a partir de várias localizações para cada ponto final. Várias pesquisas aumentam a resiliência para monitorização de pontos finais. O gestor de tráfego agrega o estado de funcionamento médio das sondas em vez de depender de uma instância de pesquisa singular. A redundância do sistema de pesquisa é por predefinição. Os valores de ponto final devem ser analisados de forma holística e não por sonda. O número apresentado para o estado de funcionamento da sonda é uma média. O estado só deve ser preocupante se menos de 50% (0,5) das pesquisas publicarem um estado de up.
Nota
Uma vez que 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 (por definições de perfil alteradas ou durante a ativação pós-falha ou reativação pós-falha), o Gestor de Tráfego direciona novas ligações para pontos finais disponíveis. Outros pontos finais podem continuar a receber tráfego através de ligações existentes até essas sessões serem terminadas. 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 estado Degradado , este deixa de ser devolvido em resposta a consultas DNS. Em vez disso, é escolhido e devolvido um ponto final alternativo. O método de encaminhamento de tráfego configurado no perfil determina a forma como o ponto final alternativo é escolhido.
- Prioridade. Os pontos finais estabelecem uma lista prioritária. O primeiro ponto final disponível na lista é sempre devolvido. Se um estado de ponto final estiver Degradado, será devolvido o próximo ponto final disponível.
- Ponderado. Todos os pontos finais disponíveis são escolhidos aleatoriamente com base nos pesos atribuídos e nos pesos dos outros pontos finais disponíveis.
- Desempenho. É devolvido o ponto final mais próximo do utilizador final. Se esse ponto final não estiver disponível, o Gestor de Tráfego move o tráfego para os pontos finais na próxima região mais próxima do Azure. Pode configurar planos de ativação pós-falha alternativos para o encaminhamento de tráfego de desempenho através de perfis aninhados do Gestor de Tráfego.
- Geográfico. É devolvido o ponto final mapeado para servir a localização geográfica (com base nos endereços IP do pedido de consulta). Se esse ponto final não estiver disponível, não é selecionado outro ponto final para o qual efetuar a ativação pós-falha, uma vez que uma localização geográfica só pode ser mapeada para um ponto final num perfil. (Estão disponíveis mais detalhes nas FAQ). Como melhor prática, ao utilizar o encaminhamento geográfico, recomendamos que os clientes utilizem perfis aninhados do Gestor de Tráfego com mais do que um ponto final como pontos finais do perfil.
- Valor Múltiplo São devolvidos vários pontos finais mapeados para endereços IPv4/IPv6. Quando é recebida uma consulta para este perfil, os pontos finais em bom estado de funcionamento são devolvidos com base na contagem máxima de registos no valor de resposta que especificou. O número predefinido de respostas são dois pontos finais.
- Sub-rede É devolvido o ponto final mapeado para um conjunto de intervalos de endereços IP. Quando um pedido é recebido desse endereço IP, o ponto final devolvido é o mapeado para esse endereço IP.
Para obter mais informações, veja Traffic Manager traffic-routing methods (Métodos de encaminhamento de tráfego do Gestor de Tráfego).
Nota
Uma exceção ao comportamento normal de encaminhamento de tráfego ocorre quando todos os pontos finais elegíveis têm um estado degradado. O Gestor de Tráfego faz uma tentativa de "melhor esforço" e responde como se todos os pontos finais de estado Degradados estejam realmente num estado online. Este comportamento é preferível à alternativa, que seria não devolver nenhum ponto final na resposta 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 é normalmente causada por uma configuração incorreta do serviço, como:
- Uma lista de controlo de acesso [ACL] a bloquear as verificações de estado de funcionamento do Gestor de Tráfego.
- Uma configuração incorreta da porta de monitorização ou do protocolo no perfil do Gestor de tráfego.
A consequência deste comportamento é que, se as verificações de estado de funcionamento do Gestor de Tráfego não estiverem configuradas corretamente, poderá aparecer a partir do encaminhamento de tráfego como se o Gestor de Tráfego estivesse a funcionar corretamente. No entanto, neste caso, a ativação pós-falha do ponto final não pode ocorrer, o que afeta a disponibilidade geral da aplicação. É importante verificar se o perfil mostra um estado Online e não um estado Degradado. Um estado Online indica que as verificações de estado de funcionamento do Gestor de Tráfego estão a funcionar conforme esperado.
Para obter mais informações sobre a resolução de problemas de verificações de estado de funcionamento falhadas, veja Resolver problemas de estado degradado no Gestor de Tráfego do Azure.
Ativar ou desativar verificações de estado de funcionamento
O Gestor de Tráfego do Azure também lhe permite configurar verificações de estado de funcionamento do ponto final para serem ativadas ou desativadas. Para desativar a monitorização, escolha a opção para Servir sempre o tráfego.
Existem duas definições disponíveis para Verificações de Estado de Funcionamento:
- Ativar (verificações de estado de funcionamento). O tráfego é servido para o ponto final com base no estado de funcionamento. Esta é a predefinição.
- Servir sempre o tráfego. Esta definição desativa as verificações de estado de funcionamento.
Servir Sempre
Quando a opção Servir sempre o tráfego é selecionada, a monitorização é ignorada e o tráfego é sempre enviado para um ponto final. O estado do monitor de ponto final apresentado é Não monitorizado.
Para ativar o Serviço Always:
- Selecione Pontos finais na secção Definições do painel perfil do Gestor de Tráfego.
- Selecione o ponto final que pretende configurar.
- Em Verificações de Estado de Funcionamento, selecione Servir sempre o tráfego.
- Selecione Guardar.
Veja o seguinte exemplo:
Nota
- As verificações de estado de funcionamento não podem ser desativadas em perfis aninhados do Gestor de Tráfego.
- Um ponto final tem de estar ativado para configurar as verificações de estado de funcionamento.
- Ativar e desativar um ponto final não repõe a configuração de Verificações de Estado de Funcionamento .
- Os pontos finais configurados para servir sempre o tráfego são faturados para verificações básicas do estado de funcionamento.
FAQs
- O Gestor de Tráfego é resiliente a falhas na região do Azure?
- Como é que a escolha da localização do grupo de recursos afeta o Gestor de Tráfego?
- Como devo proceder para determinar o estado de funcionamento atual de cada ponto final?
- Posso monitorizar pontos finais HTTPS?
- Utilizo um endereço IP ou um nome DNS ao adicionar um ponto final?
- Que tipos de endereços IP posso utilizar ao adicionar um ponto final?
- Posso utilizar diferentes tipos de endpoint addressing num único perfil?
- O que acontece quando o tipo de registo de uma consulta recebida é diferente do tipo de registo associado ao tipo de endereçamento dos pontos finais?
- Posso utilizar um perfil com pontos finais endereçados IPv4/IPv6 num perfil aninhado?
- Parei um ponto final de aplicação Web no meu perfil do Gestor de Tráfego, mas não estou a receber tráfego mesmo depois de o reiniciar. Como posso corrigir este problema?
- Posso utilizar o Gestor de Tráfego mesmo que a minha aplicação não tenha suporte para HTTP ou HTTPS?
- Que respostas específicas são necessárias do ponto final ao utilizar a monitorização TCP?
- Quão rápido é que o Gestor de Tráfego afasta os meus utilizadores de um ponto final em mau estado de funcionamento?
- Como posso especificar diferentes definições de monitorização para diferentes pontos finais num perfil?
- Como posso atribuir cabeçalhos HTTP às verificações de estado de funcionamento do Gestor de Tráfego aos meus pontos finais?
- Que cabeçalho de anfitrião utiliza as verificações de estado de funcionamento dos pontos finais?
- Quais são os endereços IP a partir dos quais as verificações de estado de funcionamento têm origem?
- Quantas verificações de estado de funcionamento para o meu ponto final posso esperar do Gestor de Tráfego?
- Como posso ser notificado se um dos meus pontos finais ficar inativo?
Passos seguintes
- Saiba como funciona o Gestor de Tráfego
- Saiba mais sobre os métodos de encaminhamento de tráfego suportados pelo Gestor de Tráfego
- Saiba como criar um perfil do Gestor de Tráfego
- Resolver problemas do estado Degradado num ponto final do Gestor de Tráfego