Testes de disponibilidade do Application Insights

Artigo
07/16/2024

Depois de implantar seu aplicativo Web ou site, você pode configurar testes recorrentes para monitorar a disponibilidade e a capacidade de resposta. O Application Insights envia solicitações da Web para seu aplicativo em intervalos regulares de pontos ao redor do mundo. Ele pode alertá-lo se seu aplicativo não estiver respondendo ou responder muito lentamente. Você pode criar até 100 testes de disponibilidade por recurso do Application Insights.

Os testes de disponibilidade não exigem alterações no site que você está testando e funcionam para qualquer ponto de extremidade HTTP ou HTTPS acessível a partir da Internet pública. Você também pode testar a disponibilidade de uma API REST da qual seu serviço depende.

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: este é 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.
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.
(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.

Gorjeta

Se você estiver usando outros testes de disponibilidade, como testes de ping de URL, poderá adicionar testes padrão ao lado dos outros. Se você quiser usar testes padrão em vez de um de seus outros testes, adicione um teste padrão e exclua seu teste antigo.

Pré-requisitos

Recurso do Application Insights baseado na área de trabalho

Começar agora

Vá para o recurso do Application Insights e selecione o painel Disponibilidade .
Selecione Adicionar teste padrão.

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

Definição	Descrição
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. Por favor, note que analisamos apenas até 15 pedidos dependentes.
Ativar novas tentativas	Quando o teste falha, é repetido 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.
Teste de validação 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.
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.
Cabeçalhos personalizados	Pares de valores-chave que definem os parâmetros operacionais.
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.

Critérios de êxito

Definição	Descrição
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 tiverem sido recebidas dentro desse período. Se você selecionou 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 que é contado como um sucesso. O número 200 é o código que indica que uma página da Web normal foi 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.

Pré-requisitos

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

Exemplo de código básico

Nota

Este exemplo foi projetado exclusivamente para mostrar a mecânica de como a TrackAvailability() chamada de API funciona em uma função do Azure. 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.

Por padrão, se você percorrer este exemplo, estará criando um teste HTTP GET de disponibilidade básica. Para seguir estas instruções, você deve usar o plano dedicado para permitir a edição de código no Editor do Serviço de Aplicativo.

Criar uma função de gatilho de temporizador

Crie um recurso do Azure Functions.
- Se você já tiver um recurso do Application Insights:
  
  Por padrão, o Azure Functions cria um recurso do Application Insights. Se você quiser usar um recurso criado anteriormente, deverá especificá-lo durante a criação.
  
  Siga as instruções sobre como criar um recurso do Azure Functions com a seguinte modificação:
  
  Na guia Monitoramento, selecione a caixa suspensa Application Insights e insira ou selecione o nome do seu recurso:
- Se você ainda não tiver um recurso do Application Insights criado para sua função acionada por temporizador:
  
  Por padrão, quando você cria seu aplicativo Azure Functions, ele cria um recurso do Application Insights para você. Siga as instruções sobre como criar um recurso do Azure Functions.
Nota

Você pode hospedar suas funções em um plano de Consumo, Premium ou 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 Premium no lugar do plano de consumo. Selecione seu plano na guia Hospedagem . Verifique se a versão mais recente do .NET está selecionada ao criar o aplicativo de função.
Crie uma função de gatilho de temporizador.
1. No seu aplicativo de funções, selecione a guia Funções .
2. Selecione Adicionar. No painel Adicionar funções, selecione as seguintes configurações:
  - Ambiente de desenvolvimento: Desenvolver no portal
  - Selecione um modelo: Gatilho de temporizador
3. Selecione Adicionar para criar a função de gatilho de temporizador.

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

Vá para seu aplicativo de função 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/"); 
    } 
}

Defina a variável de ambiente como um local de disponibilidade válido do REGION_NAME Azure.

Execute o seguinte comando na CLI do Azure para listar as regiões disponíveis.
```
az account list-locations -o table
```

Copie o código a seguir para o arquivo run.csx . (Você substitui o código pré-existente.)

#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, please 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(); 
    } 
}

Exemplo de código de teste da Web em várias etapas

Siga as mesmas instruções acima e, em vez disso, cole o seguinte código no arquivo runAvailabilityTest.csx :

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/"); 

        // TODO: Replace with your business logic for an additional monitored endpoint, and logic for additional steps as needed
        await httpClient.GetStringAsync("https://www.learn.microsoft.com/"); 
    } 
}

Alertas 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 de ping de URL de disponibilidade usando o Gerenciador de Recursos do Azure.

Azure

Nome a apresentar	Nome da população
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

Nome a apresentar	Nome da população
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

Nome a apresentar	Nome da população
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

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

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, na guia Detalhes , selecione as reticências pelo teste feito. Selecione a página Abrir Regras (Alertas).
Defina 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 esta regra de alerta.

Critérios de alerta

Os alertas de disponibilidade ativados automaticamente disparam um e-mail quando o ponto de extremidade definido está indisponível e 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ê tenha configurado um alerta por e-mail com uma frequência de avaliação de 15 minutos. Você só receberá um e-mail quando o site sair do ar e outro e-mail quando ele estiver online novamente. Você não receberá alertas contínuos a cada 15 minutos para lembrá-lo de que o site ainda está indisponível.

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

Alterar os critérios de alerta

Para fazer alterações no limite de localização, período de agregação e frequência de teste, selecione a condição na página de edição da regra de alerta 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ó receberá notificações no portal quando a regra for 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 revisando o gráfico na guia Disponibilidade do recurso do Application Insights.

Teste standard
TrackAvailability

Captura de ecrã que mostra a página Disponibilidade com o botão Atualizar realçado.

A visualização Gráfico de Dispersão mostra amostras dos resultados do teste que contê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. Passe o cursor sobre qualquer um dos pontos verdes/vermelhos para ver o teste, o nome do teste e o local.

Captura de ecrã que mostra a vista Linha.

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 que mostra a seleção de um teste de disponibilidade de exemplo.

Inspecionar e editar testes

Para editar, desativar temporariamente ou excluir um teste, selecione as reticências ao lado de um nome de teste. 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.

Captura de ecrã que mostra os detalhes do teste de visualização. Editar e desativar um teste da Web.

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

Selecione um ponto vermelho.

Captura de tela que mostra a guia Detalhes da transação de ponta a ponta.

A partir de um resultado de teste de disponibilidade, você pode ver os detalhes da transação em todos os componentes. Aqui você pode:

Revise o relatório de solução de problemas para determinar o que pode ter causado a falha no teste, mas seu aplicativo ainda está disponível.
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.
Registre um problema ou item de trabalho no Git ou Azure Boards para acompanhar o problema. O erro irá conter uma ligação para este evento.
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.

Captura de tela que mostra o diagnóstico do lado do servidor.

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, dependências e muito mais. Para saber mais sobre o Log Analytics, consulte Visão geral da consulta de log.

Migrar testes de disponibilidade

Neste artigo, guiamos você pelo processo de migração dos testes clássicos de ping de URL para os testes padrão modernos e eficientes.

Simplificamos esse processo fornecendo instruções passo a passo claras para garantir uma transição perfeita e equipar seus aplicativos com os recursos de monitoramento mais atualizados.

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.

Os comandos a seguir criam um teste padrão com a mesma lógica do teste de ping de URL.

Nota

Os comandos a seguir funcionam para pontos de extremidade HTTP e HTTPS, que são usados em seus testes de ping de URL.

$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.
Depois de validar a funcionalidade do novo teste padrão, atualize as regras de alerta que fazem referência ao teste de ping de URL para fazer referência ao teste padrão. Em seguida, desative ou exclua o teste de ping de URL.

Para excluir um teste de ping de URL 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 de disponibilidade padrão para validar o tráfego.

Gere um token ou GUID para identificar o tráfego de seus testes de disponibilidade.
Adicione o cabeçalho personalizado "X-Customer-InstanceId" com o valor ApplicationInsightsAvailability:<GUID generated in step 1> 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 token como um parâmetro de consulta. Por exemplo, https://yourtestendpoint/?x-customer-instanceid=applicationinsightsavailability:<your guid>.

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.
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, selecione regras de segurança de entrada. Em seguida, selecione Adicionar.
2. Em seguida, selecione Service Tag como a origem e selecione ApplicationInsightsAvailability como a tag de serviço de origem. 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, selecione regras de segurança de entrada. Em seguida, 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

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.

Nota

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

TLS 1.2

Pacotes de cifra

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

Curvas elípticas

NistP384
NistP256

TLS 1,3

Pacotes de cifra

TLS_AES_256_GCM_SHA384
TLS_AES_128_GCM_SHA256

Curvas elípticas:

NistP384
NistP256

Substituição da configuração TLS

Aviso

Em 31 de outubro de 2024, em alinhamento com a descontinuação do TLS herdado em todo o Azure, as versões do protocolo TLS 1.0/1.1 e os pacotes de codificação herdados TLS 1.2/1.3 listados abaixo e as curvas elípticas serão desativados para testes de disponibilidade do Application Insights.

TLS 1.0 e TLS 1.1

As versões do protocolo não serão mais suportadas.

TLS 1.2

Pacotes de cifra

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

Curvas elípticas:

curva25519

TLS 1,3

Curvas elípticas

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 que executam 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. Consulte o artigo dedicado à resolução de problemas.

Livro de tempo de inatividade, SLA e indisponibilidades

Este artigo 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 o painel Disponibilidade e selecione Relatório de SLA na parte superior da tela.
Abra o painel Pastas de trabalho e selecione 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 ocorram durante o período identificado serã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 definidas por quando um teste começa a falhar até ser bem-sucedido, com base nos 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

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.

Editar o relatório

Você pode editar o relatório como qualquer outra pasta de trabalho do Azure Monitor.

Captura de tela que mostra a seleção do botão Editar para alterar a visualização para um gráfico de pizza.

Você pode 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.

O relatório pode ser compartilhado com suas equipes e lideranças ou fixado em um painel para uso posterior. O usuário precisa ter permissão/acesso de leitura 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 nossos testes Web são executados em pontos de presença distribuídos por 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 31 de outubro de 2024, 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 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 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

Critérios de êxito

Alertas de disponibilidade

Etiquetas de população de localização

Azure

Azure Government

Microsoft Azure operado pela 21Vianet

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

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

TLS 1.2

TLS 1,3

Substituição da configuração TLS

TLS 1.0 e TLS 1.1

TLS 1.2

TLS 1,3

Resolução de Problemas

Livro de tempo de inatividade, SLA e indisponibilidades

Flexibilidade de parâmetros

Página de descrição geral

Tempo de inatividade, interrupções e falhas

Editar o relatório

Log Analytics

Acesso e partilha

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 31 de outubro de 2024, 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