Testes de disponibilidade do Application Insights

Artigo
09/13/2024

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.

Nota

Os testes de disponibilidade são armazenados criptografados, de acordo com as políticas de criptografia de dados em repouso do Azure.

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.

Importante

Há duas próximas aposentadorias de testes de disponibilidade:

Testes da Web em várias etapas: Em 31 de agosto de 2024, os testes da Web em várias etapas no Application Insights serão desativados. Aconselhamos os utilizadores destes testes a fazerem a transição para testes de disponibilidade alternativos antes da data de reforma. Após esta data, iremos retirar a infraestrutura subjacente que irá quebrar os restantes testes em várias etapas.
Testes de ping de URL: Em 30 de setembro de 2026, os testes de ping de URL no Application Insights serão desativados. Os testes de ping de URL existentes serão removidos dos seus recursos. Revise os preços dos testes padrão e faça a transição para usá-los antes de 30 de setembro de 2026 para garantir que você possa continuar a executar testes de disponibilidade em uma única etapa em seus recursos do Application Insights.

Pré-requisitos

Recurso do Application Insights baseado na área de trabalho

Começar agora

Vá para o recurso do Application Insights e abra a experiência de disponibilidade .
Selecione Adicionar teste padrão na barra de navegação superior.

Insira o nome do teste, URL e outras configurações descritas na tabela a seguir e selecione Criar.

Section	Definição	Descrição
Informação Básica
	URL	O URL pode ser qualquer página Web que pretenda testar, mas tem de estar visível a partir da Internet pública. O URL pode incluir uma cadeia de consulta. Desta forma, pode, por exemplo, testar um pouco a base de dados. Se o URL remeter para um redirecionamento, iremos segui-lo até dez redirecionamentos.
	Analisar solicitações dependentes	O teste solicita imagens, scripts, arquivos de estilo e outros arquivos que fazem parte da página da Web em teste. O tempo de resposta gravado inclui o tempo necessário para obter estes ficheiros. O teste falhará se algum desses recursos não puder ser baixado com êxito dentro do tempo limite para todo o teste. Se a opção não estiver selecionada, o teste solicitará apenas o arquivo na URL especificada. Ativar essa opção resulta em uma verificação mais rigorosa. O teste pode falhar em casos, que podem não ser percetíveis quando você navega manualmente no site. Analisamos apenas até 15 solicitações dependentes.
	Habilitar novas tentativas para falhas de teste de disponibilidade	Quando o teste falha, ele tenta novamente após um curto intervalo. Uma falha só é comunicada após três tentativas falhadas sucessivas. Os testes subsequentes são realizados à frequência habitual de teste. A repetição encontra-se temporariamente suspensa até ao próximo êxito. Esta regra é aplicada de forma independente em cada localização de teste. Recomendamos esta opção. Em média, cerca de 80% das falhas desaparecem aquando da repetição.
	Ativar a validade do certificado SSL	Você pode verificar o certificado SSL em seu site para se certificar de que ele está corretamente instalado, válido, confiável e não fornece erros a nenhum de seus usuários. A validação do certificado SSL só será realizada no URL final redirecionado.
	Verificação proativa do tempo de vida	Essa configuração permite que você defina um período de tempo definido antes que seu certificado SSL expire. Depois de expirar, o teste será reprovado.
	Frequência de ensaio	Define a frequência com que o teste é executado a partir de cada local de teste. Com uma frequência predefinida de cinco minutos e cinco localizações de teste, o site é testado, em média, a cada minuto.
	Locais de teste	Os nossos servidores enviam pedidos Web para o seu URL a partir destas localizações. Nosso número mínimo de locais de teste recomendados é cinco para garantir que você possa distinguir problemas em seu site de problemas de rede. Pode selecionar até 16 localizações.
Informações de teste padrão
	Verbo de solicitação HTTP	Indique a ação que pretende tomar com o seu pedido.
	Corpo do pedido	Dados personalizados associados à sua solicitação HTTP. Pode carregar os seus próprios ficheiros, introduzir o seu conteúdo ou desativar esta funcionalidade.
	Adicionar cabeçalhos personalizados	Pares de valores-chave que definem os parâmetros operacionais. Os cabeçalhos "Host" e "User-Agent" são reservados nos Testes de Disponibilidade e não podem ser modificados ou substituídos.
Critérios de sucesso
	Tempo limite de teste	Diminua esse valor para ser alertado sobre respostas lentas. O teste é contado como uma falha se as respostas do seu site não forem recebidas dentro desse período. Se você selecionou Analisar solicitações dependentes, todas as imagens, arquivos de estilo, scripts e outros recursos dependentes deverão ser recebidos dentro desse período.
	Resposta HTTP	O código de status retornado contou como um sucesso. O número 200 é o código que indica que uma página da Web normal é retornada.
	Correspondência de conteúdo	Uma corda, como "Bem-vindo!" Testamos se uma correspondência exata que diferencia maiúsculas de minúsculas ocorre em todas as respostas. Tem de ser uma cadeia simples, sem carateres universais. Não se esqueça de que, se o conteúdo da sua página for alterado, talvez seja necessário atualizá-lo. Apenas caracteres em inglês são suportados com correspondência de conteúdo.

Importante

TrackAvailability() requer fazer um investimento do desenvolvedor em escrever e manter código personalizado potencialmente complexo.

Testes padrão devem ser sempre usados, se possível, pois exigem pouco investimento, nenhuma manutenção e têm poucos pré-requisitos.

Este exemplo foi criado apenas para mostrar a mecânica de como a TrackAvailability() chamada de API funciona em um aplicativo do Azure Functions. Ele não mostra como escrever o código de teste HTTP subjacente ou a lógica de negócios necessária para transformar este exemplo em um teste de disponibilidade totalmente funcional.

Pré-requisitos

Recurso do Application Insights baseado na área de trabalho
Acesso ao código-fonte de um aplicativo do Azure Functions
Experiência do desenvolvedor para criar código personalizado para TrackAvailability(), adaptado às suas necessidades específicas de negócios

Começar agora

Nota

Para seguir estas instruções, você deve usar o plano do Serviço de Aplicativo ou o plano Premium do Functions para permitir a edição de código no Editor do Serviço de Aplicativo.

Se você estiver testando atrás de uma rede virtual ou testando pontos de extremidade não públicos, precisará usar o plano Functions Premium.

Criar uma função de gatilho de temporizador

Crie um recurso do Azure Functions com a seguinte consideração:
- Se você ainda não tiver um recurso do Application Insights para sua função acionada por temporizador, ele será criado por padrão quando você criar um aplicativo do Azure Functions.
- Se você já tiver um recurso do Application Insights, vá para a guia Monitoramento ao criar o aplicativo Azure Functions e selecione ou insira o nome do recurso existente na lista suspensa do Application Insights:
Siga as instruções para criar uma função acionada pelo temporizador.

Adicionar e editar código no Editor do Serviço de Aplicativo

Vá para o aplicativo Azure Functions implantado e, em Ferramentas de Desenvolvimento, selecione a guia Editor do Serviço de Aplicativo.

Para criar um novo arquivo, clique com o botão direito do mouse na função de gatilho do temporizador (por exemplo, TimerTrigger1) e selecione Novo arquivo. Em seguida, digite o nome do arquivo e selecione Enter.

Crie um novo arquivo chamado function.proj e cole o seguinte código:

<Project Sdk="Microsoft.NET.Sdk"> 
    <PropertyGroup> 
        <TargetFramework>netstandard2.0</TargetFramework> 
    </PropertyGroup> 
    <ItemGroup> 
        <PackageReference Include="Microsoft.ApplicationInsights" Version="2.15.0" /> <!-- Ensure you’re using the latest version --> 
    </ItemGroup> 
</Project>

Crie um novo arquivo chamado runAvailabilityTest.csx e cole o seguinte código:

using System.Net.Http; 

public async static Task RunAvailabilityTestAsync(ILogger log) 
{ 
    using (var httpClient = new HttpClient()) 
    { 
        // TODO: Replace with your business logic 
        await httpClient.GetStringAsync("https://www.bing.com/"); 
    } 
}

Substitua o código existente em run.csx pelo seguinte:

#load "runAvailabilityTest.csx" 

using System; 

using System.Diagnostics; 

using Microsoft.ApplicationInsights; 

using Microsoft.ApplicationInsights.Channel; 

using Microsoft.ApplicationInsights.DataContracts; 

using Microsoft.ApplicationInsights.Extensibility; 

private static TelemetryClient telemetryClient; 

// ============================================================= 

// ****************** DO NOT MODIFY THIS FILE ****************** 

// Business logic must be implemented in RunAvailabilityTestAsync function in runAvailabilityTest.csx 

// If this file does not exist, add it first 

// ============================================================= 

public async static Task Run(TimerInfo myTimer, ILogger log, ExecutionContext executionContext) 

{ 
    if (telemetryClient == null) 
    { 
        // Initializing a telemetry configuration for Application Insights based on connection string 

        var telemetryConfiguration = new TelemetryConfiguration(); 
        telemetryConfiguration.ConnectionString = Environment.GetEnvironmentVariable("APPLICATIONINSIGHTS_CONNECTION_STRING"); 
        telemetryConfiguration.TelemetryChannel = new InMemoryChannel(); 
        telemetryClient = new TelemetryClient(telemetryConfiguration); 
    } 

    string testName = executionContext.FunctionName; 
    string location = Environment.GetEnvironmentVariable("REGION_NAME"); 
    var availability = new AvailabilityTelemetry 
    { 
        Name = testName, 

        RunLocation = location, 

        Success = false, 
    }; 

    availability.Context.Operation.ParentId = Activity.Current.SpanId.ToString(); 
    availability.Context.Operation.Id = Activity.Current.RootId; 
    var stopwatch = new Stopwatch(); 
    stopwatch.Start(); 

    try 
    { 
        using (var activity = new Activity("AvailabilityContext")) 
        { 
            activity.Start(); 
            availability.Id = Activity.Current.SpanId.ToString(); 
            // Run business logic 
            await RunAvailabilityTestAsync(log); 
        } 
        availability.Success = true; 
    } 

    catch (Exception ex) 
    { 
        availability.Message = ex.Message; 
        throw; 
    } 

    finally 
    { 
        stopwatch.Stop(); 
        availability.Duration = stopwatch.Elapsed; 
        availability.Timestamp = DateTimeOffset.UtcNow; 
        telemetryClient.TrackAvailability(availability); 
        telemetryClient.Flush(); 
    } 
}

Nota

Os testes criados com TrackAvailability() aparecerão com CUSTOM ao lado do nome do teste.

Captura de tela mostrando a experiência de disponibilidade com dois testes diferentes listados.

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.

Definição	Descrição
Quase em tempo real	Recomendamos o uso de alertas quase em tempo real. A configuração desse tipo de alerta é feita após a criação do teste de disponibilidade.
Limite de localização de alerta	Recomendamos um mínimo de 3/5 locais. A relação ideal entre o limite de local de alerta e o número de locais de teste é o número = de locais de teste de local de alerta - 2, com um mínimo de cinco locais de teste.

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.

Provider	Nome a apresentar	Nome da população
Azure
	Leste da Austrália	EMEA-au-Syd-Edge
	Sul do Brasil	LATAM-BR-GRU-EDGE
	E.U.A. Central	US-FL-MIA-EDGE
	Ásia Leste	APAC-HK-HKN-AZR
	E.U.A. Leste	US-Va-Ash-Azr
	França Sul (Anteriormente France Central)	EMEA-CH-ZRH-EDGE
	França Central	EMEA-FR-PRA-Edge
	Leste do Japão	APAC-JP-KAW-EDGE
	Europa do Norte	EMEA-GB-DB3-AZR
	E.U.A. Centro-Norte	US-IL-CH1-AZR
	E.U.A. Centro-Sul	EUA-TX-SN1-AZR
	Sudeste Asiático	APAC-SG-SIN-AZR
	Oeste do Reino Unido	EMEA-SE-Sto-Edge
	Europa Ocidental	EMEA-nl-ams-azr
	E.U.A. Oeste	US-CA-SJC-AZR
	Sul do Reino Unido	EMEA-RU-MSA-EDGE
Azure Government
	USGov Virginia	usgov-va-azr
	US Gov - Arizona	USGov-PHX-AZR
	USGov Texas	USGov-TX-AZR
	USDoD Leste	USGov-DDEAST-AZR
	USDoD Central	usgov-ddcentral-azr
Microsoft Azure operado pela 21Vianet
	Norte da China	MC-CNE-AZR
	China Leste 2	MC-CNE2-AZR
	Norte da China	MC-CNN-AZR
	Norte da China 2	MC-CNN2-AZR

Ativar alertas

Nota

Com os novos alertas unificados, a severidade da regra de alerta e as preferências de notificação com gruposde ação devem ser configuradas na experiência de alertas. Sem as etapas a seguir, você receberá apenas notificações no portal.

Depois de salvar o teste de disponibilidade, abra o menu de contexto pelo teste feito e selecione a página Abrir regras (alertas).
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.

Gorjeta

Para períodos de inatividade programados mais longos, desative temporariamente a regra de alerta ou crie uma regra personalizada. Dá-lhe mais opções para ter em conta o tempo de inatividade.

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.

Captura de tela mostrando a seleção de um teste de disponibilidade de amostra.

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.

Gorjeta

Talvez você queira desabilitar os testes de disponibilidade ou as regras de alerta associadas a eles enquanto executa a manutenção no serviço.

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.

Importante

Um custo está associado à execução de testes padrão. Depois de criar um teste padrão, você será cobrado pelas execuções de teste. Consulte os preços do Azure Monitor antes de iniciar este processo.

Pré-requisitos

Qualquer teste de ping de URL no Application Insights
Acesso ao Azure PowerShell

Começar agora

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

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;

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

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.

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.
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.

Aviso

Os endereços IP usados pelo serviço de testes de disponibilidade são compartilhados e podem expor seus pontos de extremidade de serviço protegidos por firewall a outros testes. A filtragem de endereços IP por si só não protege o tráfego do seu serviço, por isso é recomendável adicionar cabeçalhos personalizados adicionais para verificar a origem da solicitação da Web. Para obter mais informações, consulte Marcas de serviço de rede virtual.

Autenticar tráfego

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

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.
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.
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

Nota

Este exemplo é específico para o uso da etiqueta de serviço do grupo de segurança de rede. Muitos serviços do Azure aceitam marcas de serviço, cada uma exigindo etapas de configuração diferentes.

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.

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.
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.

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.
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

Conecte seu recurso do Application Insights ao seu ponto de extremidade de serviço interno usando o Azure Private Link.
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.

Versão	Conjuntos de cifras	Curvas elípticas
TLS 1.2	• TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 • TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 • TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 • TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256	• NistP384 • NistP256
TLS 1,3	• TLS_AES_256_GCM_SHA384 • TLS_AES_128_GCM_SHA256	• NistP384 • NistP256

Substituição da configuração TLS

Importante

Em 1º de maio de 2025, em alinhamento com a aposentadoria do TLS legado em todo o Azure, as versões do protocolo TLS 1.0/1.1 e os pacotes de codificação herdados e curvas elípticas do TLS 1.2/1.3 listados serão desativados para testes de disponibilidade do Application Insights.

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

Versão	Conjuntos de cifras	Curvas elípticas
TLS 1.2	• TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA • TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA • TLS_RSA_WITH_AES_256_GCM_SHA384 • TLS_RSA_WITH_AES_128_GCM_SHA256 • TLS_RSA_WITH_AES_256_CBC_SHA256 • TLS_RSA_WITH_AES_128_CBC_SHA256 • TLS_RSA_WITH_AES_256_CBC_SHA • TLS_RSA_WITH_AES_128_CBC_SHA	• Curva25519
TLS 1,3		• Curva25519

Resolução de Problemas

Aviso

Recentemente, habilitamos o TLS 1.3 em testes de disponibilidade. Se você estiver vendo novas mensagens de erro como resultado, certifique-se de que os clientes em execução no Windows Server 2022 com TLS 1.3 habilitado possam se conectar ao seu ponto de extremidade. Se você não conseguir fazer isso, considere desativar temporariamente o TLS 1.3 em seu endpoint para que os testes de disponibilidade retornem às versões mais antigas do TLS.

Para obter informações adicionais, consulte o artigo de soluçã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.

Nota

Para conhecer as etapas para habilitar a configuração TLS necessária em seu servidor web, é melhor entrar em contato com a equipe proprietária da plataforma de hospedagem em que seu servidor web é executado, se o processo não for conhecido.

Após 1º de maio 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 maio 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.

Partilhar via

Testes de disponibilidade do Application Insights

Tipos de testes de disponibilidade

Criar um teste de disponibilidade

Pré-requisitos

Começar agora

Alertas de disponibilidade

Etiquetas de população de localização

Ativar alertas

Critérios de alerta

Alterar os critérios de alerta

Criar uma regra de alerta personalizada

Automatize alertas

Ver os resultados do teste de disponibilidade

Verificar disponibilidade

Inspecionar e editar testes

Se vir falhas

Consulta no Log Analytics

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

Pré-requisitos

Começar agora

Testar por trás de uma firewall

Habilitação de teste de disponibilidade pública

Autenticar tráfego

Configure seu firewall para permitir solicitações de entrada de testes de disponibilidade

Cenários desconectados ou sem entrada

Configurações TLS suportadas

Substituição da configuração TLS

TLS 1.0 e TLS 1.1

TLS 1.2 e TLS 1.3

Resolução de Problemas

Pasta de trabalho Downtime & Outages

Flexibilidade de parâmetros

Página de descrição geral

Tempo de inatividade, interrupções e falhas

Outras funcionalidades

Perguntas mais frequentes

Geral

Posso executar testes de disponibilidade em um servidor de intranet?

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

Suporte de TLS

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

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

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

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

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

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

Onde posso obter suporte TLS?

Próximos passos

Comentários

Recursos adicionais