Testes de disponibilidade do Application Insights

Artigo
10/15/2024

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.

Observação

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

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

Importante

Temos duas desativações futuras dos testes de disponibilidade:

Testes Web de várias etapas: em 31 de agosto de 2024, os testes web de várias etapas no Application Insights serão desativados. Aconselhamos os usuários desses testes a fazerem a transição para os testes de disponibilidade alternativos antes da data da desativação. Após essa data, vamos remover a infraestrutura subjacente, o que irá interromper os testes multietapas restantes.
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 de seus recursos. Examine preços para testes padrão e transição para usá-los antes de 30 de setembro de 2026 para garantir que você possa continuar a executar testes de disponibilidade em etapa única em seus recursos do Application Insights.

Pré-requisitos

Recurso baseado em espaço de trabalho do Application Insights

Introdução

Acesse o recurso do Application Insights e abra a experiência Disponibilidade.
Selecione Adicionar teste padrão na barra de navegação superior.

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

Seção	Configuração	Descrição
Informações Básicas
	URL	A URL pode ser qualquer página da Web que você deseja testar, mas deve estar visível na Internet pública. A URL pode incluir uma cadeia de consulta. Por exemplo, você pode utilizar um pouco seu banco de dados. Se a URL for resolvida para um redirecionamento, nós a seguiremos, até um máximo de 10 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 esses arquivos. O teste falhará se não for possível baixar algum desses recursos dentro do tempo limite do teste inteiro. Se a opção não estiver selecionada, o teste solicitará apenas o arquivo na URL especificada. A habilitação dessa opção resulta em uma verificação mais rigorosa. O teste pode falhar em alguns casos, o que pode não ser perceptível quando você navega manualmente pelo site. Analisamos até 15 solicitações dependentes.
	Habilitar novas tentativas para falhas de teste de disponibilidade	Quando o teste falha, ele é repetido após um breve intervalo. Uma falha só será relatada se três tentativas sucessivas falharem. Testes subsequentes são então executados com a frequência de teste normal. A repetição é suspensa temporariamente até o próximo sucesso. Essa regra é aplicada independentemente em cada local de teste. Recomendamos esta opção. Em média, aproximadamente 80% das falhas desaparecem na repetição.
	Habilitar a validade do certificado SSL	Você pode verificar o certificado SSL em seu site para verificar se ele está instalado corretamente, se é válido, confiável e não resulta em erros para seus usuários.
	Verificação proativa de tempo de vida	Isso permite que você estabeleça um período de tempo definido antes que o certificado SSL expire. Depois que expirar, seu teste falhará.
	Frequência de teste	define a frequência com que o teste é executado em cada localização de teste. Com uma frequência padrão de cinco minutos e cinco locais de teste, seu site é testado em média a cada minuto.
	Locais de teste	Nossos servidores enviam as solicitações da Web para a sua URL desses locais. O número mínimo de locais de teste recomendado é cinco para garantir que você possa diferenciar problemas no seu site de problemas na rede. Você pode selecionar até 16 locais.
Informações de teste padrão
	Verbo da solicitação HTTP	Indique a ação que deseja executar com sua solicitação.
	Corpo da solicitação	Dados personalizados associados à sua solicitação HTTP. Você pode carregar seus próprios arquivos, inserir seu conteúdo ou desabilitar esse recurso.
	Adicionar cabeçalhos personalizados	Pares chave-valor que definem os parâmetros operacionais.
Critérios de êxito
	Tempo limite de teste	diminua esse valor para ser alertado sobre respostas lentas. O teste será contado como uma falha se as respostas do seu site não forem recebidas nesse período. Se você tiver selecionado Analisar solicitações dependentes, todas as imagens, arquivos de estilo, scripts e outros recursos dependentes devem ter sido recebidos dentro desse período.
	Resposta HTTP	O código de status retornado é contado como êxito. O número 200 é o código que indica que uma página da Web normal foi retornada.
	Correspondência de conteúdo	Uma cadeia de caracteres, como "Boas vindas!". Fazemos o teste para verificar se uma correspondência exata de maiúsculas e minúsculas ocorre em cada resposta. É necessário que seja uma cadeia de caracteres simples, sem curingas. Lembre-se de que se o conteúdo da sua página for alterado, talvez seja necessário atualizá-la. Somente os caracteres da língua inglesa são compatíveis com a correspondência de conteúdo.

Importante

O TrackAvailability() exige que o desenvolvedor invista na criação e manutenção de um código personalizado potencialmente complexo.

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

Esse exemplo foi projetado unicamente para mostrar a você a mecânica de como a chamada à API TrackAvailability() funciona com o aplicativo do Azure Functions. Ele não mostra como escrever a lógica de negócios ou o código de teste HTTP necessário para transformar esse exemplo em um teste de disponibilidade totalmente funcional.

Pré-requisitos

Recurso baseado em espaço de trabalho do Application Insights
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 comerciais específicas

Introdução

Observação

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

Se você estiver testando por trá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 disparada 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 do 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 disparada pelo temporizador.

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

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

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

Crie um 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 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(); 
    } 
}

Observação

Os testes criados com TrackAvailability() serão exibidos com CUSTOM próximo ao nome do teste.

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

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.

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

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.

Provedor	Nome de exibição	Nome da população
Azure
	Leste da Austrália	emea-au-syd-edge
	Brazil South	latam-br-gru-edge
	Centro dos EUA	us-fl-mia-edge
	Leste da Ásia	apac-hk-hkn-azr
	Leste dos EUA	us-va-ash-azr
	Sul da França (antiga França Central)	emea-ch-zrh-edge
	França Central	emea-fr-pra-edge
	Leste do Japão	apac-jp-kaw-edge
	Norte da Europa	emea-gb-db3-azr
	Centro-Norte dos EUA	us-il-ch1-azr
	Centro-Sul dos Estados Unidos	us-tx-sn1-azr
	Sudeste Asiático	apac-sg-sin-azr
	Oeste do Reino Unido	emea-se-sto-edge
	Europa Ocidental	emea-nl-ams-azr
	Oeste dos EUA	us-ca-sjc-azr
	Sul do Reino Unido	emea-ru-msa-edge
Azure Governamental
	Gov. EUA – Virgínia	usgov-va-azr
	Gov. EUA – Arizona	usgov-phx-azr
	Gov. EUA – Texas	usgov-tx-azr
	Leste do USDoD	usgov-ddeast-azr
	USDoD Central	usgov-ddcentral-azr
Microsoft Azure operado pela 21Vianet
	Leste da China	mc-cne-azr
	Leste da China 2	mc-cne2-azr
	Norte da China	mc-cnn-azr
	Norte da China 2	mc-cnn2-azr

Habilitar alertas

Observação

com os novos alertas unificados, as preferências de notificação e a gravidade de regra de alerta com grupos de açãodeve ser configurada no experiência de alertas. Sem as etapas a seguir, você só receberá notificações no portal.

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

Dica

Para tempos de inatividade agendados mais longos, desative temporariamente a regra de alerta ou crie uma regra personalizada. Isso oferecerá mais opções para contabilizar o tempo de inatividade.

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.

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

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.

Dica

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

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.

Importante

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

Pré-requisitos

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

Introdução

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

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;

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

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.

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

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ço IP sozinha não protege o tráfego do serviço, portanto, é recomendável adicionar cabeçalhos personalizados extras para verificar a origem da solicitação da Web. Para obter mais informações, confira Marcas de serviço de rede virtual.

Autenticar tráfego

Defina cabeçalhos personalizados em testes de disponibilidade 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). Daqui em diante, 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 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

Observação

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

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.

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

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

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

Versão	Conjuntos de criptografia	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

Preterindo a configuração do TLS

Importante

Em 1º de março de 2025, em alinhamento com a desativação do TLS legado do Azure, as versões do protocolo TLS 1.0/1.1 e os conjuntos de cifras e curvas elípticas legados do TLS 1.2/1.3 listados serão desativados para os testes de disponibilidade do Application Insights.

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

Versão	Conjuntos de criptografia	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	• curve25519
TLS 1.3		• curve25519

Solução de problemas

Aviso

Recentemente, habilitamos o TLS 1.3 nos testes de disponibilidade. Se 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 não conseguir fazer isso, considere a possibilidade de desabilitar temporariamente o TLS 1.3 em seu ponto de extremidade para que os testes de disponibilidade caiam de volta para versões mais antigas do TLS.

Para obter informações adicionais, verifique o artigo 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?

Nossos testes na Web executam em pontos de presença distribuídos no mundo inteiro. 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.

Observação

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

Após 31 de outubro de 2024, qual será o comportamento do teste web para 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 substituição do TLS detalhada neste documento só deve afetar o comportamento de execução do teste web de disponibilidade após 31 de outubro de 2024. 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.

Compartilhar via

Testes de disponibilidade do Application Insights

Tipos de testes de disponibilidade

Criar um Conjunto de Disponibilidade

Pré-requisitos

Introdução

Alertas de disponibilidade

Marcas de população de local

Habilitar alertas

Critérios do alerta

Alterar os critérios de alerta

Criar uma regra de alerta personalizada

Automatizar alertas

Ver os resultados de teste de disponibilidade

Verificar a disponibilidade

Como inspecionar e editar testes

Se você encontrar falhas

Consulta no Log Analytics

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

Pré-requisitos

Introdução

Testar com proteção de um firewall

Habilitação de teste de disponibilidade público

Autenticar tráfego

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

Cenários de entrada desconectados ou não

Configurações de TLS compatíveis

Preterindo a configuração do TLS

TLS 1.0 e TLS 1.1

TLS 1.2 and TLS 1.3

Solução de problemas

Pasta de trabalho tempo de inatividade e interrupções

Flexibilidade de parâmetro

Página de visão geral

Tempo de inatividade, interrupções e falhas

Outros recursos

Perguntas frequentes

Geral

Posso executar testes de disponibilidade em um servidor de intranet?

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

Compatível com TLS

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

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

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

Após 31 de outubro de 2024, qual será o comportamento do teste web para testes afetados?

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

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

Onde posso obter suporte ao TLS?

Próximas etapas

Comentários

Recursos adicionais