Проверка доступности Application Insights
Application Insights позволяет настроить повторяющиеся веб-тесты, отслеживающие доступность веб-сайта или приложения и скорость реагирования из различных точек по всему миру. Эти тесты доступности отправляют веб-запросы приложению через регулярные интервалы и оповещают вас, если ваше приложение не отвечает, или если время отклика слишком медленно.
Тесты доступности не требуют каких-либо изменений на веб-сайте или приложении, которое вы тестируете. Они работают для любой конечной точки HTTP или HTTPS, доступной из общедоступного Интернета, включая REST API, от которых зависит ваша служба. Это означает, что вы можете отслеживать не только собственные приложения, но и внешние службы, критически важные для функциональных возможностей приложения. Для одного ресурса Application Insights можно создать не более 100 тестов доступности.
Примечание.
Тесты доступности хранятся в зашифрованном виде в соответствии с политиками шифрования данных Azure при хранении .
Типы тестов доступности
Существует четыре вида тестов доступности.
Стандартный тест: тип теста доступности, который проверяет доступность веб-сайта, отправляя один запрос, аналогичный устаревшей проверке ping URL-адреса. Помимо проверки того, отвечает ли конечная точка и измеряет производительность, стандартные тесты также включают допустимость TLS/SSL-сертификата, упреждающая проверка времени существования, команда HTTP-запроса (например,
GETиHEAD), пользовательские заголовки иPOSTпользовательские данные, связанные с HTTP-запросом.Тесты доступности пользовательской трассировки. Если вы решили создать пользовательское приложение для выполнения тестов доступности, используйте метод TrackAvailability() для отправки результатов в Application Insights.
Узнайте, как создать пользовательский тест TrackAvailability.
(не рекомендуется) Многоэтапный веб-тест: вы можете воспроизвести эту запись последовательности веб-запросов для тестирования более сложных сценариев. Многоэтапные веб-тесты создаются в Visual Studio Enterprise и загружаются на портал для выполнения.
(не рекомендуется) Проверка связи ПО URL-адреса. Этот тест можно создать с помощью портал Azure, чтобы проверить, отвечает ли конечная точка и измеряет производительность, связанную с этим ответом. Вы также можете задать настраиваемые критерии успеха с помощью расширенных функций, таких как синтаксический анализ зависимых запросов и разрешение на повторные попытки.
Внимание
Существует два предстоящих теста доступности:
Многоэтапные веб-тесты: 31 августа 2024 г. многоэтапные веб-тесты в Application Insights будут прекращены. Мы советуем пользователям этих тестов перейти на альтернативные тесты доступности до даты выхода на пенсию. После этой даты мы снимем базовую инфраструктуру, которая будет прерывать оставшиеся многофакторные тесты.
Тесты ping URL: 30 сентября 2026 г. тесты ping URL-адресов в Application Insights будут прекращены. Существующие тесты проверки ping URL-адресов будут удалены из ресурсов. Просмотрите цены на стандартные тесты и переход на их использование до 30 сентября 2026 г., чтобы гарантировать, что вы сможете продолжать выполнять одношаговые тесты доступности в ресурсах Application Insights.
Создание теста доступности
Необходимые компоненты
Начало работы
Перейдите к ресурсу Application Insights и откройте интерфейс доступности .
Выберите " Добавить стандартный тест " на верхней панели навигации.
Введите имя теста, URL-адрес и другие параметры, описанные в следующей таблице, а затем нажмите кнопку "Создать".
Section Параметр Description Основные сведения URL-адрес URL-адрес может быть любой веб-страницей, которую вы хотите проверить, но она должна быть видна из общедоступного Интернета. URL-адрес может содержать строку запроса, поэтому вы, например, сможете немного поупражняться в работе с базой данных. Если URL-адрес указывает на перенаправление, мы будем переходить по нему до 10 раз. Анализировать зависимые запросы Тестовые запросы изображений, скриптов, файлов стилей и других файлов, которые являются частью веб-страницы, в ходе тестирования. Записанное время ответа включает время, затраченное на получение этих файлов. Тест завершается ошибкой, если какой-либо из этих ресурсов не удается скачать за отведенное на тест время. Если параметр не выбран, тест запрашивает только файл по указанному URL-адресу. Включение этого параметра позволяет выполнять более тщательную проверку. Тест может завершиться ошибкой для случаев, которые могут быть заметными при просмотре сайта вручную. Мы анализируем только до 15 зависимых запросов. Включение повторных попыток для сбоев тестов доступности Когда тест завершается сбоем, он повторяется через короткий интервал. Сообщение об ошибке отобразится только после трех неудачных попыток подряд. Последующие тесты будут выполняться с обычной частотой. Повторные попытки будут временно приостановлены до следующей успешной попытки. Это правило действует в любом расположении тестирования. Этот вариант является рекомендуемым. В среднем около 80 % неудачных попыток решаются при повторной попытке. Включение допустимости SSL-сертификата Вы можете проверить сертификат SSL на вашем веб-сайте, чтобы убедиться, что он правильно установлен, допустим, надежен и из-за него у пользователей не возникает никаких ошибок. Упреждающая проверка времени существования Эта настройка позволяет определить заданное время до истечения срока действия SSL-сертификата. После истечения срока действия теста завершится сбоем. Периодичность проведения тестирования Задает частоту выполнения теста для всех тестовых расположений. При стандартной частоте в пять минут и с пятью тестовыми расположениями ваш сайт будет проверяться в среднем каждую минуту. Расположения тестирования Наши серверы отправляют веб-запросы по URL-адресу из этих расположений. Чтобы вы могли отличить проблемы с веб-сайтом от проблем с сетью, мы рекомендуем использовать не менее пяти расположений. Вы можете выбрать до 16 таких расположений. Стандартные сведения о тестировании Команда HTTP-запроса Укажите, какие действия необходимо предпринять с запросом. Текст запроса Пользовательские данные, связанные с HTTP-запросом. Вы можете отправить собственные файлы, ввести содержимое или отключить эту функцию. Добавление настраиваемых заголовков Пары "ключ — значение", определяющие рабочие параметры. Критерии успешности Время ожидания теста Уменьшите значение этого параметра, чтобы получать оповещения о медленных откликах. Тест считается ошибкой, если ответы с сайта не получены в течение этого периода. Если вы выбрали зависимые запросы, все изображения, файлы стилей, скрипты и другие зависимые ресурсы должны быть получены в течение этого периода. HTTP-ответ Возвращенный код состояния считается успешной. Число 200 — это код, указывающий, что возвращается обычная веб-страница. Совпадение содержимого Произвольная строка, например "Welcome!". Мы проверяем наличие точного совпадения (с учетом регистра) со строкой в каждом ответе. Это должна быть строка обычного текста без подстановочных знаков. Не забывайте, что при изменении содержимого страницы необходимо обновить эту строку. Поддерживаются только английские символы с совпадением содержимого.
Оповещения о доступности
Оповещения автоматически включены по умолчанию, но для полной настройки оповещения необходимо изначально создать тест доступности.
| Параметр | Description |
|---|---|
| Почти в режиме реального времени | Мы рекомендуем использовать оповещения практически в режиме реального времени. Настройка этого типа оповещений выполняется после создания теста доступности. |
| Пороговое значение для расположения оповещения | Мы рекомендуем как минимум 3 из 5 расположений. Оптимальное отношение между пороговым значением для оповещения расположения и числом тестовых расположений: пороговое значение для оповещения расположения = число расположений теста – 2, минимум с пятью расположениями теста. |
Обозначения местоположений
При развертывании стандартного теста или проверки связи ПО URL-адреса можно использовать следующие теги популяции для атрибута географического расположения с помощью Azure Resource Manager.
| Provider | Показать имя | Обозначение |
|---|---|---|
| Azure | ||
| Восточная Австралия | emea-au-syd-edge | |
| Южная Бразилия | latam-br-gru-edge | |
| Центральная часть США | us-fl-mia-edge | |
| Восточная Азия | apac-hk-hkn-azr | |
| Восточная часть США | us-va-ash-azr | |
| Южная Франция (прежнее название — Центральная Франция) | emea-ch-zrh-edge | |
| Центральная Франция | emea-fr-pra-edge | |
| Восточная Япония | apac-jp-kaw-edge | |
| Северная Европа | emea-gb-db3-azr | |
| Центрально-северная часть США | us-il-ch1-azr | |
| Центрально-южная часть США | us-tx-sn1-azr | |
| Юго-Восточная Азия | apac-sg-sin-azr | |
| западная часть Соединенного Королевства | emea-se-sto-edge | |
| Западная Европа | emea-nl-ams-azr | |
| западная часть США | us-ca-sjc-azr | |
| южная часть Соединенного Королевства | emea-ru-msa-edge | |
| Azure для государственных организаций | ||
| USGov Вирджиния | usgov-va-azr | |
| US Gov (Аризона). | usgov-phx-azr | |
| USGov Техас | usgov-tx-azr | |
| Восточная часть США (DoD) | usgov-ddeast-azr | |
| Центральная часть США (DoD) | usgov-ddcentral-azr | |
| Microsoft Azure, управляемый 21Vianet | ||
| Восточный Китай | mc-cne-azr | |
| Восточный Китай 2 | mc-cne2-azr | |
| Северный Китай | mc-cnn-azr | |
| Северный Китай 2 | mc-cnn2-azr |
Включение оповещений
Примечание.
В новых унифицированных оповещениях настройки серьезности и уведомлений для правила генерации оповещений с помощью группы действийдолжны настраиваться в интерфейсе оповещений. Без следующих шагов вы получите только уведомления на портале.
После сохранения теста доступности откройте контекстное меню, выполнив тест, а затем страницу "Открыть правила (оповещения").
На странице правил генерации оповещений откройте оповещение, а затем нажмите кнопку "Изменить" на верхней панели навигации. Здесь можно задать уровень серьезности, описание правила и группу действий с предпочтениями уведомлений, которые вы хотите использовать для этого правила генерации оповещений.
Критерии оповещений
Автоматическое включение оповещений о доступности активирует одно сообщение электронной почты, когда конечная точка становится недоступной, а другая электронная почта снова доступна. Оповещения о доступности, созданные с помощью этого интерфейса, основаны на состоянии. При выполнении условий генерации оповещений создается одно оповещение при обнаружении веб-сайта как недоступного. Если веб-сайт по-прежнему отключен при следующем вычислении условий генерации оповещений, он не создаст новое оповещение.
Например, предположим, что ваш веб-сайт отключен в течение часа, и вы настроили оповещение электронной почты с частотой оценки в 15 минут. Вы получаете только сообщение электронной почты, когда веб-сайт выходит из строя, и другое сообщение электронной почты, когда он возвращается в интернет. Вы не получаете непрерывных оповещений каждые 15 минут, чтобы напомнить вам, что веб-сайт по-прежнему недоступен.
Изменение условий генерации оповещений
Возможно, вы не хотите получать уведомления, если веб-сайт не работает в течение короткого периода времени, например во время обслуживания. Вы можете изменить частоту оценки на более высокое значение, чем ожидаемое время простоя, до 15 минут. Можно также увеличить порог расположения оповещений, чтобы он активировал оповещение только в том случае, если веб-сайт отключен для определенного количества регионов.
Совет
Для более длительных запланированных простоев временно отключите правило генерации оповещений или создайте пользовательское правило. Он предоставляет дополнительные возможности для учета простоя.
Чтобы внести изменения в пороговое значение расположения, период агрегирования и частоту тестирования, перейдите на страницу правила изменения генерации оповещений (см. шаг 2 в разделе "Включить оповещения"), а затем выберите условие, чтобы открыть окно логики настройки сигнала.
Создание настраиваемого правила генерации оповещений
Если вам нужны дополнительные возможности, можно создать настраиваемое правило генерации оповещений на вкладке "Оповещения". Выберите "Создать>правило генерации оповещений". Выберите метрики для типа signal, чтобы отобразить все доступные сигналы и выбрать доступность.
Пользовательское правило генерации оповещений предлагает более высокие значения для периода агрегирования (вместо 24 часов вместо 6 часов) и частоту тестирования (до 1 часа вместо 15 минут). Также в нем добавлены параметры для дальнейшего определения логики путем выбора различных операторов, типов агрегирования и пороговых значений.
Оповещение о сбоях Y из расположений Y. Правило генерации оповещений Y по умолчанию включено в новом едином интерфейсе оповещений при создании нового теста доступности. Вы можете отказаться, выбрав параметр "классический" или выбрав отключить правило генерации оповещений. Настройте группы действий для получения уведомлений при активации оповещений, выполнив описанные выше действия. Без этого шага вы получаете уведомления только на портале при активации правила.
Оповещения о метриках доступности: с помощью новых унифицированных оповещений можно также оповещать о сегментированной статистической доступности и метриках длительности тестирования:
Выберите ресурс Application Insights в интерфейсе метрик и выберите метрику доступности .
Параметр "Настройка оповещений" в меню позволяет выбрать определенные тесты или расположения, в которых можно настроить правила генерации оповещений. Здесь можно также настроить группы действий для этого правила.
Оповещение о пользовательских запросах аналитики: с помощью новых унифицированных оповещений можно генерации оповещений о пользовательских запросах журналов. С помощью настраиваемых запросов вы можете создать оповещение с любым произвольным условием, которое поможет вам получить самый надежный сигнал о проблемах с доступностью. Это также применимо, если вы отправляете пользовательские результаты доступности с помощью пакета 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-адреса.
Внимание
Стоимость связана с выполнением стандартных тестов. После создания стандартного теста вы будете взиматься плата за выполнение тестов. Прежде чем начать этот процесс, ознакомьтесь с ценами на Azure Monitor.
Необходимые компоненты
- Любой тест проверки ping URL-адреса в Application Insights
- Доступ к Azure PowerShell
Начало работы
Подключитесь к подписке с помощью Azure PowerShell (
Connect-AzAccount+Set-AzContext).Список всех тестов проверки ping URL-адресов в текущей подписке:
Get-AzApplicationInsightsWebTest | ` Where-Object { $_.WebTestKind -eq "ping" } | ` Format-Table -Property ResourceGroupName,Name,WebTestKind,Enabled;Найдите тест ping URL-адреса, который вы хотите перенести и записать ее группу ресурсов и имя.
Создайте стандартный тест с той же логикой, что и тест 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-адреса не вносятся, чтобы вы могли продолжать полагаться на них для оповещений.
Проверьте функциональные возможности нового стандартного теста, а затем обновите правила генерации оповещений, ссылающиеся на тест ping URL-адреса, чтобы ссылаться на стандартный тест.
Отключите или удалите тест проверки ping URL-адреса. Для этого с помощью Azure PowerShell можно использовать следующую команду:
Remove-AzApplicationInsightsWebTest -ResourceGroupName $resourceGroup -Name $pingTestName;
Тестирование за брандмауэром
Чтобы обеспечить доступность конечных точек за брандмауэрами, включите открытые тесты доступности или запустите тесты доступности в отключенном режиме или нет сценариев входящего трафика.
Включение теста общедоступной доступности
Убедитесь, что внутренний веб-сайт содержит запись общедоступной системы доменных имен (DNS). Тесты доступности завершаются ошибкой, если не удается разрешить DNS. Дополнительные сведения см. в статье "Создание личного доменного имени для внутреннего приложения".
Предупреждение
IP-адреса, используемые службой тестов доступности, являются общими и могут предоставлять конечные точки службы, защищенные брандмауэром, другим тестам. Фильтрация IP-адресов не защищает трафик вашей службы, поэтому рекомендуется добавить дополнительные пользовательские заголовки для проверки происхождения веб-запроса. Дополнительные сведения см. в разделе тегов службы виртуальной сети.
Проверка подлинности трафика
Задайте настраиваемые заголовки в стандартных тестах для проверки трафика.
Создайте буквенно-цифровые строки без пробелов, чтобы определить этот тест доступности (например, MyAppAvailabilityTest). Здесь мы называем эту строку идентификатором строки теста доступности.
Добавьте пользовательский заголовок X-Customer-InstanceId со значением
ApplicationInsightsAvailability:<your availability test string identifier>в разделе сведений о тестировании уровня "Стандартный" при создании или обновлении тестов доступности.
Убедитесь, что входящий трафик включает заголовок и значение, определенное на предыдущих шагах.
Кроме того, задайте идентификатор строки теста доступности в качестве параметра запроса.
Пример: https://yourtestendpoint/?x-customer-instanceid=applicationinsightsavailability:<your availability test string identifier>
Настройка брандмауэра для разрешения входящих запросов из тестов доступности
Примечание.
Этот пример предназначен для использования тега службы группы безопасности сети. Многие службы Azure принимают теги служб, каждый из которых требует различных действий по настройке.
Чтобы упростить включение служб Azure без авторизации отдельных IP-адресов или поддержания актуального списка IP-адресов, используйте теги служб. Примените эти теги между Брандмауэр Azure и группами безопасности сети, позволяя службе тестирования доступности обращаться к конечным точкам. Тег ApplicationInsightsAvailability службы применяется ко всем тестам доступности.
Если вы используете группы безопасности сети Azure, перейдите к ресурсу группы безопасности сети и в разделе "Параметры", откройте правила безопасности для входящего трафика, а затем нажмите кнопку "Добавить".
Затем выберите тег службы в качестве исходного и ApplicationInsightsAvailability в качестве тега службы источника. Используйте открытые порты 80 (http) и 443 (https) для входящего трафика от тега службы.
Чтобы управлять доступом, когда конечные точки находятся за пределами Azure или если теги служб не являются вариантом, укажите IP-адреса наших агентов веб-тестирования. Диапазоны IP-адресов можно запрашивать с помощью PowerShell, Azure CLI или вызова REST с помощью API тегов службы. Полный список текущих тегов службы и их IP-адресов скачайте JSON-файл.
В ресурсе группы безопасности сети в разделе "Параметры" откройте интерфейс правил безопасности для входящего трафика, а затем нажмите кнопку "Добавить".
Затем выберите IP-адреса в качестве источника. Затем добавьте IP-адреса в список с разделителями-запятыми в диапазонах IP-адресов источника или CIRD.
Сценарии с отключением или без входящего трафика
Подключите ресурс Application Insights к внутренней конечной точке службы с помощью Приватный канал Azure.
Напишите пользовательский код для периодической проверки внутреннего сервера или конечных точек. Отправьте результаты в Application Insights с помощью API TrackAvailability() в основном пакете SDK.
Поддерживаемые конфигурации TLS
Чтобы обеспечить лучшее шифрование в классе, все тесты доступности используют tls 1.2 и 1.3 в качестве механизмов шифрования. Кроме того, следующие наборы шифров и эллиптические кривые также поддерживаются в каждой версии.
TLS 1.3 в настоящее время доступен только в регионах тестирования доступности NorthCentralUS, CentralUS, EastUS, SouthCentralUS и WestUS.
| Версия | Комплекты шифров | Эллиптические кривые |
|---|---|---|
| TLS 1.2 | • 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 |
• NistP384 • NistP256 |
| Протокол TLS 1.3 | • TLS_AES_256_GCM_SHA384 • TLS_AES_128_GCM_SHA256 |
• NistP384 • NistP256 |
Нерекомендуемая конфигурация TLS
Внимание
1 марта 2025 г. в соответствии с устаревшими версиями TLS Azure, версиями протокола TLS 1.0/1.1 и перечисленными версиями протокола TLS 1.2/1.3 устаревшие наборы шифров и эллиптические кривые будут прекращены для тестов доступности Application Insights.
TLS 1.0 и TLS 1.1
Tls 1.0 и TLS 1.1 удаляются.
TLS 1.2 и TLS 1.3
| Версия | Комплекты шифров | Эллиптические кривые |
|---|---|---|
| TLS 1.2 | • 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 |
• кривая25519 |
| Протокол TLS 1.3 | • кривая25519 |
Устранение неполадок
Предупреждение
Недавно мы включили TLS 1.3 в тестах доступности. Если в результате отображаются новые сообщения об ошибках, убедитесь, что клиенты, работающие в Windows Server 2022 с включенным протоколом TLS 1.3, могут подключаться к конечной точке. Если этого не удается сделать, вы можете временно отключить TLS 1.3 в конечной точке, чтобы тесты доступности вернулись к более старым версиям TLS.
Дополнительные сведения см. в статье по устранению неполадок.
Книга простоя и простоев
В этом разделе представлен простой способ вычисления и отчета о соглашении об уровне обслуживания (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 поддерживается на удаленной конечной точке с компьютера, имеющего доступ к вызову конечной точки.
Примечание.
Чтобы включить необходимую конфигурацию 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".