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

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

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

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

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

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

  Узнайте, как создать стандартный тест.

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

  Узнайте, как создать пользовательский тест TrackAvailability.

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

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

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

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

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

Метки населения местоположения

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

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

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

   

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

   

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

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

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

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

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

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

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

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

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

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

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

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

  2. Вариант Configure alerts из меню откроет для вас новый опыт, где можно выбрать конкретные тесты или места, на которые можно создавать правила оповещений. Вы можете также настроить группы действий для этого правила оповещения здесь.

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

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

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

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

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

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

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

Начните с просмотра диаграммы в интерфейсе Availability в Портале 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) -RuleSslCheck:$false;
   

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

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

6. Отключите или удалите тест пинга 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-адресов источника/CIDR.

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

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

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

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

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

Устаревшая конфигурация 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.

Как я могу убедиться, что мой веб-тест не будет затронут?

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

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

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

После 1 мая 2025 года как будет изменено поведение веб-тестов для затронутых тестов?

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

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

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

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

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

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

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

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

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