Testes de disponibilidade do Application Insights

O Application Insights permite a configuração de testes web recorrentes que monitoram a disponibilidade e a capacidade de resposta do seu site ou aplicativo de vários pontos ao redor do mundo. Esses testes de disponibilidade enviam solicitações da Web para seu aplicativo em intervalos regulares e o alertarão se o aplicativo não estiver respondendo ou se o tempo de resposta for muito lento.

Os testes de disponibilidade não exigem modificações no site ou aplicativo que você está testando. Eles funcionam para qualquer ponto de extremidade HTTP ou HTTPS acessível pela Internet pública, incluindo APIs REST das quais seu serviço depende. Isso significa que você pode monitorar não apenas seus aplicativos, mas também serviços externos que são essenciais para a funcionalidade do aplicativo. Você pode criar até 100 testes de disponibilidade por recurso do Application Insights.

Tipos de testes de disponibilidade

Há quatro tipos de testes de disponibilidade:

• Teste padrão: um tipo de teste de disponibilidade que verifica a disponibilidade de um site enviando uma única solicitação, semelhante ao teste de ping de URL preterido. Além de validar se um ponto de extremidade está respondendo e medindo o desempenho, os testes Padrão também incluem a validade de certificado TLS/SSL, a verificação da vida útil proativa, verbo de solicitação HTTP (por exemplo,GET, HEAD e POST), cabeçalhos personalizados e dados personalizados associados à sua solicitação HTTP.

  Saiba como criar um teste padrão.

• Testes de TrackAvailability personalizado: se você decidir criar um aplicativo personalizado para executar testes de disponibilidade, poderá usar o método TrackAvailability() para enviar os resultados para o Application Insights.

  Saiba como criar um teste de TrackAvailability personalizado.

• (Preterido) Teste na Web de várias etapas:: você pode reproduzir a gravação de uma sequência de solicitações da Web para testar cenários mais complexos. Os testes na Web de várias etapas são criados no Visual Studio Enterprise e carregados no portal para execução.

• (Preterido): Teste de ping de URL: você pode criar esse teste por meio do portal do Azure para validar se um ponto de extremidade está respondendo e medir o desempenho associado a essa resposta. Você também pode definir critérios de êxito personalizados associados a recursos mais avançados, como a análise de solicitações dependentes, além de permitir novas tentativas.

Criar um Conjunto de Disponibilidade

Alertas de disponibilidade

Os alertas são automaticamente habilitados por padrão, mas, para configurar um alerta completamente, é necessário inicialmente criar o teste de disponibilidade.

Marcas de população de local

Você pode usar as marcas de população a seguir para o atributo de localização geográfica ao implantar um teste padrão ou um teste de ping de URL usando o Azure Resource Manager.

Habilitar alertas

1. Depois de salvar o teste de disponibilidade, abra o menu de contexto pelo teste que você fez e, em seguida, selecione a página Abrir Regras (Alertas).

   

2. Na página Regras de alerta, abra o alerta e selecione Editar na barra de navegação superior. Aqui você pode definir o nível de gravidade, descrição da regra e o grupo de ação que tem as preferências de notificação que você deseja usar para essa regra de alerta.

   

Critérios do alerta

Os alertas de disponibilidade habilitados automaticamente disparam um email quando o ponto de extremidade fica indisponível e outro email quando ele está disponível novamente. Os alertas de disponibilidade criados por meio dessa experiência são baseados em estado. Quando os critérios de alerta são atendidos, um só alerta é gerado quando o site é detectado como indisponível. Se o site ainda estiver inoperante na próxima vez que os critérios do alerta forem avaliados, isso não gerará um novo alerta.

Por exemplo, suponha que seu site esteja inoperante por uma hora e você tenha configurado um alerta de email com uma frequência de avaliação de 15 minutos. Você só recebe um email quando o site ficar inoperante e um outro email quando estiver de volta online. Você não recebe alertas contínuos a cada 15 minutos para lembrá-lo que o site ainda não está disponível.

Alterar os critérios de alerta

Talvez você não queira receber notificações quando o site estiver inoperante por apenas um curto período de tempo, por exemplo, durante a manutenção. Você pode alterar a frequência de avaliação para um valor maior do que o tempo de inatividade esperado, até 15 minutos. Você também pode aumentar o limite de localização do alerta, de modo que ele só dispare um alerta se o site estiver inoperante para um determinado número de regiões.

Para fazer alterações no limite de localização, no período de agregação e na frequência de teste, vá para a página Editar regra de alerta (consulte a etapa 2 em Habilitar alertas) e selecione a condição para abrir a janela Configurar lógica de sinal.

Criar uma regra de alerta personalizada

Se você precisar de recursos avançados, pode criar uma regra de alerta personalizada na guia Alertas. Selecione Criar>Regra de alerta. Escolha Métricas em Tipo de sinal para mostrar todos os sinais disponíveis e selecione Disponibilidade.

Uma regra de alerta personalizada oferece valores mais altos para o período de agregação (até 24 horas, em vez de 6 horas) e a frequência de teste (até 1 hora, em vez de 15 minutos). Ela também adiciona opções para definir ainda mais a lógica, selecionando diferentes operadores, tipos de agregação e valores de limite.

• Alerta em X de Y locais relatando falhas: a regra de alerta de X de Y locais fica habilitada por padrão na experiência de novos alertas unificados quando você cria um teste de disponibilidade. Você pode recusá-la selecionando a opção “clássica” ou optar por desabilitar a regra de alerta. Configure os grupos de ação para receber notificações quando o alerta for disparado, seguindo as etapas acima. Sem essa etapa, você só recebe notificações no portal quando a regra for disparada.

• Alerta em métricas de disponibilidade: usando os novos alertas unificados, você pode alertar sobre a disponibilidade de agregação segmentada e métricas de duração de teste:

  1. Selecione um recurso do Application Insights na experiência de Métricas e selecione uma métrica de Disponibilidade.

  2. A opção Configurar alertas do menu leva você para a nova experiência, de onde você pode selecionar testes ou locais específicos para configurar regras de alerta. Você também pode configurar os grupos de ação para esta regra de alerta aqui.

• Alerta em consultas de análise personalizadas: usando os novos alertas unificados, você pode alertar sobre consultas de log personalizado. Com consultas personalizadas, você pode alertar sobre qualquer critério arbitrário que ajuda você a obter o sinal de mais confiável dos problemas de disponibilidade. Isso também é aplicável se você estiver enviando resultados personalizados de disponibilidade usando o SDK TrackAvailability.

  As métricas sobre dados de disponibilidade incluem resultados de disponibilidade personalizados que podem ser enviados chamando o SDK TrackAvailability. Você pode usar os alertas de suporte a métricas para alertar sobre resultados de disponibilidade personalizado.

Automatizar alertas

Para automatizar esse processo com modelos do Azure Resource Manager, veja Criar um alerta de métrica com um modelo do Azure Resource Manager.

Ver os resultados de teste de disponibilidade

Esta seção explica como revisar os resultados do teste de disponibilidade no portal do Azure e consultar os dados por meio do Log Analytics. Os resultados do teste de disponibilidade podem ser visualizados com as exibições de Linha e Gráfico de Dispersão.

Verificar a disponibilidade

Comece examinando o grafo na experiência de Disponibilidade no portal do Azure.

Por padrão, a experiência de Disponibilidade mostra um grafo de linha. Altere o modo de exibição para Gráfico de Dispersão (alternância acima do grafo) para ver exemplos dos resultados do teste que têm detalhes de etapa de teste de diagnóstico neles. O mecanismo de teste armazena detalhes de diagnóstico para testes com falhas. Para testes bem-sucedidos, detalhes de diagnóstico são armazenados para um subconjunto das execuções. Para ver o teste, o nome do teste e o local, passe o mouse sobre qualquer um dos pontos verdes ou cruzes vermelhas.

Selecione um teste ou local específico. Ou você pode reduzir o período para ver mais resultados em torno do período de interesse. Use o Gerenciador de Pesquisa para ver os resultados de todas as execuções. Ou você pode usar as consultas do Log Analytics para executar relatórios personalizados sobre esses dados.

Para ver os detalhes da transação de ponta a ponta, em Analisar em, selecione Êxito ou Falha. Em seguida, selecione uma amostra. Você também pode obter os detalhes da transação de ponta a ponta selecionando um ponto de dados no grafo.

Como inspecionar e editar testes

Para editar, desabilitar temporariamente ou excluir um teste, abra o menu de contexto (reticências) pelo teste e selecione Editar. Pode levar até 20 minutos para que as alterações da configuração sejam propagadas para todos os agentes de teste após a alteração ser feita.

Se você encontrar falhas

Abra a Exibição de detalhes da transação de ponta a ponta selecionando uma cruz vermelha no Gráfico de Dispersão.

Aqui, você pode ver:

• Examine o Relatório de Solução de Problemas para determinar o que potencialmente causou a falha do teste.
• Inspecionar a resposta recebida do servidor.
• Diagnosticar falha na telemetria do lado do servidor correlacionado coletada durante o processamento do teste de disponibilidade com falha.
• Acompanhe o problema registrando um problema ou item de trabalho no Git ou no Azure Boards. O bug contém um link para o evento no portal do Azure.
• Abrir o resultado do teste na Web no Visual Studio.

Para saber mais sobre a experiência de diagnóstico de transações de ponta a ponta, consulte a documentação do diagnóstico de transações.

Selecione a linha de exceção para ver os detalhes da exceção do lado servidor que causou a falha no teste de disponibilidade sintético. Você também pode obter o instantâneo de depuração para ter um diagnóstico mais detalhado com códigos.

Além dos resultados brutos, você também pode exibir duas métricas principais de disponibilidade no explorador de métricas:

• Disponibilidade: percentual dos testes que foram bem-sucedidos em todas as execuções de teste.
• Duração do teste: duração média em todas as execuções de teste.

Consulta no Log Analytics

Você pode usar o Log Analytics para ver os resultados de disponibilidade (availabilityResults), as dependências (dependencies) e muito mais. Para saber mais sobre o Log Analytics, confira Visão geral de consultas de log.

Migrar testes de ping de URL clássicos para testes padrão

As etapas a seguir explicam o processo de criação de testes padrão que replicam a funcionalidade dos testes de ping de URL. Ele permite que você comece com mais facilidade usando os recursos avançados de testes padrão usando seus testes de ping de URL criados anteriormente.

Pré-requisitos

Introdução

1. Conecte-se à sua assinatura do Azure com o Azure PowerShell (Connect-AzAccount + Set-AzContext).

2. Listar todos os testes de ping de URL na assinatura atual:

   Get-AzApplicationInsightsWebTest | `
   Where-Object { $_.WebTestKind -eq "ping" } | `
   Format-Table -Property ResourceGroupName,Name,WebTestKind,Enabled;
   

3. Localize o teste de ping de URL que você deseja migrar e registre seu nome e grupo de recursos.

4. Crie um teste padrão com a mesma lógica que o teste de ping de URL usando os comandos a seguir, que funcionam para pontos de extremidade HTTP e HTTPS.

   $resourceGroup = "pingTestResourceGroup";
   $appInsightsComponent = "componentName";
   $pingTestName = "pingTestName";
   $newStandardTestName = "newStandardTestName";
   
   $componentId = (Get-AzApplicationInsights -ResourceGroupName $resourceGroup -Name $appInsightsComponent).Id;
   $pingTest = Get-AzApplicationInsightsWebTest -ResourceGroupName $resourceGroup -Name $pingTestName;
   $pingTestRequest = ([xml]$pingTest.ConfigurationWebTest).WebTest.Items.Request;
   $pingTestValidationRule = ([xml]$pingTest.ConfigurationWebTest).WebTest.ValidationRules.ValidationRule;
   
   $dynamicParameters = @{};
   
   if ($pingTestRequest.IgnoreHttpStatusCode -eq [bool]::FalseString) {
   $dynamicParameters["RuleExpectedHttpStatusCode"] = [convert]::ToInt32($pingTestRequest.ExpectedHttpStatusCode, 10);
   }
   
   if ($pingTestValidationRule -and $pingTestValidationRule.DisplayName -eq "Find Text" `
   -and $pingTestValidationRule.RuleParameters.RuleParameter[0].Name -eq "FindText" `
   -and $pingTestValidationRule.RuleParameters.RuleParameter[0].Value) {
   $dynamicParameters["ContentMatch"] = $pingTestValidationRule.RuleParameters.RuleParameter[0].Value;
   $dynamicParameters["ContentPassIfTextFound"] = $true;
   }
   
   New-AzApplicationInsightsWebTest @dynamicParameters -ResourceGroupName $resourceGroup -Name $newStandardTestName `
   -Location $pingTest.Location -Kind 'standard' -Tag @{ "hidden-link:$componentId" = "Resource" } -TestName $newStandardTestName `
   -RequestUrl $pingTestRequest.Url -RequestHttpVerb "GET" -GeoLocation $pingTest.PropertiesLocations -Frequency $pingTest.Frequency `
   -Timeout $pingTest.Timeout -RetryEnabled:$pingTest.RetryEnabled -Enabled:$pingTest.Enabled `
   -RequestParseDependent:($pingTestRequest.ParseDependentRequests -eq [bool]::TrueString);
   

   O novo teste padrão não tem regras de alerta por padrão, portanto, ele não cria alertas com ruído. Nenhuma alteração é feita no teste de ping de URL para que você possa continuar a depender dele para alertas.

5. Valide a funcionalidade do novo teste padrão e, em seguida, atualize as regras de alerta que fazem referência ao teste de ping de URL para fazer referência ao teste padrão.

6. Desabilite ou exclua o teste de ping de URL. Para fazer isso com o Azure PowerShell, você pode usar este comando:

   Remove-AzApplicationInsightsWebTest -ResourceGroupName $resourceGroup -Name $pingTestName;
   

Testar com proteção de um firewall

Para garantir a disponibilidade do ponto de extremidade protegido por firewalls, habilite testes de disponibilidade públicos ou execute testes de disponibilidade em cenários desconectados ou sem entrada.

Habilitação de teste de disponibilidade público

Verifique se o site interno tem um registro DNS (Sistema de Nomes de Domínio) público. Os testes de disponibilidade falharão se o DNS não puder ser resolvido. Para obter mais informações, consulte Crie um nome de domínio personalizado para o aplicativo interno.

Autenticar tráfego

Defina cabeçalhos personalizados em testes padrão para validar o tráfego.

1. Crie uma cadeia de caracteres alfanumérica sem espaços para identificar esse teste de disponibilidade (por exemplo, MyAppAvailabilityTest). Daqui em diante, nos referimos a essa cadeia de caracteres como o identificador de cadeia de caracteres de teste de disponibilidade.

2. Adicione o cabeçalho personalizado X-Customer-InstanceId com o valor ApplicationInsightsAvailability:<your availability test string identifier> na seção Informações de teste padrão ao criar ou atualizar seus testes de disponibilidade.

   

3. Verifique se o tráfego de entrada inclui o cabeçalho e o valor definidos nas etapas anteriores.

Como alternativa, defina o identificador de cadeia de caracteres de teste de disponibilidade como um parâmetro de consulta.

Exemplo: https://yourtestendpoint/?x-customer-instanceid=applicationinsightsavailability:<your availability test string identifier>

Configure seu firewall para permitir a chegada de solicitações de Testes de disponibilidade

Para simplificar a habilitação de serviços do Azure sem autorizar IPs individuais ou manter uma lista de IP atualizada, use Marcas de serviço. Aplique essas marcas no Firewall do Azure e em grupos de segurança de rede, permitindo que o serviço de Teste de Disponibilidade acesse seus pontos de extremidade. A marca de serviço ApplicationInsightsAvailability se aplica a todos os testes de disponibilidade.

1. Se você estiver usando grupos de segurança de rede do Azure, vá para o recurso do grupo de segurança de rede e, em Configurações, abra a experiência regras de segurança de entrada e selecione Adicionar.

2. Em seguida, selecione a Marca de serviço como a Origem e ApplicationInsightsAvailability como a Marca de serviço de origem. Use as portas abertas 80 (http) e 443 (https) para o tráfego de entrada que virá da marca de serviço.

Para gerenciar o acesso quando os pontos de extremidade estiverem fora do Azure ou quando as marcas de serviço não forem uma opção, permita a lista de permissões dos endereços IP de nossos agentes de teste da Web. Você pode consultar intervalos de IP usando o PowerShell, a CLI do Azure ou uma chamada REST com a API de Marca de Serviço. Para obter uma lista abrangente de marcas de serviço atuais e seus detalhes de IP, baixe o arquivo JSON.

1. No recurso do grupo de segurança de rede, em Configurações, abra a experiência de Regras de segurança de entrada e selecione Adicionar.

2. Em seguida, selecione Endereços IP como sua Origem. Em seguida, adicione seus endereços IP em uma lista delimitada por vírgulas nos intervalos de endereço IP/CIRD de origem.

Cenários de entrada desconectados ou não

1. Conecte seu recurso do Application Insights ao ponto de extremidade de serviço interno usando o Link Privado do Azure.

2. Escreva seu próprio código para testar periodicamente o servidor interno ou pontos de extremidade. Envie os resultados para o Application Insights usando a API TrackAvailability() no pacote SDK principal.

Configurações de TLS compatíveis

Para fornecer a melhor criptografia de classe, todos os testes de disponibilidade usam Transport Layer Security (TLS) 1.2 e 1.3 como o mecanismo de criptografia de sua escolha. Além disso, os seguintes conjuntos de criptografia e curvas elípticas também têm suporte em cada versão.

Atualmente, o TLS 1.3 só está disponível nessas regiões de teste de disponibilidade: NorthCentralUS, CentralUS, EastUS, SouthCentralUS, WestUS.

Preterindo a configuração do TLS

TLS 1.0 e TLS 1.1

Os TLS 1.0 e TLS 1.1 estão sendo desativados

TLS 1.2 and TLS 1.3

Solução de problemas

Pasta de trabalho tempo de inatividade e interrupções

Essa seção apresenta uma forma simples de calcular e relatar o SLA (Contrato de Nível de Serviço) para testes na Web em um só lugar para todos os recursos do Application Insights e assinaturas do Azure. O relatório tempo de inatividade e interrupção mostra visualizações de dados e consultas pré-criadas avançadas para você entender melhor a conectividade do cliente, o tempo de resposta comum do aplicativo e o tempo de inatividade.

O modelo de pasta de trabalho do SLA pode ser acessado do recurso do Application Insights de duas maneiras:

• Abra a experiência de Disponibilidade e selecione o Relatório SLA na barra de navegação superior.

• Abra a experiência de Pastas de Trabalho e selecione o modelo Tempo de Inatividade e Interrupções .

Flexibilidade de parâmetro

Os parâmetros definidos na pasta de trabalho influenciam o restante do relatório.

• Subscriptions, App Insights Resources e Web Test: esses parâmetros determinam as opções de recursos de alto nível. Eles são baseados em consultas do Log Analytics e são usados em cada consulta de relatório.
• Failure Threshold e Outage Window: use esses parâmetros para determinar seus próprios critérios para uma interrupção de serviço. Um exemplo são os critérios para um alerta de disponibilidade do Application Insights com base num contador de localização com falha durante um período escolhido. O limite comum é de três locais em uma janela de cinco minutos.
• Maintenance Period: use esse parâmetro para selecionar sua frequência de manutenção típica. Maintenance Window é um seletor de datetime para um exemplo de período de manutenção. Todos os dados que ocorrem durante o período identificado são ignorados em seus resultados.
• Availability Target %: esse parâmetro especifica seu objetivo de destino e usa valores personalizados.

Página de visão geral

A página de visão geral contém informações de alto nível sobre:

• SLA total (excluindo períodos de manutenção, se definido)
• Instâncias de interrupção de ponta a ponta.
• Tempo de inatividade do aplicativo

As instâncias de interrupção são determinadas a partir do momento em que um teste começa a falhar até que ele seja aprovado novamente com êxito, de acordo com seus parâmetros de interrupção. Se um teste começar a falhar às 8h e tiver êxito novamente às 10h, esse período de dados inteiro será considerado a mesma interrupção. Você também pode investigar a interrupção mais longa que ocorreu no período do relatório.

Alguns testes podem ser vinculados de volta ao recurso do Application Insights para investigação mais aprofundada. Mas isso só é possível no recurso do Application Insights baseado em workspace.

Tempo de inatividade, interrupções e falhas

Há mais duas guias ao lado da página Visão Geral:

• A guia Interrupções e tempo de inatividade tem informações sobre o total de instâncias com interrupção e o tempo de inatividade dividido por teste.

• A guia Falhas por Localização tem um mapa geográfico de localizações de teste com falha para identificar áreas de conexão de problema em potencial.

Outros recursos

• Personalização: você pode editar o relatório como qualquer outra pasta de trabalho do Azure Monitor e personalizar as consultas ou visualizações de acordo com as necessidades da sua equipe.

• Log Analytics: As consultas podem ser executadas no Log Analytics e usadas em outros relatórios ou painéis. Remova a restrição de parâmetro e reutilize a consulta principal.

• Acesso e compartilhamento: O relatório pode ser compartilhado com suas equipes e liderança ou fixado em um painel para uso posterior. O usuário precisa de permissão de leitura e acesso ao recurso do Application Insights em que a pasta de trabalho real está armazenada.

Perguntas frequentes

Esta seção fornece respostas para perguntas comuns.

Geral

Posso executar testes de disponibilidade em um servidor de intranet?

Os testes de disponibilidade são executados em pontos de presença distribuídos em todo o mundo. Existem duas soluções:

• Porta do firewall: permita solicitações ao seu servidor da lista mutável e longa dos agentes de teste na Web.
• Código personalizado: grave seu próprio código para enviar solicitações periódicas ao seu servidor a partir da sua intranet. Você pode executar testes na Web do Visual Studio para essa finalidade. O testador pode enviar os resultados ao Application Insights usando a API TrackAvailability().

O que é a cadeia de caracteres do agente de usuário para testes de disponibilidade?

A cadeia de caracteres do agente de usuário é Mozilla/5.0 (compatível; MSIE 9.0; Windows NT 6.1; Trident/5.0; AppInsights)

Compatível com TLS

Como essa substituição afeta meu comportamento de teste na Web?

Os testes de disponibilidade atuam como um cliente distribuído em cada um dos locais de teste da Web com suporte. Sempre que um teste na Web é executado, o serviço de teste de disponibilidade tenta entrar em contato com o ponto de extremidade remoto definido na configuração de teste da Web. Uma mensagem “Olá” do cliente TLS é enviada contendo toda a configuração TLS com suporte no momento. Se o ponto de extremidade remoto compartilhar uma configuração TLS comum com o cliente de teste de disponibilidade, o handshake do TLS terá êxito. Caso contrário, o teste da Web falhará com uma falha de handshake do TLS.

Como posso garantir que meu teste na Web não seja afetado?

Para evitar qualquer impacto, cada ponto de extremidade remoto (incluindo solicitações dependentes) com o qual o teste Web interage precisa dar suporte a pelo menos uma combinação da mesma Versão de protocolo, Pacote de criptografia e Curva elíptica que o teste de disponibilidade faz. Se o ponto de extremidade remoto não der suporte à configuração de TLS necessária, ele precisará ser atualizado com suporte para alguma combinação da configuração do TLS após a substituição mencionada acima. Esses pontos de extremidade podem ser descobertos por meio da exibição dos Detalhes da Transação do teste da Web (idealmente para uma execução bem-sucedida de teste na Web).

Como posso validar qual configuração de TLS um ponto de extremidade remoto dá suporte?

Há várias ferramentas disponíveis para testar qual configuração de TLS um ponto de extremidade dá suporte. Uma maneira seria seguir o exemplo detalhado nesta página. Se o ponto de extremidade remoto não estiver disponível por meio da Internet pública, você precisará garantir a validação da configuração do TLS com suporte no ponto de extremidade remoto de um computador que tenha acesso para chamar seu ponto de extremidade.

Após 1° de março de 2025, qual será o comportamento de teste na web para os testes afetados?

Não há um tipo de exceção com o qual todas as falhas de handshake do TLS afetadas por essa substituição se apresentariam. No entanto, a exceção mais comum com a qual o teste da Web começaria a falhar seria The request was aborted: Couldn't create SSL/TLS secure channel. Você também deve ser capaz de ver quaisquer falhas relacionadas ao TLS na Etapa de solução de problemas de Transporte do TLS para o resultado do teste da Web potencialmente afetado.

Posso exibir qual configuração do TLS está sendo usada no momento pelo meu teste na Web?

A configuração do TLS negociada durante uma execução de teste da Web não pode ser exibida. Desde que o ponto de extremidade remoto dê suporte à configuração TLS comum com testes de disponibilidade, nenhum impacto deve ser visto após a substituição.

Quais componentes a substituição afeta no serviço de teste de disponibilidade?

A preterição do TLS detalhada nesse documento só deve afetar o comportamento de execução do teste web de disponibilidade após 1° de março de 2025. Para obter mais informações sobre como interagir com o serviço de teste de disponibilidade para operações CRUD, consulte Suporte do TLS do Azure Resource Manager. Esse recurso fornece mais detalhes sobre as linhas do tempo de suporte e substituição do TLS.

Onde posso obter suporte ao TLS?

Em caso de dúvidas gerais sobre o problema herdado do TLS, consulte Solução de problemas de TLS.

Próximas etapas

• Solução de problemas
• Modelo do Azure Resource Manager de testes da Web
• API REST de teste da Web