Compartilhar via


Testes de disponibilidade do Application Insights

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 ao aplicativo em intervalos regulares de pontos no mundo todo. Ele poderá alertar se o aplicativo não responder ou a reposta for muito lenta. 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 pela Internet pública. Você pode testar a disponibilidade de uma API REST da qual o seu serviço depende.

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: esse é 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.

Criar um Conjunto de Disponibilidade

Dica

Se estiver usando outros testes de disponibilidade, como testes de ping de URL, você pode adicionar os testes Padrão junto com os outros. Se você quiser usar testes Padrão em vez de um dos outros testes, adicione um teste Padrão e exclua o antigo teste.

Pré-requisitos

Introdução

  1. Acesse o recurso do Application Insights e selecione o painel Disponibilidade.

  2. Selecione Adicionar teste Standard.

    Captura de tela mostrando o painel Disponibilidade com a guia Adicionar Teste Padrão aberta.

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

    Configuração Descrição
    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. Observe que analisamos apenas até 15 solicitações dependentes.
    Habilitar novas tentativas 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.
    Teste de validação 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.
    Cabeçalhos personalizados Pares chave-valor que definem os parâmetros operacionais.
    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.

Critérios de êxito

Configuração Descrição
Tempo limite de teste diminua esse valor para ser alertado sobre respostas lentas. O teste é considerado uma falha se as respostas de seu site não forem recebidas dentro desse 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 que é 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.

Alertas 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 de ping de URL de disponibilidade usando o Azure Resource Manager.

Azure

Nome de exibição Nome da população
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 Government

Nome de exibição Nome da população
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

Nome de exibição Nome da população
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

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

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.

  1. Depois de salvar o teste de disponibilidade, na guia Detalhes, selecione as reticências do teste que acabou de criar. Selecione Abrir página Regras (Alertas).

    Captura de tela que mostra o painel Disponibilidade de um recurso do Application Insights no portal do Azure e a opção de menu da página Abrir Regras (Alertas).

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

Alertas de disponibilidade habilitados automaticamente disparam um email quando o ponto de extremidade definido não está disponível e quando ele fica 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ó receberá um email quando o site ficar inoperante e um outro email quando estiver de volta online. Você não receberá alertas contínuos a cada 15 minutos para lembrá-lo que o site ainda não está disponível.

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

Alterar os critérios de alerta

Para fazer alterações no limite de localização, no período de agregação e na frequência de testes, selecione a condição na página de edição da regra de alerta, que abrirá a janela “Configurar lógica de sinais”.

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ó receberá 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 analisando o gráfico na guia Disponibilidade do seu recurso Application Insights.

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

A exibição do Gráfico de Dispersão mostra exemplos dos resultados do teste que contêm os detalhes da etapa do teste de diagnóstico. 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. Passe o mouse sobre qualquer um dos pontos verdes/vermelhos para ver o teste, o nome do teste e a localização.

Captura de tela mostrando a exibição Linha.

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

Captura de tela que mostra os detalhes da transação de ponta a ponta.

Como inspecionar e editar testes

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

Captura de tela mostrando os detalhes do teste. Editar e Desabilitar um teste da Web.

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

Selecione um ponto vermelho.

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

De um resultado do teste de disponibilidade, você pode ver os detalhes de transações em todos os componentes. Aqui, você pode ver:

  • Revise o relatório da 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 servidor.
  • Diagnosticar falha na telemetria do lado do servidor correlacionado coletada durante o processamento do teste de disponibilidade com falha.
  • Registrar um problema ou um item de trabalho no Git ou no Azure Boards para controlar o problema. O bug conterá um link para este evento.
  • 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.

Captura de tela mostrando diagnósticos do lado do servidor.

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

Captura de tela que mostra os resultados de disponibilidade.

Captura de tela que mostra a guia Nova Consulta com as dependências limitadas a 50.

Migrar testes de disponibilidade

Neste artigo, orientamos você pelo processo de migração de testes de ping de URL clássicos 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 equipe seus aplicativos com os recursos de monitoramento mais atualizados.

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

Introdução

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

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

    Get-AzApplicationInsightsWebTest | `
    Where-Object { $_.WebTestKind -eq "ping" } | `
    Format-Table -Property ResourceGroupName,Name,WebTestKind,Enabled;
    
  3. Localize o teste de ping de URL que você deseja migrar e registre seu nome e grupo de recursos.

  4. Os seguintes comandos criam um teste padrão com a mesma lógica que o teste de ping de URL.

    Observação

    Sim, esses comandos 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);
    
  5. 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.

  6. 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, desabilite ou exclua o teste de ping de URL.

  7. Para excluir um teste de ping de URL 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.

  1. Gere um token ou GUID para identificar o tráfego de seus testes de disponibilidade.

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

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

    Captura de tela que mostra o cabeçalho de validação personalizado.

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

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

      Captura de tela que mostra a guia regras de segurança de entrada no recurso de grupo de segurança de rede.

    2. Em seguida, selecione a Marca de serviço como a origem e, em seguida, 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.

      Captura de tela que mostra a guia adicionar regras de segurança de entrada com uma fonte de marca de serviço.

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

    1. No recurso do grupo segurança de rede em Configurações, selecione regras de segurança de entrada. Em seguida, selecioneAdicionar.

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

      Captura de tela que mostra a guia adicionar regras de segurança de entrada com uma fonte de endereços IP.

Cenários de entrada desconectados ou não

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

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

Configurações de TLS compatíveis

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

Observação

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

TLS 1.2

Conjuntos de criptografia

  • 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

Conjuntos de criptografia

  • TLS_AES_256_GCM_SHA384
  • TLS_AES_128_GCM_SHA256

Curvas elípticas:

  • NistP384
  • NistP256

Preterindo a configuração do TLS

Aviso

Em 31 de outubro de 2024, em alinhamento com a substituição do TLS herdado do Azure, as versões do protocolo TLS 1.0/1.1 e os conjuntos de Criptografia legados TLS 1.2/1.3 listados abaixo e as curvas elípticas serão preteridos para testes de disponibilidade do Application Insights.

TLS 1.0 e TLS 1.1

Não haverá mais suporte para versões de protocolo.

TLS 1.2

Conjuntos de criptografia

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

  • curve25519

TLS 1.3

Curvas elípticas

  • 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. Confira o artigo de solução de problemas dedicado.

Tempo de inatividade, SLA e pasta de trabalho de interrupções

Este artigo 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 o painel Disponibilidade e selecione Relatório de SLA na parte superior da tela.

    Captura de tela que mostra a guia Disponibilidade com o Relatório de SLA realçado.

  • Abra o painel Workbooks e selecione Tempo de Inatividade e Interrupções.

    Captura de tela da galeria de pastas de trabalho com a pasta de trabalho “Tempo de inatividade e interrupções” realçada.

Flexibilidade de parâmetro

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

 Captura de tela que mostra parâmetros.

  • 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 ocorrerem durante o período identificado serão ignorados nos 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 vão desde o início da falha do teste até seu sucesso, com base nos 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.

Captura de tela que mostra uma página de visão geral com a tabela de visão geral por teste.

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

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.

Captura de tela que mostra a guia “Interrupções e tempo de inatividade” na pasta de trabalho “Tempo de inatividade e interrupções”.

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.

Captura de tela que mostra a guia “Falha por local” na pasta de trabalho “Tempo de inatividade e interrupções”.

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.

Captura de tela que mostra a alteração da visualização para um gráfico de pizza.

Log Analytics

As consultas podem ser executadas no Log Analytics e usadas em outros relatórios ou painéis.

Captura de tela que mostra como acessar uma consulta de log.

Remova a restrição de parâmetro e reutilize a consulta principal.

Captura de tela que mostra uma consulta de log que você pode reutilizar.

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 ter permissão de leitura/acesso ao recurso do Application Insights em que a pasta de trabalho real está armazenada.

 Captura de tela que mostra o painel Compartilhar Modelo.

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.

Próximas etapas