Testes de disponibilidade do Application Insights

O Application Insights permite que você configure testes recorrentes da Web 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 alertam você se seu aplicativo não está respondendo ou se o tempo de resposta é 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 a partir da Internet pública, incluindo APIs REST das quais seu serviço depende. Isso significa que você pode monitorar não apenas seus próprios aplicativos, mas também serviços externos que são críticos para a funcionalidade do seu aplicativo. Você pode criar até 100 testes de disponibilidade por recurso do Application Insights.

Tipos de testes de disponibilidade

Existem 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 medir o desempenho, os testes padrão também incluem validade do certificado TLS/SSL, verificação proativa do tempo de vida, 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.

• Teste 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 TrackAvailability personalizado.

• (Preterido) Teste da Web em várias etapas: Você pode reproduzir essa gravação de uma sequência de solicitações da Web para testar cenários mais complexos. Testes da Web de várias etapas são criados no Visual Studio Enterprise e carregados no portal, onde você pode executá-los.

• (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 sucesso personalizados juntamente com recursos mais avançados, como analisar solicitações dependentes e permitir tentativas.

Criar um teste de disponibilidade

Alertas de disponibilidade

Os alertas são ativados automaticamente por padrão, mas para configurar totalmente um alerta, você deve inicialmente criar seu teste de disponibilidade.

Etiquetas de população de localização

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

Ativar alertas

1. Depois de salvar o teste de disponibilidade, abra o menu de contexto pelo teste feito e 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, a descrição da regra e o grupo de ações que têm as preferências de notificação que você deseja usar para essa regra de alerta.

   

Critérios de alerta

Os alertas de disponibilidade ativados automaticamente acionam um e-mail quando o ponto de extremidade fica indisponível e outro e-mail quando ele está disponível novamente. Os alertas de disponibilidade criados por meio dessa experiência são baseados no estado. Quando os critérios de alerta são atendidos, um único alerta é gerado quando o site é detetado como indisponível. Se o site ainda estiver fora do ar na próxima vez que os critérios de alerta forem avaliados, ele não gerará um novo alerta.

Por exemplo, suponha que seu site fique fora do ar por uma hora e você configure um alerta por e-mail com uma frequência de avaliação de 15 minutos. Você só recebe um e-mail quando o site sai do ar e outro quando ele está online novamente. Você não recebe alertas contínuos a cada 15 minutos para lembrá-lo de que o site ainda está indisponível.

Alterar os critérios de alerta

Talvez você não queira receber notificações quando seu site estiver fora do ar 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 mais alto do que o tempo de inatividade esperado, até 15 minutos. Você também pode aumentar o limite de local de alerta para que ele só acione um alerta se o site estiver inativo para um número específico de regiões.

Para fazer alterações no limite de local, período de agregação e 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 precisar de recursos avançados, você pode criar uma regra de alerta personalizada na guia Alertas. Selecione Criar>regra de alerta. Escolha Métricas para o 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). Ele 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 locais X fora de Y relatando falhas: A regra de alerta de locais X fora de Y é habilitada por padrão na nova experiência de alertas unificados quando você cria um novo teste de disponibilidade. Você pode desativar selecionando a opção "clássico" ou optando por desativar a regra de alerta. Configure os grupos de ações para receber notificações quando o alerta for acionado seguindo as etapas anteriores. Sem essa etapa, você só recebe notificações no portal quando a regra é acionada.

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

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

  2. A opção Configurar alertas no menu leva você para a nova experiência, 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 essa regra de alerta aqui.

• Alerta em consultas de análise personalizadas: usando os novos alertas unificados, você pode alertar sobre consultas de log personalizadas. Com consultas personalizadas, você pode alertar sobre qualquer condição arbitrária que o ajude a obter o sinal mais confiável de problemas de disponibilidade. Também é aplicável se você estiver enviando resultados de disponibilidade personalizados usando o SDK TrackAvailability.

  As métricas nos dados de disponibilidade incluem quaisquer resultados de disponibilidade personalizados que você possa estar enviando chamando o SDK TrackAvailability. Você pode usar o suporte a alertas sobre métricas para alertar sobre resultados de disponibilidade personalizados.

Automatize alertas

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

Ver os resultados do teste de disponibilidade

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

Verificar disponibilidade

Comece por rever o gráfico na experiência de Disponibilidade no portal do Azure.

Por padrão, a experiência de Disponibilidade mostra um gráfico de linhas. Altere a exibição para Gráfico de dispersão (alterne acima do gráfico) para ver amostras dos resultados do teste que têm detalhes da etapa de teste de diagnóstico. O motor de testes armazena os detalhes de diagnóstico dos testes que têm falhas. Relativamente aos testes bem-sucedidos, são armazenados os detalhes de diagnóstico de 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 de tempo para ver mais resultados em torno do período de interesse. Use o Search Explorer para ver os resultados de todas as execuções. Ou você pode usar consultas do Log Analytics para executar relatórios personalizados nesses dados.

Para ver os detalhes da transação de ponta a ponta, em Detalhar, selecione Bem-sucedido ou Reprovado. Em seguida, selecione uma amostra. Você também pode chegar aos detalhes da transação de ponta a ponta selecionando um ponto de dados no gráfico.

Inspecionar e editar testes

Para editar, desativar 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 de configuração se propaguem para todos os agentes de teste depois que uma alteração é feita.

Se vir falhas

Abra a visualização Detalhes da transação de ponta a ponta selecionando uma cruz vermelha no Gráfico de dispersão.

Aqui você pode:

• Analise o Relatório de solução de problemas para determinar o que potencialmente causou a falha do teste.
• Inspecionar a resposta recebida do seu servidor.
• Diagnostique falhas com telemetria correlacionada do lado do servidor 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.
• Abra o resultado do teste da Web no Visual Studio.

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

Selecione a linha de exceção para ver os detalhes da exceção do lado do servidor que causou a falha do teste de disponibilidade sintética. Você também pode obter o instantâneo de depuração para diagnósticos mais avançados no nível de código.

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

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

Consulta no Log Analytics

Você pode usar o Log Analytics para exibir seus resultados de disponibilidade (availabilityResults), dependências (dependencies) e muito mais. Para saber mais sobre o Log Analytics, consulte Visão geral da consulta de log.

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

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

Pré-requisitos

Começar agora

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

2. Liste 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. Encontre o teste de ping de URL que você deseja migrar e registre seu grupo de recursos e nome.

4. Crie um teste padrão com a mesma lógica do 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, não cria alertas barulhentos. Nenhuma alteração é feita no seu teste de ping de URL para que você possa continuar a confiar nele 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. Desative 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 por trás de uma firewall

Para garantir a disponibilidade do endpoint atrás de firewalls, habilite testes de disponibilidade pública ou execute testes de disponibilidade em cenários desconectados ou sem ingresso.

Habilitação de teste de disponibilidade pública

Certifique-se de que seu site interno tenha um registro DNS (Sistema de Nomes de Domínio) público. Os testes de disponibilidade falham se o DNS não puder ser resolvido. Para obter mais informações, consulte Criar um nome de domínio personalizado para 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). A partir daqui, 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 serviço verifica 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 solicitações de entrada de testes de disponibilidade

Para simplificar a habilitação dos serviços do Azure sem autorizar IPs individuais ou manter uma lista de IP atualizada, use tags de serviço. Aplique essas tags no Firewall do Azure e nos grupos de segurança de rede, permitindo que o serviço de teste de disponibilidade acesse seus pontos de extremidade. A etiqueta ApplicationInsightsAvailability de serviço aplica-se a todos os testes de disponibilidade.

1. Se estiver a utilizar grupos de segurança de rede do Azure, aceda ao recurso do grupo de segurança de rede e, em Definições, abra a experiência de regras de segurança de entrada e, em seguida, selecione Adicionar.

2. Em seguida, selecione Service Tag como Source e ApplicationInsightsAvailability como Source service tag. Use as portas abertas 80 (http) e 443 (https) para o tráfego de entrada da etiqueta de serviço.

Para gerenciar o acesso quando seus pontos de extremidade estiverem fora do Azure ou quando as tags de serviço não forem uma opção, permita a lista de endereços IP de nossos agentes de teste da Web. Você pode consultar intervalos de IP usando PowerShell, CLI do Azure ou uma chamada REST com a API da Etiqueta de Serviço. Para obter uma lista abrangente das tags 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 fonte. Em seguida, adicione seus endereços IP em uma lista delimitada por vírgulas nos intervalos de endereços IP de origem/CIRD.

Cenários desconectados ou sem entrada

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

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

Configurações TLS suportadas

Para fornecer a melhor criptografia da categoria, todos os testes de disponibilidade usam Transport Layer Security (TLS) 1.2 e 1.3 como os mecanismos de criptografia de escolha. Além disso, as seguintes suítes de codificação e curvas elípticas também são suportadas em cada versão.

Atualmente, o TLS 1.3 está disponível apenas nas regiões de teste de disponibilidade NorthCentralUS, CentralUS, EastUS, SouthCentralUS e WestUS.

Substituição da configuração TLS

TLS 1.0 e TLS 1.1

TLS 1.0 e TLS 1.1 estão sendo aposentados.

TLS 1.2 e TLS 1.3

Resolução de Problemas

Pasta de trabalho Downtime & Outages

Esta seção apresenta uma maneira simples de calcular e relatar o contrato de nível de serviço (SLA) para testes da Web por meio de um único painel de vidro em seus recursos do Application Insights e assinaturas do Azure. O relatório de tempo de inatividade e indisponibilidade apresenta consultas e visualizações de dados pré-criadas avançadas para melhorar a sua compreensão da conectividade do cliente, do tempo de resposta típico da aplicação e do período de indisponibilidade.

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

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

• Abra a experiência Pastas de trabalho e selecione o modelo Tempo de inatividade & Interrupções.

Flexibilidade de parâmetros

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

• Subscriptions, App Insights Resourcese Web Test: Esses parâmetros determinam suas opções de recursos de alto nível. Eles são baseados em consultas do Log Analytics e são usados em todas as consultas de relatório.
• Failure Threshold e Outage Window: Você pode usar 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 em um contador de local com falha durante um período escolhido. O limite típico é de três locais em uma janela de cinco minutos.
• Maintenance Period: Você pode usar este parâmetro para selecionar sua frequência de manutenção típica. Maintenance Window é um seletor datetime para um exemplo de período de manutenção. Todos os dados que ocorrem durante o período identificado são ignorados nos seus resultados.
• Availability Target %: Este parâmetro especifica seu objetivo de destino e usa valores personalizados.

Página de descriçã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é ser aprovado novamente, de acordo com seus parâmetros de interrupção. Se um teste começar a falhar às 8h00 e for bem-sucedido novamente às 10h00, todo esse período de dados será considerado a mesma interrupção. Você também pode investigar a interrupção mais longa que ocorreu durante o período de relatório.

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

Tempo de inatividade, interrupções e falhas

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

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

• A guia Falhas por Localização tem um mapa geográfico de locais de teste com falha para ajudar a identificar áreas de conexão com possíveis problemas.

Outras funcionalidades

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

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

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

Perguntas mais frequentes

Esta secção fornece respostas a 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 de firewall: permita solicitações ao seu servidor a partir da longa e alterável lista de agentes de teste da Web.
• Código personalizado: escreva seu próprio código para enviar solicitações periódicas ao seu servidor de dentro da intranet. Você pode executar testes da Web do Visual Studio para essa finalidade. O testador pode enviar os resultados para o Application Insights usando a TrackAvailability() API.

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

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

Suporte de TLS

Como essa depreciação afeta meu comportamento de teste da Web?

Os testes de disponibilidade atuam como um cliente distribuído em cada um dos locais de teste da Web suportados. Sempre que um teste da Web é executado, o serviço de teste de disponibilidade tenta entrar em contato com o ponto de extremidade remoto definido na configuração do teste da Web. É enviada uma mensagem Hello do Cliente TLS que contém toda a configuração TLS suportada no momento. Se o ponto de extremidade remoto compartilhar uma configuração TLS comum com o cliente de teste de disponibilidade, o handshake TLS será bem-sucedido. Caso contrário, o teste da Web falhará com uma falha de handshake TLS.

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

Para evitar qualquer impacto, cada ponto de extremidade remoto (incluindo solicitações dependentes) com o qual seu teste da Web interage precisa suportar pelo menos uma combinação da mesma Versão de Protocolo, Cipher Suite e Curva Elíptica que o teste de disponibilidade faz. Se o ponto de extremidade remoto não suportar a configuração TLS necessária, ele precisará ser atualizado com suporte para alguma combinação da configuração TLS pós-depreciação mencionada acima. Esses pontos de extremidade podem ser descobertos através da visualização dos Detalhes da Transação do seu teste da Web (idealmente para uma execução bem-sucedida do teste da Web).

Como faço para validar qual configuração TLS um ponto de extremidade remoto suporta?

Há várias ferramentas disponíveis para testar qual configuração TLS um ponto de extremidade suporta. Uma maneira seria seguir o exemplo detalhado nesta página. Se o seu ponto de extremidade remoto não estiver disponível através da Internet pública, você precisará garantir que valida a configuração TLS suportada no ponto de extremidade remoto a partir de uma máquina que tenha acesso para chamar seu ponto de extremidade.

Após 1º de março de 2025, qual será o comportamento do teste da Web para testes impactados?

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

Posso visualizar qual configuração TLS está atualmente em uso no meu teste da Web?

A configuração TLS negociada durante uma execução de teste da Web não pode ser visualizada. Contanto que o ponto de extremidade remoto ofereça suporte à configuração TLS comum com testes de disponibilidade, nenhum impacto deve ser visto após a depreciação.

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

A substituição do TLS detalhada neste documento só deve afetar o comportamento de execução do teste da Web do teste 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 TLS do Azure Resource Manager. Este recurso fornece mais detalhes sobre o suporte TLS e cronogramas de descontinuação.

Onde posso obter suporte TLS?

Para quaisquer perguntas gerais sobre o problema de TLS herdado, consulte Resolvendo problemas de TLS.

Próximos passos

• Resolução de problemas
• Web testa o modelo do Azure Resource Manager
• API REST de teste da Web