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. O Traffic Manager permite, por defeito, a monitorização dos endpoints. Para desativar a monitorização, consulte Ativar ou desativar verificações de integridade.

Configurar o monitoramento de pontos finais

Especifique as seguintes definições no seu perfil do Gestor de Tráfego para configurar a monitorização dos endpoints:

  • Protocolo. Escolha HTTP, HTTPS ou TCP como o protocolo que o Traffic Manager utiliza para testar o estado de funcionamento do seu ponto final. O monitoramento HTTPS não verifica se seu certificado TLS/SSL é válido, apenas verifica se o certificado está presente.

Nota

O suporte do Traffic Manager para TLS 1.0 e 1.1 terminou em 28 de fevereiro de 2025. Para obter mais informações, consulte Perguntas frequentes sobre o TLS do Gerenciador de Tráfego.

  • Porto. Escolha a porta usada para a solicitação.
  • Caminho. Esta definição de configuração é válida apenas para os protocolos HTTP e HTTPS, para os quais é necessário especificar a definição de caminho. Esta configuração causa um erro no protocolo de monitorização TCP. Para o protocolo HTTP e HTTPS, forneça o caminho relativo e o nome da página da Web ou do arquivo que o monitoramento acessa. Uma barra oblíqua / é um valor válido para o caminho relativo. Esse valor implica que o arquivo está no diretório raiz (padrão).
  • Configuraçõ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 de extremidade num perfil. Os cabeçalhos personalizados podem ser especificados ao nível do perfil, para se aplicarem a todos os pontos finais desse perfil, e/ou ao nível do ponto final, aplicando-se apenas a esse ponto final. Pode utilizar cabeçalhos personalizados para verificações do estado de funcionamento de endpoints num ambiente multi-inquilino. Dessa forma, ele pode ser roteado corretamente para seu destino especificando um cabeçalho de host. Você também pode usar essa configuração adicionando cabeçalhos exclusivos que podem ser usados para identificar solicitações HTTP(S) originadas pelo Gerenciador de Tráfego e processá-las de forma diferente. Você pode especificar até oito header:value pares separados por uma vírgula. Por exemplo, header1:value1, header2:value2.

Nota

Não há suporte para o uso de caracteres asterisco (*) em cabeçalhos personalizados Host .

  • Intervalos de códigos de status esperados. Essa configuração permite especificar vários intervalos de códigos de sucesso no formato 200-299, 301-301. Se estes códigos de estado forem recebidos como resposta de um ponto final durante uma verificação de estado de funcionamento, o Traffic Manager marcará esses pontos finais como saudáveis. Você pode especificar um máximo de oito intervalos de códigos de status. Essa configuração é aplicável somente aos protocolos HTTP e HTTPS e a todos os pontos de extremidade. Essa configuração está no nível de perfil do Gerenciador de Tráfego e, por padrão, o valor 200 é definido como o código de status de sucesso.
  • Intervalo de sondagem. Este valor especifica com que frequência um ponto final é verificado quanto ao seu estado de funcionamento por um agente de teste do Traffic Manager. Você pode especificar dois valores aqui: 30 segundos (sondagem normal) e 10 segundos (sondagem rápida). Se nenhum valor for fornecido, o perfil será definido como um valor padrão de 30 segundos. Visite a página de preços do Traffic Manager para saber mais sobre preços de sondagem rápida.
  • Número tolerado de falhas. Este valor especifica quantas falhas um agente de sondagem do Gestor de Tráfego tolera antes de marcar essa extremidade como não operacional. Seu valor pode variar entre 0 e 9. Um valor de 0 significa que uma única falha de monitorização pode fazer com que essa extremidade seja marcada como não operacional. Se nenhum valor for especificado, ele usará o valor padrão de 3.
  • Tempo esgotado na sondagem. Esta propriedade especifica a quantidade de tempo que o agente de sondagem do Gerenciador de Tráfego deve aguardar antes de considerar uma verificação de teste de integridade para um ponto de extremidade uma falha. Se o intervalo de sondagem estiver definido como 30 segundos, você poderá definir o valor de tempo limite entre 5 e 10 segundos. Se nenhum valor for especificado, ele usará um valor padrão de 10 segundos. Se o intervalo de sondagem estiver definido como 10 segundos, você poderá definir o valor de tempo limite entre 5 e 9 segundos. Se nenhum valor de tempo limite for especificado, ele usará um valor padrão de 9 segundos.

Captura de ecrã das definições de configuração do endpoint de monitorização do Traffic Manager no portal Azure.

Figura: Monitoramento de pontos finais do Gerenciador de Tráfego

Como funciona o monitoramento de endpoints

Quando o protocolo de monitoramento é definido como HTTP ou HTTPS, o agente de sondagem do Gerenciador de Tráfego faz uma solicitação GET para o ponto de extremidade usando o protocolo, a porta e o caminho relativo fornecidos. O Gestor de Tráfego considera um endpoint saudável se o agente sondador receber uma resposta de 200 OK, ou qualquer uma das respostas configuradas nos intervalos de códigos de estado esperados. Se a resposta tiver um valor diferente ou não for recebida dentro do período de tempo limite, o agente de sondagem do Gestor de Tráfego irá repetir de acordo com a definição do Número Tolerado de Falhas. Nenhuma nova tentativa será feita se essa configuração for 0. O ponto final é marcado como não saudável se o número de falhas consecutivas for superior à definição Número tolerado de falhas.

Quando o protocolo de monitoramento é TCP, o agente de sondagem do Gerenciador de Tráfego cria uma solicitação de conexão TCP usando a porta especificada. Se a extremidade responder ao pedido com uma resposta para estabelecer a ligação, essa verificação de estado de funcionamento será considerada bem-sucedida. O agente de sondagem do Traffic Manager redefine a conexão TCP. Nos casos em que a resposta é de um valor diferente ou não é recebida resposta dentro do tempo limite, o agente de sondagem do Gestor de Tráfego volta a tentar de acordo com a definição Número tolerado de falhas. Nenhuma nova tentativa será feita se essa configuração for 0. Se o número de falhas consecutivas for superior à definição Número tolerado de falhas, essa extremidade será marcada como não operacional.

Em todos os casos, o Traffic Manager investiga a partir de vários locais. A falha consecutiva determina o que acontece dentro de cada região. É por isso que os pontos finais estão a receber sondagens de estado de funcionamento do Traffic Manager com uma frequência superior à configurada para o Intervalo de Sondagem.

Nota

Para o protocolo de monitorização HTTP ou HTTPS, uma prática comum do lado do endpoint é implementar uma página personalizada na sua aplicação — por exemplo, /health.aspx. Use este caminho para realizar verificações específicas da aplicação, como verificar contadores de desempenho ou verificar a disponibilidade da base de dados. Com base nessas verificações personalizadas, a página retorna um código de status HTTP apropriado.

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

Estado do ponto final e do perfil

Ative ou desative os perfis e endpoints do Gestor de Tráfego conforme necessário. No entanto, o estado do endpoint também pode mudar devido às definições e processos automatizados do Traffic Manager.

Estado do ponto final

Você pode habilitar ou desabilitar um ponto de extremidade específico. O serviço subjacente, que ainda pode estar saudável, não é afetado. A alteração do status do ponto de extremidade controla a disponibilidade do ponto de extremidade no perfil do Gerenciador de Tráfego. Quando o estado de um ponto final está desativado, o Gestor de Tráfego não verifica o respetivo estado de funcionamento e o ponto final não é incluído numa resposta DNS.

Status do perfil

Usando a configuração de status do perfil, você pode habilitar ou desabilitar um perfil específico. Enquanto o status do ponto de extremidade afeta um único ponto de extremidade, o status do perfil afeta todo o perfil, incluindo todos os pontos de extremidade. Quando desativa um perfil, os pontos finais não são verificados quanto ao estado de funcionamento e nenhum ponto final é incluído numa resposta DNS. É devolvido um código de resposta NXDOMAIN para a consulta DNS.

Estado da monitorização de dispositivos terminais

O estado do monitor do ponto final é um valor gerado pelo Gestor de Tráfego que mostra o estado do ponto final. Não é possível alterar essa configuração manualmente. O estado do monitor do ponto final é uma combinação entre os resultados da monitorização do ponto final e o estado configurado do ponto final. Os valores possíveis do status do monitor de ponto final são mostrados na tabela a seguir:

Status do perfil Estado do ponto final Estado da monitorização de dispositivos terminais Notas
Desabilitado Ativado Inativos O perfil foi desativado. Embora o estado do ponto final seja Ativado, o estado do perfil (Desativado) tem precedência. Os terminais em perfis desativados não são monitorizados. Um código de resposta NXDOMAIN é retornado para a consulta DNS.
<qualquer> Desabilitado Desabilitado O endpoint foi desativado. Os endpoints desativados não são monitorizados. O ponto de extremidade não está incluído nas respostas DNS, como tal, não recebe tráfego.
Ativado Ativado Online O endpoint é monitorizado e está operacional. Está incluído nas respostas DNS e pode receber tráfego.
Ativado Ativado Degradado As verificações de integridade do monitoramento de ponto final estão falhando. O ponto terminal não é incluído nas respostas DNS e não recebe tráfego.
Uma exceção é se todos os pontos de extremidade estiverem degradados. Nesse caso, todos eles são considerados retornados na resposta da consulta.
Ativado Ativado CheckingEndpoint O endpoint é monitorado, mas os resultados da primeira sonda ainda não foram recebidos. CheckingEndpoint é um estado temporário que geralmente ocorre logo após adicionar ou ativar um endpoint no perfil. Um ponto de extremidade nesse estado é incluído nas respostas DNS e pode receber tráfego.
Ativado Ativado Parado A aplicação web para a qual o ponto final aponta não está em execução. Verifique as configurações do aplicativo Web. Este estado também pode acontecer se o endpoint for do tipo endpoint aninhado e o perfil filho estiver desativado ou inativo.
Uma extremidade com o estado Parado não é monitorizada. Ele não está incluído nas respostas DNS e não recebe tráfego. Uma exceção é se todos os pontos de extremidade estiverem degradados. Nesse caso, todos eles são considerados retornados na resposta da consulta.
Ativado Ativado Não monitorizado O ponto de extremidade está configurado para sempre servir tráfego. As verificações de integridade não estão habilitadas.

Para mais detalhes sobre como é calculado o estado de monitorização do ponto final para pontos finais aninhados, consulte Perfis aninhados do Gestor de Tráfego.

Nota

Pode ocorrer um estado do monitor de ponto final como Parado no App Service se a sua aplicação Web não estiver em execução no escalão Standard ou superior. Para obter mais informações, consulte Integração do Gerenciador de Tráfego com o Serviço de Aplicativo.

Status do monitor de perfil

O estado de monitorização do perfil é uma combinação do estado do perfil configurado e dos valores de estado de monitorização de todos os endpoints. Os valores possíveis são descritos na tabela a seguir:

Status do perfil (conforme configurado) Estado da monitorização de dispositivos terminais Status do monitor de perfil Notas
Desabilitado <qualquer> ou um perfil sem pontos finais definidos. Desabilitado O perfil foi desativado.
Ativado O estado de pelo menos uma extremidade está Degradado. Degradado Analise os valores individuais do status do endpoint para determinar quais endpoints requerem mais atenção.
Ativado O estado de pelo menos um terminal está online. Nenhum terminal tem o estado Degradado. Online O serviço está aceitando tráfego. Não são necessárias mais ações.
Ativado O estado de, pelo menos, um ponto final é CheckingEndpoint. Nenhum terminal está no estado Online ou Degradado. Verificação de Endpoints Este estado de transição ocorre quando um perfil é criado ou ativado. A integridade do endpoint está sendo verificada pela primeira vez.
Ativado Os estados de todos os pontos finais no perfil são Desativados ou Parados, ou o perfil não tem pontos finais definidos. Inativos Nenhum ponto de extremidade está ativo, mas o perfil ainda está habilitado.

Ativação pós-falha e recuperação do ponto final

O Gestor de Tráfego verifica periodicamente o estado de cada extremidade, incluindo as extremidades não saudáveis. O Traffic Manager deteta quando um ponto de extremidade se torna íntegro e o coloca de volta à rotação.

Uma extremidade é considerada não saudável quando ocorre um dos seguintes eventos:

  • Se o protocolo de monitorização for HTTP ou HTTPS:
    • Recebe-se uma resposta que não seja 200, ou uma resposta que não inclua o intervalo de estado especificado na definição de 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:
    • Recebe-se uma resposta diferente de ACK ou SYN-ACK em resposta ao pedido SYN enviado pelo Gestor de Tráfego para tentar estabelecer uma ligação.
  • Tempo esgotado.
  • Qualquer outro problema de ligação que torne a extremidade inacessível.

Para obter mais informações sobre como solucionar problemas de verificações com falha, consulte Solução de problemas de status degradado no Gerenciador de Tráfego do Azure.

A cronologia apresentada na figura seguinte é uma descrição detalhada do processo de monitorização do ponto de extremidade do Traffic Manager com as seguintes definições:

  • O protocolo de monitoramento é HTTP.
  • O intervalo de sondagem é de 30 segundos.
  • O número de falhas toleradas é 3.
  • O valor de tempo limite é de 10 segundos.
  • DNS TTL é de 30 segundos.

Captura de ecrã do cronograma de sequência de failover e failback do Traffic Manager.

Figura: Sequência de failover e recuperação do endpoint do gestor de tráfego

  1. GET. Para cada ponto de extremidade, o sistema de monitoramento do Gerenciador de Tráfego faz uma solicitação GET no caminho especificado nas configurações de monitoramento.

  2. Definições de monitorização do perfil do Traffic Manager para 200 OK ou intervalo de códigos personalizado especificado O sistema de monitoramento espera que um HTTP 200 OK ou um código de status no intervalo especificado nas configurações de monitoramento seja retornado dentro de 10 segundos. Quando recebe essa resposta, reconhece que o serviço está disponível.

  3. 30 segundos entre as verificações. A verificação de integridade do endpoint é repetida a cada 30 segundos.

  4. Serviço indisponível. O serviço fica indisponível. O Traffic Manager não saberá até a próxima verificação de integridade.

  5. Tentativas de acesso ao caminho de monitorização. O sistema de monitoramento faz uma solicitação 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á redefinido.

  6. Status definido como Degradado. Após uma quarta falha consecutiva, o sistema de monitoramento marca o status do ponto final indisponível como Degradado.

  7. O tráfego é desviado para outros pontos finais. Os servidores de nomes DNS do Traffic Manager são atualizados e o Traffic Manager não retorna mais o ponto de extremidade em resposta a consultas DNS. As novas conexões são direcionadas para outras extremidades disponíveis. No entanto, as respostas DNS anteriores que incluem esta extremidade podem ainda estar armazenadas em cache por servidores DNS recursivos e clientes DNS. Os clientes continuam a usar o ponto final até que a cache de DNS expire. À medida que o cache DNS expira, os clientes fazem novas consultas DNS e são direcionados para diferentes pontos de extremidade. A duração do cache é controlada pela configuração TTL no perfil do Gerenciador de Tráfego, por exemplo, 30 segundos.

  8. Os controlos de saúde continuam. O Traffic Manager continua a verificar o estado de funcionamento do ponto final enquanto este tiver o estado Degradado. O Traffic Manager deteta quando o ponto final volta a um estado saudável.

  9. 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 efetue a verificação seguinte do estado de funcionamento.

  10. O tráfego para o serviço é retomado. O Gerenciador de Tráfego envia uma solicitação GET e recebe uma resposta de status 200 OK. O serviço voltou a um estado saudável. Os servidores de nomes do Traffic Manager são atualizados e começam a fornecer o nome DNS do serviço nas respostas DNS. O tráfego retorna ao ponto de extremidade à medida que as respostas DNS armazenadas em cache que retornam outros pontos de extremidade expiram e as conexões existentes com outros pontos de extremidade terminam.

    Importante

    O gestor de tráfego implementa várias sondas a partir de várias localizações para cada ponto final. Várias sondas aumentam a resiliência na monitorização de endpoints. O gestor de tráfego agrega o estado de funcionamento médio das sondas em vez de depender de uma única instância de sonda. A redundância do sistema de sondagem é por design. Os valores dos parâmetros de avaliação final devem ser analisados de forma holística e não por sonda. O número exibido para a integridade da sonda é uma média. O estado só deve ser motivo de preocupação se menos de 50% (0,5) das sondas indicarem o estado ativo.

    Nota

    Como o Gerenciador de Tráfego funciona no nível DNS, ele não pode influenciar as conexões existentes com nenhum ponto de extremidade. Quando direciona o tráfego entre pontos de extremidade (seja devido a alterações das definições do perfil ou durante failover ou failback), o Gestor de Tráfego direciona novas ligações para os pontos de extremidade disponíveis. Outros pontos de extremidade podem continuar a receber tráfego por meio de conexões existentes até que essas sessões sejam encerradas. Para permitir que o tráfego seja drenado das conexões existentes, os aplicativos devem limitar a duração da sessão usada com cada ponto de extremidade.

Métodos de roteamento de tráfego

Quando um ponto de extremidade tem um status Degradado , ele não é mais retornado em resposta a consultas DNS. Em vez disso, um ponto de extremidade alternativo é escolhido e retornado. O método de roteamento de tráfego configurado no perfil determina como o ponto de extremidade alternativo é escolhido.

  • Prioridade. Os pontos de extremidade estabelecem uma lista de prioridades. O primeiro endpoint disponível na lista é sempre devolvido. Se um status de ponto de extremidade for Degradado, o próximo ponto de extremidade disponível será retornado.
  • 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 endpoint mais próximo do utilizador final. Se esse ponto de extremidade não estiver disponível, o Gerenciador de Tráfego moverá o tráfego para os pontos de extremidade na próxima região do Azure mais próxima. Você pode configurar planos de failover alternativos para roteamento de tráfego de desempenho usando perfis aninhados do Gerenciador de Tráfego.
  • Geográfico. É devolvido o terminal mapeado para fornecer a localização geográfica (com base nos endereços IP do pedido de consulta). Se esse ponto de extremidade não estiver disponível, outro ponto de extremidade não será selecionado para failover, uma vez que um local geográfico pode ser mapeado apenas para um ponto de extremidade em um perfil. (Mais detalhes estão no Perguntas frequentes). Como boa prática, ao utilizar o encaminhamento geográfico, recomendamos que os clientes utilizem perfis Traffic Manager aninhados com mais de um ponto final como pontos finais do perfil.
  • MultiValue São devolvidos múltiplos endpoints mapeados para endereços IPv4/IPv6. Quando é recebida uma consulta para esse perfil, são devolvidos pontos finais em bom estado com base no valor de Número máximo de registos na resposta que especificou. O número predefinido de endpoints de resposta é dois.
  • Sub-rede É devolvido o ponto terminal associado a um conjunto de intervalos de endereços IP. Quando uma solicitação é recebida desse endereço IP, o ponto de extremidade retornado é aquele mapeado para esse endereço IP. 

Para obter mais informações, consulte Métodos de roteamento de tráfego do Gerenciador de Tráfego.

Nota

Uma exceção ao comportamento normal de roteamento de tráfego ocorre quando todos os pontos de extremidade qualificados têm um status degradado. O Gestor de Tráfego envida os "melhores esforços" e responde como se todos os pontos finais com estado Degradado estivessem efetivamente online. Esse comportamento é preferível à alternativa, que seria não retornar nenhum ponto de extremidade na resposta DNS. As extremidades desativadas ou paradas não são monitorizadas; por conseguinte, não são consideradas elegíveis para tráfego.

Essa condição geralmente é causada pela configuração incorreta do serviço, como:

  • Uma lista de controle de acesso [ACL] bloqueando as verificações de integridade do Gerenciador de Tráfego.
  • Uma configuração incorreta da porta ou protocolo de monitoramento no perfil do gerenciador de tráfego.

A consequência desse comportamento é que, se as verificações de integridade do Gerenciador de Tráfego não estiverem configuradas corretamente, ele pode aparecer no roteamento de tráfego como se o Gerenciador de Tráfego estivesse funcionando corretamente. No entanto, nesse caso, o failover de ponto de extremidade não pode acontecer, o que afeta a disponibilidade geral do aplicativo. É importante verificar se o perfil mostra um status Online, não um status Degradado. Um status Online indica que as verificações de integridade do Gerenciador de Tráfego estão funcionando conforme o esperado.

Para obter mais informações sobre como resolver problemas de verificações de estado de funcionamento falhadas, consulte Resolução de problemas do estado degradado no Gestor de Tráfego do Azure.

Ativar ou desativar verificações de integridade

O Gestor de Tráfego do Azure permite ativar ou desativar as verificações de saúde dos endpoints. Para desativar a monitorização, escolha a opção Sempre servir o tráfego.

Há duas configurações disponíveis para verificações de integridade:

  1. Ativar (verificações de integridade). O tráfego é encaminhado para o ponto final com base no estado de funcionamento. Esta é a predefinição.
  2. Sirva sempre o trânsito. Essa configuração desabilita as verificações de integridade.

Sirva sempre

Quando Servir sempre tráfego está selecionado, a monitorização é ignorada e o tráfego é sempre enviado para um ponto de extremidade. O status do monitor de ponto de extremidade exibido é Não monitorado.

Para habilitar o Always Serve:

  1. Selecione Pontos de extremidade na seção Configurações da folha de perfil do Gerenciador de Tráfego.
  2. Selecione o ponto de extremidade que você deseja configurar.
  3. Em Verificações de Integridade, escolha Servir sempre tráfego.
  4. Selecione Guardar.

Veja o seguinte exemplo:

Captura de ecrã das opções de configuração das verificações de saúde do endpoint.

Nota

  • As verificações de integridade não podem ser desabilitadas em perfis aninhados do Gerenciador de Tráfego.
  • Um ponto de extremidade deve estar habilitado para configurar verificações de integridade.
  • Ativar e desativar um terminal não repõe a configuração das Verificações de Integridade.
  • Os endpoints configurados para servir sempre tráfego são faturados pelas verificações básicas de integridade.

Nota

As sondas de saúde do Gestor de Tráfego do Azure são concebidas para monitorizar endpoints que são acessíveis pela infraestrutura de sondagem do Traffic Manager. O Traffic Manager não foi concebido para sondar endpoints que resolvem endereços dentro de espaços privados, não roteáveis ou internos da Microsoft.

Os endpoints que resolvem para endereços dentro destes espaços de rede devem ser configurados como Always serve traffic endpoints. O Traffic Manager não consegue realizar validação de saúde para estes endpoints e, por isso, não pode fornecer failover baseado em saúde.

Para garantir um comportamento consistente, o Traffic Manager impõe a configuração Always serve traffic para endpoints que correspondem a endereços em espaços de rede não suportados.

Configuração de firewall para verificações de integridade

O Gestor de Tráfego do Azure depende de sondas de integridade para monitorizar a disponibilidade e o desempenho dos endpoints. Para que as sondas sejam bem-sucedidas, os endpoints devem estar acessíveis e todos os firewalls ou listas de controle de acesso (ACLs) no caminho devem permitir o tráfego de todos de todos os endereços IP do Traffic Manager. Se os endereços IP dos probes não forem permitidos, os testes de saúde poderão falhar. Os pontos de extremidade marcados como não saudáveis podem causar redirecionamento de tráfego inesperado ou tempo de interrupção.

Opção 1: Usar etiquetas de serviço (recomendado) A abordagem recomendada é usar a Marca de Serviço AzureTrafficManager em NSGs ou Firewall do Azure. As Etiquetas de Serviço incluem automaticamente os intervalos de IP mais recentes e não requerem atualizações manuais.

Opção 2: Atualizar manualmente as regras de firewall Se as Etiquetas de Serviço não puderem ser usadas (por exemplo, com dispositivos de firewall personalizados ou em ambientes que não sejam do Azure), atualize as ACLs ou as regras de firewall para permitir os IPs mais recentes do Gerenciador de Tráfego do Azure.

Perguntas frequentes

Próximos passos

  • Last updated on