Testes de disponibilidade do Application Insights

O Application Insights permite que você configure testes recorrentes da Web que monitoram a disponibilidade e a capacidade de resposta do seu site ou aplicativo de vários pontos ao redor do mundo. Esses testes de disponibilidade enviam solicitações da Web para seu aplicativo em intervalos regulares e alertam você se seu aplicativo não está respondendo ou se o tempo de resposta é muito lento.

Os testes de disponibilidade não exigem modificações no site ou aplicativo que você está testando. Eles funcionam para qualquer ponto de extremidade HTTP ou HTTPS acessível a partir da Internet pública, incluindo APIs REST das quais seu serviço depende. Isso significa que você pode monitorar não apenas seus próprios aplicativos, mas também serviços externos que são críticos para a funcionalidade do seu aplicativo. Você pode criar até 100 testes de disponibilidade por recurso do Application Insights.

Tipos de testes de disponibilidade

Existem quatro tipos de testes de disponibilidade:

• Teste padrão: um tipo de teste de disponibilidade que verifica a disponibilidade de um site enviando uma única solicitação, semelhante ao teste de ping de URL preterido. Além de validar se um ponto de extremidade está respondendo e medir o desempenho, os testes padrão também incluem validade do certificado TLS/SSL, verificação proativa do tempo de vida, verbo de solicitação HTTP (por exemplo, GET,HEAD, e POST), cabeçalhos personalizados e dados personalizados associados à sua solicitação HTTP.

  Saiba como criar um teste padrão.

• Teste TrackAvailability personalizado: Se você decidir criar um aplicativo personalizado para executar testes de disponibilidade, poderá usar o método TrackAvailability() para enviar os resultados para o Application Insights.

  Saiba como criar um teste personalizado de TrackAvailability.

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

• (Preterido) Teste de ping de URL: você pode criar esse teste por meio do portal do Azure para validar se um ponto de extremidade está respondendo e medir o desempenho associado a essa resposta. Você também pode definir critérios de sucesso personalizados juntamente com recursos mais avançados, como analisar solicitações dependentes e permitir tentativas.

Criar um teste de disponibilidade

Alertas de disponibilidade

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

Etiquetas de localização e população

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

Ativar alertas

1. Depois de guardar o teste de disponibilidade, abra o menu de contexto junto ao teste que fez e selecione página Abrir Regras (Alertas).

   

2. Na página Regras de alerta, abra o seu alerta e selecione Editar na barra de navegação superior. Aqui você pode definir o nível de gravidade, a descrição da regra e o grupo de ações que têm as preferências de notificação que você deseja usar para essa regra de alerta.

   

Critérios de alerta

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

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

Alterar os critérios de alerta

Talvez você não queira receber notificações quando seu site estiver fora do ar por apenas um curto período de tempo, por exemplo, durante a manutenção. Você pode alterar a frequência de avaliação para um valor mais alto do que o tempo de inatividade esperado, até 15 minutos. Você também pode aumentar o limite de local de alerta para que ele só acione um alerta se o site estiver inativo para um número específico de regiões.

Para fazer alterações no limite de local, período de agregação e frequência de teste, vá para a página Editar regra de alerta (consulte a etapa 2 em Habilitar alertas) e selecione a condição para abrir a Configure signal logic janela.

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. Pode optar por sair ao selecionar a opção "clássico" ou ao desativar a regra de alerta. Configure os grupos de ações para receber notificações quando o alerta for acionado seguindo as etapas anteriores. Sem essa etapa, você só recebe notificações no portal quando a regra é acionada.

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

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

  2. A Configure alerts opção do menu leva você para a nova experiência, onde você pode selecionar testes específicos ou locais 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 Linha e Gráfico de Dispersão.

Verificar disponibilidade

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

Por padrão, a experiência de Disponibilidade mostra um gráfico de linhas. Altere a exibição para Gráfico de dispersão (alterne no menu acima do gráfico) para ver amostras dos resultados do teste que contêm detalhes sobre a etapa de teste de diagnóstico. O motor de testes armazena os detalhes de diagnóstico dos testes que têm falhas. Relativamente aos testes bem-sucedidos, são armazenados os detalhes de diagnóstico de um subconjunto das execuções. Para ver o teste, o nome do teste e o local, passe o mouse sobre qualquer um dos pontos verdes ou cruzes vermelhas.

Selecione um teste ou local específico. Ou você pode reduzir o período de tempo para ver mais resultados em torno do período de interesse. Use o Search Explorer para ver os resultados de todas as execuções. Ou você pode usar consultas do Log Analytics para executar relatórios personalizados nesses dados.

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

Inspecionar e editar testes

Para editar, desativar temporariamente ou eliminar um teste, clique no menu de contexto (reticências) junto ao teste e selecione Editar. Pode levar até 20 minutos para que as alterações de configuração se propaguem para todos os agentes de teste depois que uma alteração é feita.

Caso detecte falhas

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

Aqui você pode:

• Analise o Relatório de solução de problemas para determinar o que potencialmente causou a falha do teste.
• Inspecionar a resposta recebida do seu servidor.
• Diagnostique as falhas usando telemetria correlacionada à do lado do servidor coletada durante o processamento de um teste de disponibilidade falhado.
• Acompanhe o problema registrando um problema ou item de trabalho no Git ou no Azure Boards. O bug contém um link para o evento no portal do Azure.
• Abra o resultado do teste da Web no Visual Studio.

Para saber mais sobre a experiência completa de diagnóstico de transação, 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 a captura de depuração para diagnósticos mais avançados a nível de código.

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

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

Consulta no Log Analytics

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

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

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

Prerequisites

Descubra testes de ping de URL

Descubra testes de ping de URL com a seguinte consulta no Azure Resource Graph Explorer.

resources
| where subscriptionId == "<subscriptionId>"
| where ['type'] == "microsoft.insights/webtests"
| extend testKind = tostring(properties.Kind)
| where testKind == "ping"

Iniciar a migração

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

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

   Get-AzApplicationInsightsWebTest | `
   Where-Object { $_.WebTestKind -eq "ping" } | `
   Format-Table -Property ResourceGroupName,Name,WebTestKind,Enabled;
   

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

4. Crie um teste padrão com a mesma lógica do teste de ping de URL usando os comandos a seguir, que funcionam para pontos de extremidade HTTP e HTTPS.

   $resourceGroup = "pingTestResourceGroup";
   $appInsightsComponent = "componentName";
   $pingTestName = "pingTestName";
   $newStandardTestName = "newStandardTestName";
   
   $componentId = (Get-AzApplicationInsights -ResourceGroupName $resourceGroup -Name $appInsightsComponent).Id;
   $pingTest = Get-AzApplicationInsightsWebTest -ResourceGroupName $resourceGroup -Name $pingTestName;
   $pingTestRequest = ([xml]$pingTest.ConfigurationWebTest).WebTest.Items.Request;
   $pingTestValidationRule = ([xml]$pingTest.ConfigurationWebTest).WebTest.ValidationRules.ValidationRule;
   
   $dynamicParameters = @{};
   
   if ($pingTestRequest.IgnoreHttpStatusCode -eq [bool]::FalseString) {
   $dynamicParameters["RuleExpectedHttpStatusCode"] = [convert]::ToInt32($pingTestRequest.ExpectedHttpStatusCode, 10);
   }
   
   if ($pingTestValidationRule -and $pingTestValidationRule.DisplayName -eq "Find Text" `
   -and $pingTestValidationRule.RuleParameters.RuleParameter[0].Name -eq "FindText" `
   -and $pingTestValidationRule.RuleParameters.RuleParameter[0].Value) {
   $dynamicParameters["ContentMatch"] = $pingTestValidationRule.RuleParameters.RuleParameter[0].Value;
   $dynamicParameters["ContentPassIfTextFound"] = $true;
   }
   
   New-AzApplicationInsightsWebTest @dynamicParameters -ResourceGroupName $resourceGroup -Name $newStandardTestName `
   -Location $pingTest.Location -Kind 'standard' -Tag @{ "hidden-link:$componentId" = "Resource" } -TestName $newStandardTestName `
   -RequestUrl $pingTestRequest.Url -RequestHttpVerb "GET" -GeoLocation $pingTest.PropertiesLocations -Frequency $pingTest.Frequency `
   -Timeout $pingTest.Timeout -RetryEnabled:$pingTest.RetryEnabled -Enabled:$pingTest.Enabled `
   -RequestParseDependent:($pingTestRequest.ParseDependentRequests -eq [bool]::TrueString) -RuleSslCheck:$false;
   

   O novo teste padrão não tem regras de alerta por padrão, portanto, não cria alertas barulhentos. Nenhuma alteração é feita no seu teste de ping de URL para que você possa continuar a confiar nele para alertas.

5. Valide a funcionalidade do novo teste padrão e, em seguida , atualize as regras de alerta que fazem referência ao teste de ping de URL para fazer referência ao teste padrão.

6. Desative ou exclua o teste de ping de URL. Para fazer isso com o Azure PowerShell, você pode usar este comando:

   Remove-AzApplicationInsightsWebTest -ResourceGroupName $resourceGroup -Name $pingTestName;
   

Testar atrá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.

Ativação de teste de disponibilidade pública

Certifique-se de que seu site interno tenha um registro DNS (Sistema de Nomes de Domínio) público. Os testes de disponibilidade falham se o DNS não puder ser resolvido. Para obter mais informações, consulte Criar um nome de domínio personalizado para aplicativo interno.

Autenticar tráfego

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

1. Crie uma cadeia de caracteres alfanumérica sem espaços para identificar esse teste de disponibilidade (por exemplo, MyAppAvailabilityTest). Daqui em diante, referimo-nos a esta cadeia como o identificador do teste de disponibilidade.

2. Adicione o cabeçalho personalizado X-Customer-InstanceId com o valor ApplicationInsightsAvailability:<your availability test string identifier> na seção Informações de teste padrão ao criar ou atualizar seus testes de disponibilidade.

   

3. Confirme se o serviço verifica que o tráfego de entrada inclui o cabeçalho e o valor definidos nas etapas anteriores.

Como alternativa, defina a cadeia de caracteres de teste de disponibilidade identificador como um parâmetro de consulta.

Exemplo: https://yourtestendpoint/?x-customer-instanceid=applicationinsightsavailability:<your availability test string identifier>

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

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

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

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

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

1. No recurso do grupo de segurança de rede, em Configurações, abra a experiência de regras de segurança de entrada e selecione Adicionar.

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

Cenários desconectados ou sem entrada

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

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

Configurações TLS suportadas

O Application Insights usa o Transport Layer Security (TLS) 1.2 e 1.3. Além disso, as seguintes suítes de codificação e curvas elípticas também são suportadas em cada versão.

Desativando configurações de TLS (Transport Layer Security)

TLS 1.2 e TLS 1.3

Livro de Registos de Interrupções e Avarias

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

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

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

• Abra a experiência Pastas de Trabalho e selecione o modelo Paragens e Interrupções.

Flexibilidade de parâmetros

Os parâmetros definidos na pasta de trabalho influenciam o restante do seu 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 de data e hora para um exemplo de período de manutenção. Todos os dados que ocorrem durante o período identificado são ignorados nos seus resultados.
• Availability Target %: Este parâmetro especifica seu objetivo de destino e usa valores personalizados.

Página de 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 falha de ponta a ponta
• Tempo de inatividade do aplicativo

As instâncias de interrupção são determinadas a partir do momento em que um teste começa a falhar até ser aprovado novamente, de acordo com seus parâmetros de interrupção. Se um teste começar a falhar às 8h00 e for bem-sucedido novamente às 10h00, todo esse período de dados será considerado como 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 do Application Insights baseado no espaço de trabalho.

Tempo de inatividade, interrupções e falhas

Existem duas outras abas junto da página Visão geral:

• O separador Interrupções e Tempo de Inatividade tem informações sobre o total de instâncias de interrupção e o tempo total de inatividade dividido por teste.

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

Outras funcionalidades

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

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

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

Próximos passos

• Consulte as perguntas frequentes (FAQ), consulte Perguntas frequentes sobre testes de disponibilidade e Suporte TLS para testes de disponibilidade FAQ
• Solucionar problemas de disponibilidade
• Explore Testes de Web Modelo do Resource Manager da Azure
• Saiba mais sobre a API REST de teste da Web