Проверка доступности Application Insights

Application Insights позволяет настроить повторяющиеся веб-тесты, отслеживающие доступность веб-сайта или приложения и скорость реагирования из различных точек по всему миру. Эти тесты доступности отправляют веб-запросы приложению через регулярные интервалы и оповещают вас, если ваше приложение не отвечает, или если время отклика слишком медленно.

Тесты доступности не требуют каких-либо изменений на веб-сайте или приложении, которое вы тестируете. Они работают для любой конечной точки HTTP или HTTPS, доступной из общедоступного Интернета, включая REST API, от которых зависит ваша служба. Это означает, что вы можете отслеживать не только собственные приложения, но и внешние службы, критически важные для функциональных возможностей приложения. Для одного ресурса Application Insights можно создать не более 100 тестов доступности.

Типы тестов доступности

Существует четыре вида тестов доступности.

• Стандартный тест: тип теста доступности, который проверяет доступность веб-сайта, отправляя один запрос, аналогичный устаревшей проверке ping URL-адреса. Помимо проверки того, отвечает ли конечная точка и измеряет производительность, стандартные тесты также включают допустимость TLS/SSL-сертификата, упреждающая проверка времени существования, команда HTTP-запроса (например, GETиHEAD ), пользовательские заголовки и POSTпользовательские данные, связанные с HTTP-запросом.

• Тесты доступности пользовательской трассировки. Если вы решили создать пользовательское приложение для выполнения тестов доступности, используйте метод TrackAvailability() для отправки результатов в Application Insights.

• (не рекомендуется) Многоэтапный веб-тест: вы можете воспроизвести эту запись последовательности веб-запросов для тестирования более сложных сценариев. Многоэтапные веб-тесты создаются в Visual Studio Enterprise и загружаются на портал для выполнения.

• (не рекомендуется) Проверка связи ПО URL-адреса. Этот тест можно создать с помощью портал Azure, чтобы проверить, отвечает ли конечная точка и измеряет производительность, связанную с этим ответом. Вы также можете задать настраиваемые критерии успеха с помощью расширенных функций, таких как синтаксический анализ зависимых запросов и разрешение на повторные попытки.

Создание теста доступности

Оповещения о доступности

Оповещения автоматически включены по умолчанию, но для полной настройки оповещения необходимо изначально создать тест доступности.

Обозначения местоположений

При развертывании стандартного теста или проверки связи ПО URL-адреса можно использовать следующие теги популяции для атрибута географического расположения с помощью Azure Resource Manager.

Включение оповещений

1. После сохранения теста доступности откройте контекстное меню, выполнив тест, а затем страницу "Открыть правила (оповещения").

   

2. На странице правил генерации оповещений откройте оповещение, а затем нажмите кнопку "Изменить" на верхней панели навигации. Здесь можно задать уровень серьезности, описание правила и группу действий с предпочтениями уведомлений, которые вы хотите использовать для этого правила генерации оповещений.

   

Критерии оповещений

Автоматическое включение оповещений о доступности активирует одно сообщение электронной почты, когда конечная точка становится недоступной, а другая электронная почта снова доступна. Оповещения о доступности, созданные с помощью этого интерфейса, основаны на состоянии. При выполнении условий генерации оповещений создается одно оповещение при обнаружении веб-сайта как недоступного. Если веб-сайт по-прежнему отключен при следующем вычислении условий генерации оповещений, он не создаст новое оповещение.

Например, предположим, что ваш веб-сайт отключен в течение часа, и вы настроили оповещение электронной почты с частотой оценки в 15 минут. Вы получаете только сообщение электронной почты, когда веб-сайт выходит из строя, и другое сообщение электронной почты, когда он возвращается в интернет. Вы не получаете непрерывных оповещений каждые 15 минут, чтобы напомнить вам, что веб-сайт по-прежнему недоступен.

Изменение условий генерации оповещений

Возможно, вы не хотите получать уведомления, если веб-сайт не работает в течение короткого периода времени, например во время обслуживания. Вы можете изменить частоту оценки на более высокое значение, чем ожидаемое время простоя, до 15 минут. Можно также увеличить порог расположения оповещений, чтобы он активировал оповещение только в том случае, если веб-сайт отключен для определенного количества регионов.

Чтобы внести изменения в пороговое значение расположения, период агрегирования и частоту тестирования, перейдите на страницу правила изменения генерации оповещений (см. шаг 2 в разделе "Включить оповещения"), а затем выберите условие, чтобы открыть окно логики настройки сигнала.

Создание настраиваемого правила генерации оповещений

Если вам нужны дополнительные возможности, можно создать настраиваемое правило генерации оповещений на вкладке "Оповещения". Выберите "Создать>правило генерации оповещений". Выберите метрики для типа signal, чтобы отобразить все доступные сигналы и выбрать доступность.

Пользовательское правило генерации оповещений предлагает более высокие значения для периода агрегирования (вместо 24 часов вместо 6 часов) и частоту тестирования (до 1 часа вместо 15 минут). Также в нем добавлены параметры для дальнейшего определения логики путем выбора различных операторов, типов агрегирования и пороговых значений.

• Оповещение о сбоях Y из расположений Y. Правило генерации оповещений Y по умолчанию включено в новом едином интерфейсе оповещений при создании нового теста доступности. Вы можете отказаться, выбрав параметр "классический" или выбрав отключить правило генерации оповещений. Настройте группы действий для получения уведомлений при активации оповещений, выполнив описанные выше действия. Без этого шага вы получаете уведомления только на портале при активации правила.

• Оповещения о метриках доступности: с помощью новых унифицированных оповещений можно также оповещать о сегментированной статистической доступности и метриках длительности тестирования:

  1. Выберите ресурс Application Insights в интерфейсе метрик и выберите метрику доступности .

  2. Параметр "Настройка оповещений" в меню позволяет выбрать определенные тесты или расположения, в которых можно настроить правила генерации оповещений. Здесь можно также настроить группы действий для этого правила.

• Оповещение о пользовательских запросах аналитики: с помощью новых унифицированных оповещений можно генерации оповещений о пользовательских запросах журналов. С помощью настраиваемых запросов вы можете создать оповещение с любым произвольным условием, которое поможет вам получить самый надежный сигнал о проблемах с доступностью. Это также применимо, если вы отправляете пользовательские результаты доступности с помощью пакета SDK TrackAvailability.

  Метрики данных доступности включают любые результаты пользовательской доступности, которые вы можете отправить, вызвав пакет SDK TrackAvailability. Поддержку оповещений о метриках можно использовать для оповещения о доступности результатов.

Автоматизация оповещений

Чтобы автоматизировать этот процесс с помощью шаблонов Azure Resource Manager, см . статью "Создание оповещений метрик" с помощью шаблона Azure Resource Manager.

Просмотр результатов теста доступности

В этом разделе объясняется, как проверить результаты теста доступности в портал Azure и запрашивать данные с помощью Log Analytics. Результаты теста доступности можно визуализировать с помощью представлений "Линии " и "Точечная диаграмма ".

Проверить доступность

Начните с просмотра графа в интерфейсе доступности в портал Azure.

По умолчанию в интерфейсе доступности показан график линий. Измените представление на точечную диаграмму (переключение над графом), чтобы просмотреть примеры результатов теста с подробными сведениями о шаге диагностики. Обработчик тестов хранит сведения о диагностике тестов, которые завершились сбоем. Диагностические сведения об успешно выполненных тестах хранятся для подмножества выполнений. Чтобы просмотреть тест, имя теста и расположение, наведите указатель мыши на любую из зеленых точек или красных крестов.

Выберите конкретный тест или расположение. Кроме того, можно уменьшить период времени, чтобы увидеть больше результатов в течение интересующего периода. Используйте обозреватель поиска, чтобы просмотреть результаты всех выполнений. Вы также можете использовать запросы Log Analytics для запуска пользовательских отчетов по этим данным.

Чтобы просмотреть подробные сведения о транзакциях, в разделе "Детализация" выберите "Успешно" или "Сбой". Затем выберите пример. Можно также перейти к подробным сведениям о сквозной транзакции, выбрав на диаграмме точку данных.

Проверка и изменение тестов

Чтобы изменить, временно отключить или удалить тест, откройте контекстное меню (многоточие) теста, а затем нажмите кнопку "Изменить". После внесения изменений в конфигурацию может потребоваться до 20 минут.

При возникновении сбоев

Откройте представление сведений о сквозной транзакции, выбрав красный крест на точечной диаграмме.

Здесь можно:

• Просмотрите отчет об устранении неполадок, чтобы определить, что потенциально вызвало сбой теста.
• изучить ответ, полученный от сервера;
• диагностировать сбой на основе коррелированной телеметрии на стороне сервера, собранной во время обработки теста доступности, завершившегося сбоем;
• Отслеживайте проблему путем ведения журнала проблемы или рабочего элемента в Git или Azure Boards. Ошибка содержит ссылку на событие в портал Azure.
• открыть результат веб-теста в Visual Studio.

Дополнительные сведения о сквозной диагностика транзакций см. в документации по транзакциям диагностика.

Выберите строку исключения, чтобы просмотреть сведения об исключении на стороне сервера, вызвавшего сбой синтетического теста доступности. Вы также можете получить моментальный снимок отладки для более широкой диагностики на уровне кода.

Помимо необработанных результатов, можно также просмотреть две ключевые метрики доступности в обозревателе метрик:

• Доступность. Количество успешно выполненных тестов (в процентах).
• Продолжительность тестов. Средняя длительность всех тестов.

Запрос в Log Analytics

Вы можете использовать Log Analytics для просмотра результатов доступности (), зависимостей (availabilityResultsdependencies) и т. д. Дополнительные сведения о Log Analytics см. в обзоре запросов журнала.

Перенос классических тестов проверки ping URL-адреса на стандартные тесты

Ниже описан процесс создания стандартных тестов , которые реплицируют функциональные возможности тестов проверки ping URL-адреса. Это позволяет проще начать использовать расширенные функции стандартных тестов с помощью ранее созданных тестов URL-адреса.

Необходимые компоненты

Начало работы

1. Подключитесь к подписке с помощью Azure PowerShell (Connect-AzAccount + Set-AzContext).

2. Список всех тестов проверки ping URL-адресов в текущей подписке:

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

3. Найдите тест ping URL-адреса, который вы хотите перенести и записать ее группу ресурсов и имя.

4. Создайте стандартный тест с той же логикой, что и тест ping URL-адреса, используя следующие команды, которые работают для конечных точек HTTP и 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);
   

   По умолчанию новый стандартный тест не содержит правил генерации оповещений, поэтому он не создает шумные оповещения. Изменения в тесте проверки ping URL-адреса не вносятся, чтобы вы могли продолжать полагаться на них для оповещений.

5. Проверьте функциональные возможности нового стандартного теста, а затем обновите правила генерации оповещений, ссылающиеся на тест ping URL-адреса, чтобы ссылаться на стандартный тест.

6. Отключите или удалите тест проверки ping URL-адреса. Для этого с помощью Azure PowerShell можно использовать следующую команду:

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

Тестирование за брандмауэром

Чтобы обеспечить доступность конечных точек за брандмауэрами, включите открытые тесты доступности или запустите тесты доступности в отключенном режиме или нет сценариев входящего трафика.

Включение теста общедоступной доступности

Убедитесь, что внутренний веб-сайт содержит запись общедоступной системы доменных имен (DNS). Тесты доступности завершаются ошибкой, если не удается разрешить DNS. Дополнительные сведения см. в статье "Создание личного доменного имени для внутреннего приложения".

Проверка подлинности трафика

Задайте пользовательские заголовки в стандартных тестах доступности для проверки трафика.

1. Создайте буквенно-цифровые строки без пробелов, чтобы определить этот тест доступности (например, MyAppAvailabilityTest). Здесь мы называем эту строку идентификатором строки теста доступности.

2. Добавьте пользовательский заголовок X-Customer-InstanceId со значением ApplicationInsightsAvailability:<your availability test string identifier> в разделе сведений о тестировании уровня "Стандартный" при создании или обновлении тестов доступности.

   

3. Убедитесь, что входящий трафик включает заголовок и значение, определенное на предыдущих шагах.

Кроме того, задайте идентификатор строки теста доступности в качестве параметра запроса.

Пример: https://yourtestendpoint/?x-customer-instanceid=applicationinsightsavailability:<your availability test string identifier>

Настройка брандмауэра для разрешения входящих запросов из тестов доступности

Чтобы упростить включение служб Azure без авторизации отдельных IP-адресов или поддержания актуального списка IP-адресов, используйте теги служб. Примените эти теги между Брандмауэр Azure и группами безопасности сети, позволяя службе тестирования доступности обращаться к конечным точкам. Тег ApplicationInsightsAvailability службы применяется ко всем тестам доступности.

1. Если вы используете группы безопасности сети Azure, перейдите к ресурсу группы безопасности сети и в разделе "Параметры", откройте правила безопасности для входящего трафика, а затем нажмите кнопку "Добавить".

2. Затем выберите тег службы в качестве исходного и ApplicationInsightsAvailability в качестве тега службы источника. Используйте открытые порты 80 (http) и 443 (https) для входящего трафика от тега службы.

Чтобы управлять доступом, когда конечные точки находятся за пределами Azure или если теги служб не являются вариантом, укажите IP-адреса наших агентов веб-тестирования. Диапазоны IP-адресов можно запрашивать с помощью PowerShell, Azure CLI или вызова REST с помощью API тегов службы. Полный список текущих тегов службы и их IP-адресов скачайте JSON-файл.

1. В ресурсе группы безопасности сети в разделе "Параметры" откройте интерфейс правил безопасности для входящего трафика, а затем нажмите кнопку "Добавить".

2. Затем выберите IP-адреса в качестве источника. Затем добавьте IP-адреса в список с разделителями-запятыми в диапазонах IP-адресов источника или CIRD.

Сценарии с отключением или без входящего трафика

1. Подключите ресурс Application Insights к внутренней конечной точке службы с помощью Приватный канал Azure.

2. Напишите пользовательский код для периодической проверки внутреннего сервера или конечных точек. Отправьте результаты в Application Insights с помощью API TrackAvailability() в основном пакете SDK.

Поддерживаемые конфигурации TLS

Чтобы обеспечить лучшее шифрование в классе, все тесты доступности используют tls 1.2 и 1.3 в качестве механизмов шифрования. Кроме того, следующие наборы шифров и эллиптические кривые также поддерживаются в каждой версии.

TLS 1.3 в настоящее время доступен только в регионах тестирования доступности NorthCentralUS, CentralUS, EastUS, SouthCentralUS и WestUS.

Нерекомендуемая конфигурация TLS

TLS 1.0 и TLS 1.1

Tls 1.0 и TLS 1.1 удаляются.

TLS 1.2 и TLS 1.3

Устранение неполадок

Книга простоя и простоев

В этом разделе представлен простой способ вычисления и отчета о соглашении об уровне обслуживания (SLA) для веб-тестов через одну панель стекла в ресурсах Application Insights и подписках Azure. Отчет о простоях и сбоях содержит информативные предварительно созданные запросы и визуализации данных, которые позволяют оценить возможности подключения клиента, типичное время отклика приложений и время простоя.

Шаблон книги SLA можно получить из ресурса Application Insights двумя способами:

• Откройте интерфейс доступности и выберите отчет об уровне обслуживания в верхней панели навигации.

• Откройте интерфейс книг, а затем выберите шаблон "Простой" и "Простои".

Гибкость параметров

Параметры, заданные в книге, влияют на остальную часть отчета.

• Subscriptions, App Insights Resourcesи Web Test: эти параметры определяют параметры ресурса высокого уровня. Они основаны на запросах Log Analytics и используются в каждом запросе отчета.
• Failure Threshold и Outage Window: эти параметры можно использовать для определения собственных критериев сбоя службы. Примером является критерий оповещения о доступности Application Insights на основе счетчика расположения сбоем в течение выбранного периода. Типичный порог — три расположения в течение пяти минут.
• Maintenance Period: этот параметр можно использовать для выбора типичной частоты обслуживания. Maintenance Window — это селектор даты и времени для примера периода обслуживания. Все данные, возникающие в течение определенного периода, игнорируются в результатах.
• Availability Target %: этот параметр задает целевую цель и принимает пользовательские значения.

Страница обзора

Страница обзора содержит общие сведения о вашем:

• Общее соглашение об уровне обслуживания (за исключением периодов обслуживания, если определено)
• Сквозные экземпляры сбоя
• Время простоя приложения

Экземпляры сбоя определяются с момента, когда тест начинает завершать сбой, пока он не пройдет снова, в соответствии с параметрами сбоя. Если тест начинается сбой в 8:00 и завершается снова в 10:00, то весь период данных считается одинаковым сбоем. Вы также можете исследовать самый длинный сбой, который произошел в течение отчетного периода.

Некоторые тесты можно связать с ресурсом Application Insights для дальнейшего изучения. Но это возможно только в ресурсе Application Insights на основе рабочей области.

Простой, сбои и отказы

Рядом со страницей обзора рядом с двумя дополнительными вкладками:

• Вкладка "Сбои" и "Время простоя" содержит сведения об общих экземплярах сбоя и общее время простоя, разбитое на тест.

• Вкладка "Сбои по расположению " содержит гео-карту мест неудачного тестирования для выявления потенциальных областей подключения к проблемам.

Другие функции

• Настройка. Вы можете изменить отчет, как и любую другую книгу Azure Monitor, и настроить запросы или визуализации в зависимости от потребностей вашей команды.

• Log Analytics: все запросы могут выполняться в Log Analytics и использоваться в других отчетах или панелях мониторинга. Удалите ограничение параметров и повторно используйте базовый запрос.

• Доступ к отчету и совместному доступу: отчет можно предоставить своим командам и руководству или закрепить на панели мониторинга для дальнейшего использования. Пользователю требуются разрешения на чтение и доступ к ресурсу Application Insights, в котором хранится фактическая книга.

Часто задаваемые вопросы

В этом разделы приводятся ответы на часто задаваемые вопросы.

Общие

Можно ли выполнять тесты доступности на сервере интрасети?

Наши веб-тесты выполняются в точках подключения, которые распределены по всему миру. Есть два решения.

• Дверь брандмауэра. Разрешите запросы к серверу из длинного и изменяемого списка агентов веб-тестирования.
• Пользовательский код: напишите собственный код для отправки периодических запросов на сервер из интрасети. Для этой цели можно выполнять веб-тесты Visual Studio. Тестировщик может отправлять результаты в Application Insights с помощью TrackAvailability() API.

Что такое строка агента пользователя для тестов доступности?

Строка агента пользователя — Mozilla/5.0 (совместима; MSIE 9.0; Windows NT 6.1; Trident/5.0; AppInsights)

Поддержка TLS

Как это нерекомендуемо влияет на поведение веб-теста?

Тесты доступности выполняют роль распределенного клиента в каждом из поддерживаемых расположений веб-тестов. Каждый раз, когда веб-тест выполняется, служба тестирования доступности пытается обратиться к удаленной конечной точке, определенной в конфигурации веб-теста. Сообщение TLS Client Hello отправляется, содержащее всю поддерживаемую конфигурацию TLS. Если удаленная конечная точка использует общую конфигурацию TLS с клиентом тестирования доступности, то подтверждение TLS завершается успешно. В противном случае веб-тест завершается ошибкой подтверждения TLS.

Разделы справки убедитесь, что веб-тест не влияет?

Чтобы избежать каких-либо последствий, каждая удаленная конечная точка (включая зависимые запросы) веб-теста взаимодействует с потребностями в поддержке по крайней мере одной комбинации одной версии протокола, Cipher Suite и Эллиптической кривой, которая выполняет тест доступности. Если удаленная конечная точка не поддерживает необходимую конфигурацию TLS, ее необходимо обновить с поддержкой определенной комбинации указанной выше конфигурации TLS после отмены. Эти конечные точки можно обнаружить с помощью просмотра сведений о транзакциях веб-теста (в идеале для успешного выполнения веб-теста).

Разделы справки проверить, какая конфигурация TLS поддерживает удаленную конечную точку?

Существует несколько средств для проверки поддержки конфигурации TLS конечной точки. Одним из способов будет следовать примеру, подробному на этой странице. Если удаленная конечная точка недоступна через Общедоступный Интернет, необходимо убедиться, что конфигурация TLS поддерживается на удаленной конечной точке с компьютера, имеющего доступ к вызову конечной точки.

После 31 октября 2024 г. поведение веб-теста будет использоваться для затронутых тестов?

Существует ни один тип исключения, с которыми повлияли все сбои подтверждения TLS, затронутые этим нерекомендуемым. Однако наиболее распространенное исключение веб-теста начнется сбоем The request was aborted: Couldn't create SSL/TLS secure channel. Кроме того, вы должны увидеть все связанные с TLS ошибки в шаге устранения неполадок транспорта TLS для результата веб-теста, который потенциально влияет.

Можно ли просмотреть конфигурацию TLS, используемую веб-тестом?

Конфигурация TLS, согласованная во время выполнения веб-теста, не может быть просмотрна. Если удаленная конечная точка поддерживает общую конфигурацию TLS с тестами доступности, влияние не должно быть видно после отмены.

Какие компоненты влияют на нерекомендуемую службу тестирования доступности?

Отмена TLS, описанная в этом документе, должна повлиять только на поведение выполнения веб-теста доступности после 31 октября 2024 года. Дополнительные сведения об взаимодействии со службой тестирования доступности для операций CRUD см. в статье "Поддержка TLS Azure Resource Manager". Этот ресурс содержит дополнительные сведения о поддержке TLS и временной шкале нерекомендуемой поддержки TLS.

Где можно получить поддержку TLS?

Общие вопросы о устаревшей проблеме TLS см. в разделе "Решение проблем TLS".

Следующие шаги

• Устранение неполадок
• Веб-тесты шаблона Azure Resource Manager
• REST API веб-теста