Проверка доступности Application Insights
После развертывания веб-приложения или веб-сайта можно настроить повторяющиеся тесты для мониторинга доступности и реагирования. Компонент Application Insights отправляет веб-запросы через одинаковые промежутки времени из разных точек по всему миру. Вы можете получать оповещения о том, что приложение не отвечает или реагирует слишком медленно. Для одного ресурса Application Insights можно создать не более 100 тестов доступности.
Тесты доступности не требуют каких-либо изменений на веб-сайте, который вы тестируете и работаете для любой конечной точки HTTP или HTTPS, доступной из общедоступного Интернета. Вы также можете проверить доступность REST API, от которой зависит ваша служба.
Примечание.
Тесты доступности хранятся в зашифрованном виде в соответствии с политиками шифрования данных Azure при хранении .
Типы тестов доступности
Существует четыре вида тестов доступности.
Стандартный тест: это тип теста доступности, который проверяет доступность веб-сайта, отправляя один запрос, аналогичный устаревшей проверке связи URL-адреса. Помимо проверки того, отвечает ли конечная точка и измеряет производительность, стандартные тесты также включают допустимость TLS/SSL-сертификата, упреждающая проверка времени существования, команда HTTP-запроса (например,
GETиHEAD), пользовательские заголовки иPOSTпользовательские данные, связанные с HTTP-запросом.Тесты доступности пользовательской трассировки. Если вы решили создать пользовательское приложение для выполнения тестов доступности, используйте метод TrackAvailability() для отправки результатов в Application Insights.
(не рекомендуется) Многоэтапный веб-тест: вы можете воспроизвести эту запись последовательности веб-запросов для тестирования более сложных сценариев. Многоэтапные веб-тесты создаются в Visual Studio Enterprise и загружаются на портал для выполнения.
(не рекомендуется) Проверка связи ПО URL-адреса. Этот тест можно создать с помощью портал Azure, чтобы проверить, отвечает ли конечная точка и измеряет производительность, связанную с этим ответом. Вы также можете задать настраиваемые критерии успеха с помощью расширенных функций, таких как синтаксический анализ зависимых запросов и разрешение на повторные попытки.
Внимание
Существует два предстоящих теста доступности:
Многоэтапные веб-тесты: 31 августа 2024 г. многоэтапные веб-тесты в Application Insights будут прекращены. Мы советуем пользователям этих тестов перейти на альтернативные тесты доступности до даты выхода на пенсию. После этой даты мы снимем базовую инфраструктуру, которая будет прерывать оставшиеся многофакторные тесты.
Тесты ping URL: 30 сентября 2026 г. тесты ping URL-адресов в Application Insights будут прекращены. Существующие тесты проверки ping URL-адресов будут удалены из ресурсов. Просмотрите цены на стандартные тесты и переход на их использование до 30 сентября 2026 г., чтобы гарантировать, что вы сможете продолжать выполнять одношаговые тесты доступности в ресурсах Application Insights.
Создание теста доступности
Совет
Если вы используете другие тесты доступности, такие как тесты ping URL-адреса, вы можете добавить стандартные тесты вместе с другими. Если вы хотите использовать стандартные тесты вместо одного из других тестов, добавьте стандартный тест и удалите старый тест.
Необходимые компоненты
Начать
Перейдите к вашему ресурсу Application Insights и выберите панель Доступность.
Выберите Добавить стандартный тест.
Введите имя теста, URL-адрес и другие параметры, описанные в следующей таблице. Затем выберите Создать.
Параметр Description URL-адрес URL-адрес может быть любой веб-страницей, которую вы хотите проверить, но она должна быть видна из общедоступного Интернета. URL-адрес может содержать строку запроса, поэтому вы, например, сможете немного поупражняться в работе с базой данных. Если URL-адрес указывает на перенаправление, мы будем переходить по нему до 10 раз. Анализировать зависимые запросы Тестовые запросы изображений, скриптов, файлов стилей и других файлов, которые являются частью веб-страницы, в ходе тестирования. Записанное время ответа включает время, затраченное на получение этих файлов. Тест завершается ошибкой, если какой-либо из этих ресурсов не удается скачать за отведенное на тест время. Если параметр не выбран, тест запрашивает только файл по указанному URL-адресу. Включение этого параметра позволяет выполнять более тщательную проверку. Тест может завершиться ошибкой для случаев, которые могут быть заметными при просмотре сайта вручную. Обратите внимание, что мы анализируем только до 15 зависимых запросов. Enable retries (Разрешить повторные попытки) При неудачном завершении теста через короткий промежуток времени будет выполнена повторная попытка. Сообщение об ошибке отобразится только после трех неудачных попыток подряд. Последующие тесты будут выполняться с обычной частотой. Повторные попытки будут временно приостановлены до следующей успешной попытки. Это правило действует в любом расположении тестирования. Этот вариант является рекомендуемым. В среднем около 80 % неудачных попыток решаются при повторной попытке. Проверочный тест SSL-сертификата Вы можете проверить сертификат SSL на вашем веб-сайте, чтобы убедиться, что он правильно установлен, допустим, надежен и из-за него у пользователей не возникает никаких ошибок. Упреждающая проверка времени существования Эта настройка позволяет определить заданное время до истечения срока действия SSL-сертификата. После истечения срока действия теста завершится сбоем. Периодичность проведения тестирования Задает частоту выполнения теста для всех тестовых расположений. При стандартной частоте в пять минут и с пятью тестовыми расположениями ваш сайт будет проверяться в среднем каждую минуту. Расположения тестирования Наши серверы отправляют веб-запросы по URL-адресу из этих расположений. Чтобы вы могли отличить проблемы с веб-сайтом от проблем с сетью, мы рекомендуем использовать не менее пяти расположений. Вы можете выбрать до 16 таких расположений. Пользовательские заголовки Пары "ключ — значение", определяющие рабочие параметры. Команда HTTP-запроса Укажите, какие действия необходимо предпринять с запросом. Текст запроса Пользовательские данные, связанные с HTTP-запросом. Вы можете отправить собственные файлы, ввести содержимое или отключить эту функцию.
Условия успеха
| Параметр | Description |
|---|---|
| Время ожидания тестирования | Уменьшите значение этого параметра, чтобы получать оповещения о медленных откликах. Тест считается неудачной попыткой, если ответы от сайта не были получены в течение заданного периода. Если выбрать параметр Анализировать зависимые запросы, все изображения, файлы стилей, скрипты и другие зависимые ресурсы будут получены в течение этого периода. |
| HTTP-ответ | Возвращаемый код состояния, который считается успешным результатом. Число 200 — это код, указывающий на то, что была возвращена обычная веб-страница. |
| Совпадение содержимого | Произвольная строка, например "Welcome!". Мы проверяем наличие точного совпадения (с учетом регистра) со строкой в каждом ответе. Это должна быть строка обычного текста без подстановочных знаков. Не забывайте, что при изменении содержимого страницы необходимо обновить эту строку. Поддерживаются только английские символы с совпадением содержимого. |
Оповещения о доступности
| Параметр | Description |
|---|---|
| Почти в режиме реального времени | Мы рекомендуем использовать оповещения практически в режиме реального времени. Настройка этого типа оповещений выполняется после создания теста доступности. |
| Пороговое значение для расположения оповещения | Мы рекомендуем как минимум 3 из 5 расположений. Оптимальное отношение между пороговым значением для оповещения расположения и числом тестовых расположений: пороговое значение для оповещения расположения = число расположений теста – 2, минимум с пятью расположениями теста. |
Обозначения местоположений
При развертывании теста проверки связи URL-адреса доступности можно использовать следующие теги популяции для атрибута географического расположения с помощью Azure Resource Manager.
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 минут. Можно также увеличить порог расположения оповещений, чтобы он активировал оповещение только в том случае, если веб-сайт отключен для определенного количества регионов. Для более длительных запланированных простоев временно отключите правило генерации оповещений или создайте пользовательское правило. Он предоставляет дополнительные возможности для учета простоя.
Изменение условий генерации оповещений
Чтобы внести изменения в пороговое значение расположения, период агрегирования и частоту тестирования, выберите условие на странице изменения правила генерации оповещений, чтобы открыть окно "Настройка логики сигнала".
Создание настраиваемого правила генерации оповещений
Если вам нужны дополнительные возможности, можно создать настраиваемое правило генерации оповещений на вкладке "Оповещения". Выберите "Создать>правило генерации оповещений". Выберите метрики для типа signal, чтобы отобразить все доступные сигналы и выбрать доступность.
Пользовательское правило генерации оповещений предлагает более высокие значения для периода агрегирования (вместо 24 часов вместо 6 часов) и частоту тестирования (до 1 часа вместо 15 минут). Также в нем добавлены параметры для дальнейшего определения логики путем выбора различных операторов, типов агрегирования и пороговых значений.
Оповещение о сбоях Y из расположений Y. Правило генерации оповещений Y по умолчанию включено в новом едином интерфейсе оповещений при создании нового теста доступности. Вы можете отказаться, выбрав параметр "классический" или выбрав отключить правило генерации оповещений. Настройте группы действий для получения уведомлений при активации оповещений, выполнив описанные выше действия. Без этого шага вы получите только уведомления на портале при активации правила.
Оповещения о метриках доступности: с помощью новых унифицированных оповещений можно также оповещать о сегментированной статистической доступности и метриках длительности тестирования:
Выберите ресурс Application Insights в интерфейсе метрик и выберите метрику доступности .
Параметр "Настройка оповещений" в меню позволяет выбрать определенные тесты или расположения, в которых можно настроить правила генерации оповещений. Здесь можно также настроить группы действий для этого правила.
Оповещение о пользовательских запросах аналитики: с помощью новых унифицированных оповещений можно генерации оповещений о пользовательских запросах журналов. С помощью настраиваемых запросов вы можете создать оповещение с любым произвольным условием, которое поможет вам получить самый надежный сигнал о проблемах с доступностью. Это также применимо, если вы отправляете пользовательские результаты доступности с помощью пакета SDK TrackAvailability.
Метрики данных доступности включают любые результаты пользовательской доступности, которые вы можете отправить, вызвав пакет SDK TrackAvailability. Поддержку оповещений о метриках можно использовать для оповещения о доступности результатов.
Автоматизация оповещений
Чтобы автоматизировать этот процесс с помощью шаблонов Azure Resource Manager, см . статью "Создание оповещений метрик" с помощью шаблона Azure Resource Manager.
Просмотр результатов теста доступности
В этом разделе объясняется, как проверить результаты теста доступности в портал Azure и запрашивать данные с помощью Log Analytics. Результаты теста доступности можно визуализировать с помощью представлений "Линии " и "Точечная диаграмма ".
Проверить доступность
Начните с просмотра графа на вкладке "Доступность " ресурса Application Insights.
В представлении "Точечная диаграмма " показаны примеры результатов теста с подробными сведениями о шаге диагностики. Обработчик тестов хранит сведения о диагностике тестов, которые завершились сбоем. Диагностические сведения об успешно выполненных тестах хранятся для подмножества выполнений. Наведите указатель мыши на любые красные или зеленые точки, чтобы просмотреть тест, его имя и расположение.
Выберите конкретный тест или расположение. Кроме того, можно уменьшить период времени, чтобы увидеть больше результатов в течение интересующего периода. Используйте обозреватель поиска, чтобы просмотреть результаты всех выполнений. Вы также можете использовать запросы Log Analytics для запуска пользовательских отчетов по этим данным.
Чтобы просмотреть подробные сведения о транзакциях, в разделе "Детализация" выберите "Успешно" или "Сбой". Затем выберите пример. Можно также перейти к подробным сведениям о сквозной транзакции, выбрав на диаграмме точку данных.
Проверка и изменение тестов
Чтобы изменить, временно отключить или удалить тест, выберите знак многоточия рядом с именем теста. После внесения изменений в конфигурацию может потребоваться до 20 минут.
При обслуживании службы может потребоваться отключить тесты доступности или связанные с ними правила генерации оповещений.
При возникновении сбоев
Выберите красную точку.
С помощью результатов тестов доступности вы увидите сведения о транзакциях для всех компонентов. Здесь можно:
- Просмотрите отчет об устранении неполадок, чтобы определить, что может привести к сбою теста, но приложение по-прежнему доступно.
- изучить ответ, полученный от сервера;
- диагностировать сбой на основе коррелированной телеметрии на стороне сервера, собранной во время обработки теста доступности, завершившегося сбоем;
- добавить в журнал проблему или рабочий элемент в Git или Azure Boards для отслеживания проблемы; ошибка будет содержать ссылку на это событие;
- открыть результат веб-теста в Visual Studio.
Дополнительные сведения о сквозной диагностика транзакций см. в документации по транзакциям диагностика.
Выберите строку исключения, чтобы просмотреть сведения об исключении на стороне сервера, вызвавшего сбой синтетического теста доступности. Вы также можете получить моментальный снимок отладки для более широкой диагностики на уровне кода.
Помимо необработанных результатов, можно также просмотреть две ключевые метрики доступности в обозревателе метрик:
- Доступность. Количество успешно выполненных тестов (в процентах).
- Продолжительность тестов. Средняя длительность всех тестов.
Запрос в Log Analytics
Вы можете использовать Log Analytics для просмотра результатов доступности, зависимостей и т. д. Дополнительные сведения о Log Analytics см. в обзоре запросов журнала.
Перенос тестов доступности
В этой статье мы рассмотрим процесс миграции с классических тестов связи ПО URL-адреса на современные и эффективные стандартные тесты.
Мы упрощаем этот процесс, предоставляя четкие пошаговые инструкции, чтобы обеспечить простой переход и предоставить приложениям самые актуальные возможности мониторинга.
Перенос классических тестов проверки 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, которые используются в тестах проверки ping URL-адресов.
$resourceGroup = "pingTestResourceGroup"; $appInsightsComponent = "componentName"; $pingTestName = "pingTestName"; $newStandardTestName = "newStandardTestName"; $componentId = (Get-AzApplicationInsights -ResourceGroupName $resourceGroup -Name $appInsightsComponent).Id; $pingTest = Get-AzApplicationInsightsWebTest -ResourceGroupName $resourceGroup -Name $pingTestName; $pingTestRequest = ([xml]$pingTest.ConfigurationWebTest).WebTest.Items.Request; $pingTestValidationRule = ([xml]$pingTest.ConfigurationWebTest).WebTest.ValidationRules.ValidationRule; $dynamicParameters = @{}; if ($pingTestRequest.IgnoreHttpStatusCode -eq [bool]::FalseString) { $dynamicParameters["RuleExpectedHttpStatusCode"] = [convert]::ToInt32($pingTestRequest.ExpectedHttpStatusCode, 10); } if ($pingTestValidationRule -and $pingTestValidationRule.DisplayName -eq "Find Text" ` -and $pingTestValidationRule.RuleParameters.RuleParameter[0].Name -eq "FindText" ` -and $pingTestValidationRule.RuleParameters.RuleParameter[0].Value) { $dynamicParameters["ContentMatch"] = $pingTestValidationRule.RuleParameters.RuleParameter[0].Value; $dynamicParameters["ContentPassIfTextFound"] = $true; } New-AzApplicationInsightsWebTest @dynamicParameters -ResourceGroupName $resourceGroup -Name $newStandardTestName ` -Location $pingTest.Location -Kind 'standard' -Tag @{ "hidden-link:$componentId" = "Resource" } -TestName $newStandardTestName ` -RequestUrl $pingTestRequest.Url -RequestHttpVerb "GET" -GeoLocation $pingTest.PropertiesLocations -Frequency $pingTest.Frequency ` -Timeout $pingTest.Timeout -RetryEnabled:$pingTest.RetryEnabled -Enabled:$pingTest.Enabled ` -RequestParseDependent:($pingTestRequest.ParseDependentRequests -eq [bool]::TrueString);По умолчанию новый стандартный тест не содержит правил генерации оповещений, поэтому он не создает шумные оповещения. Изменения в тесте проверки ping URL-адреса не вносятся, чтобы вы могли продолжать полагаться на них для оповещений.
После проверки функциональности нового стандартного теста обновите правила генерации оповещений, ссылающиеся на тест ping URL-адреса, чтобы вместо этого ссылаться на стандартный тест. Затем вы отключите или удалите тест проверки ping URL-адреса.
Чтобы удалить тест связи URL-адресов с помощью Azure PowerShell, можно использовать следующую команду:
Remove-AzApplicationInsightsWebTest -ResourceGroupName $resourceGroup -Name $pingTestName;
Тестирование за брандмауэром
Чтобы обеспечить доступность конечных точек за брандмауэрами, включите открытые тесты доступности или запустите тесты доступности в отключенном режиме или нет сценариев входящего трафика.
Включение теста общедоступной доступности
Убедитесь, что внутренний веб-сайт содержит запись общедоступной системы доменных имен (DNS). Тесты доступности завершаются ошибкой, если не удается разрешить DNS. Дополнительные сведения см. в статье "Создание личного доменного имени для внутреннего приложения".
Предупреждение
IP-адреса, используемые службой тестов доступности, являются общими и могут предоставлять конечные точки службы, защищенные брандмауэром, другим тестам. Фильтрация IP-адресов не защищает трафик вашей службы, поэтому рекомендуется добавить дополнительные пользовательские заголовки для проверки происхождения веб-запроса. Дополнительные сведения см. в разделе тегов службы виртуальной сети.
Проверка подлинности трафика
Задайте пользовательские заголовки в стандартных тестах доступности для проверки трафика.
Создайте маркер или GUID для идентификации трафика из тестов доступности.
Добавьте пользовательский заголовок X-Customer-InstanceId со значением
ApplicationInsightsAvailability:<GUID generated in step 1>в разделе "Стандартные сведения о тестировании" при создании или обновлении тестов доступности.Убедитесь, что входящий трафик включает заголовок и значение, определенное на предыдущих шагах.
Кроме того, задайте маркер в качестве параметра запроса. Например, https://yourtestendpoint/?x-customer-instanceid=applicationinsightsavailability:<your guid>.
Настройка брандмауэра для разрешения входящих запросов из тестов доступности
Примечание.
Этот пример предназначен для использования тега службы группы безопасности сети. Многие службы 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
Предупреждение
31 октября 2024 г. в соответствии с устаревшей версией ПРОТОКОЛА TLS Azure, версиями протокола TLS 1.0/1.1 и приведенными ниже перечисленными ниже наборами шифров TLS 1.2/1.3 и эллиптических кривых будут сняты для тестов доступности Application Insights.
TLS 1.0 и TLS 1.1
Версии протокола больше не будут поддерживаться.
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 на веб-сервере, лучше обратиться к команде, которая владеет платформой размещения, на которой работает веб-сервер, если процесс неизвестен.
После 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".
Следующие шаги
Обратная связь
Ожидается в ближайшее время: в течение 2024 года мы постепенно откажемся от GitHub Issues как механизма обратной связи для контента и заменим его новой системой обратной связи. Дополнительные сведения см. в разделе https://aka.ms/ContentUserFeedback.
Отправить и просмотреть отзыв по