Application Insights 可用性测试

项目
12/10/2024

通过 Application Insights，可以设置定期 Web 测试，从世界各地的不同点监视网站或应用程序的可用性和响应能力。这些可用性测试会定期向你的应用程序发送 Web 请求，并在应用程序没有响应或响应时间太慢时提醒你。

可用性测试不需要对你正在测试的网站或应用程序进行任何修改。它们适用于可从公共 Internet 访问的任何 HTTP 或 HTTPS 终结点，包括服务依赖的 REST API。这意味着你不仅可以监视自己的应用程序，还可以监视对应用程序功能至关重要的外部服务。对于每个 Application Insights 资源，最多可以创建 100 个可用性测试。

注意

可用性测试在存储时是根据 Azure 静态数据加密策略进行加密的。

可用性测试类型

有四种类型的可用性测试：

标准测试：一种可用性测试，通过发送单个请求来检查网站的可用性，类似于已弃用的 URL ping 测试。除了验证终结点是否正在响应并测量性能外，标准测试还包括 TLS/SSL 证书有效性、主动生存期检查、HTTP 请求谓词（例如 GET、HEAD 和 POST 等）、自定义标头以及与 HTTP 请求关联的自定义数据。

了解如何创建标准测试。
自定义 TrackAvailability 测试：如果你决定创建自定义应用程序以运行可用性测试，可以使用 TrackAvailability() 方法将结果发送到 Application Insights。

了解如何创建自定义 TrackAvailability 测试。
（已弃用）URL ping 测试：可通过 Azure 门户创建此测试，以验证终结点是否正在响应，并度量与该响应关联的性能。还可以设置自定义成功标准，以及更多高级功能，例如分析从属请求、允许重试。

重要

URL ping 测试：Application Insights 中的 URL ping 测试将于 2026 年 9 月 30 日停用。现有的 URL ping 测试将从你的资源中删除。查看标准测试的定价并在 2026 年 9 月 30 日之前转换为使用它们，以确保你可以继续在 Application Insights 资源中运行单步可用性测试。

先决条件

基于工作区的 Application Insights 资源

开始使用

前往 Application Insights 资源，并打开可用性体验。
从顶部导航栏中选择添加标准测试。

输入下表所述的测试名称、URL 和其他设置，然后选择创建。

部分	设置	说明
基本信息
	URL	URL 可以是要测试的任何网页，但必须在公共 Internet 中可见。该 URL 可以包括查询字符串。因此，例如，可以稍微训练一下数据库。如果 URL 解析为重定向，最多可以跟踪 10 个重定向。
	分析从属请求	测试会请求图像、脚本、样式文件以及其他属于受测网页的文件。记录的响应时间包括获取这些文件所耗费的时间。如果无法在超时期限内为整个测试成功下载所有这些资源，测试会失败。如果不选中此选项，则测试只请求指定 URL 的文件。启用此选项会导致更严格的检查。对于手动浏览站点时可能不明显的情况，测试可能会失败。我们最多只能解析 15 个依赖请求。
	针对可用性测试失败启用重试	测试失败时，会在短时间后重试。仅当连续三次尝试失败时，才报告失败。然后，将按照一般的测试频率执行后续测试。重试会暂停，直到下次成功为止。可在每个测试位置单独应用此规则。建议使用此选项。平均大约有 80% 的失败可在重试后消除。
	启用 SSL 证书有效性	你可以在自己的网站上验证 SSL 证书，以确保它已正确安装、有效、受信任，并且不会向任何用户提供任何错误。 SSL 证书验证将仅在最终重定向 URL 上执行。
	主动生存期检查	你可借此设置在 SSL 证书过期之前定义设置的时间段。过期后，测试将失败。
	测试频率	设置从每个测试位置运行测试的频率。如果有五个测试位置，且默认频率为五分钟，则平均每隔一分钟测试站点一次。
	测试位置	服务器从这些位置将 Web 请求发送到你的 URL。建议最低测试位置数目为 5，以确保可以区分网站中的问题与网络问题。最多可以选择 16 个位置。
标准测试信息
	HTTP 请求谓词	指示你想要对请求执行的操作。
	请求正文	与 HTTP 请求关联的自定义数据。你可以上传自己的文件、输入内容或禁用此功能。
	添加自定义标头	定义操作参数的键值对。
成功标准
	测试超时	减少此值可以接收有关响应变慢的警报。如果未在这段时间内收到站点的响应，则将测试视为失败。如果选择了分析依赖请求，则必须在这段时间内收到所有图像、样式文件、脚本和其他依赖资源。
	HTTP 响应	视为成功的返回状态代码。数字 200 这一代码指示返回了正常网页。
	内容匹配	类似于“Welcome!”的字符串。我们会测试每个响应中是否出现精确匹配项（区分大小写）。它必须是不带通配符的纯字符串。别忘了，如果页面内容更改，可能需要更新。内容匹配仅支持英文字符。

重要

TrackAvailability () 需要开发人员在编写和维护可能较复杂的自定义代码方面投入精力。

应尽可能使用标准测试，因为标准测试要求的投资很少、无需进行维护，而且需要的先决条件也不多。

此示例仅用于向你展示 TrackAvailability() API 调用在 Azure Functions 应用中的工作原理。其中并未介绍如何编写将此示例转换为功能齐全的可用性测试所需的基础 HTTP 测试代码或业务逻辑。

先决条件

基于工作区的 Application Insights 资源
访问 Azure Functions 应用的源代码
为 TrackAvailability() 编写定制代码的开发人员专业知识，可根据你的特定业务需求进行定制

开始使用

注意

若要按照这些说明操作，必须使用应用程序服务计划或 Functions 高级计划，以允许在应用服务编辑器中编辑代码。

如果要在虚拟网络后面进行测试或测试非公共终结点，则需要使用 Functions 高级计划。

创建计时器触发器函数

创建 Azure Functions 资源时，请考虑以下因素：
- 如果计时器触发函数还没有 Application Insights 资源，则默认情况下会在创建 Azure Functions 应用时创建该资源。
- 如果已有 Application Insights 资源，请在创建 Azure Functions 应用时转到监视选项卡，然后在 Application Insights 下拉列表中选择或输入现有资源的名称：
按照说明创建计时器触发的函数。

在应用服务编辑器中添加和编辑代码

转到已部署的 Azure Functions 应用，然后在开发工具下选择应用服务编辑器选项卡。

若要创建新文件，请在计时器触发器函数（例如“TimerTrigger1”）下右键单击，并选择“新建文件”。然后输入文件的名称，并选择 Enter。

创建名为“function.proj”的新文件，然后将以下代码粘贴到其中：

<Project Sdk="Microsoft.NET.Sdk"> 
    <PropertyGroup> 
        <TargetFramework>netstandard2.0</TargetFramework> 
    </PropertyGroup> 
    <ItemGroup> 
        <PackageReference Include="Microsoft.ApplicationInsights" Version="2.15.0" /> <!-- Ensure you’re using the latest version --> 
    </ItemGroup> 
</Project>

创建名为“runAvailabilityTest.csx”的新文件，然后将以下代码粘贴到其中：

using System.Net.Http; 

public async static Task RunAvailabilityTestAsync(ILogger log) 
{ 
    using (var httpClient = new HttpClient()) 
    { 
        // TODO: Replace with your business logic 
        await httpClient.GetStringAsync("https://www.bing.com/"); 
    } 
}

用以下代码替换 run.csx 中的现有代码：

#load "runAvailabilityTest.csx" 

using System; 

using System.Diagnostics; 

using Microsoft.ApplicationInsights; 

using Microsoft.ApplicationInsights.Channel; 

using Microsoft.ApplicationInsights.DataContracts; 

using Microsoft.ApplicationInsights.Extensibility; 

private static TelemetryClient telemetryClient; 

// ============================================================= 

// ****************** DO NOT MODIFY THIS FILE ****************** 

// Business logic must be implemented in RunAvailabilityTestAsync function in runAvailabilityTest.csx 

// If this file does not exist, add it first 

// ============================================================= 

public async static Task Run(TimerInfo myTimer, ILogger log, ExecutionContext executionContext) 

{ 
    if (telemetryClient == null) 
    { 
        // Initializing a telemetry configuration for Application Insights based on connection string 

        var telemetryConfiguration = new TelemetryConfiguration(); 
        telemetryConfiguration.ConnectionString = Environment.GetEnvironmentVariable("APPLICATIONINSIGHTS_CONNECTION_STRING"); 
        telemetryConfiguration.TelemetryChannel = new InMemoryChannel(); 
        telemetryClient = new TelemetryClient(telemetryConfiguration); 
    } 

    string testName = executionContext.FunctionName; 
    string location = Environment.GetEnvironmentVariable("REGION_NAME"); 
    var availability = new AvailabilityTelemetry 
    { 
        Name = testName, 

        RunLocation = location, 

        Success = false, 
    }; 

    availability.Context.Operation.ParentId = Activity.Current.SpanId.ToString(); 
    availability.Context.Operation.Id = Activity.Current.RootId; 
    var stopwatch = new Stopwatch(); 
    stopwatch.Start(); 

    try 
    { 
        using (var activity = new Activity("AvailabilityContext")) 
        { 
            activity.Start(); 
            availability.Id = Activity.Current.SpanId.ToString(); 
            // Run business logic 
            await RunAvailabilityTestAsync(log); 
        } 
        availability.Success = true; 
    } 

    catch (Exception ex) 
    { 
        availability.Message = ex.Message; 
        throw; 
    } 

    finally 
    { 
        stopwatch.Stop(); 
        availability.Duration = stopwatch.Elapsed; 
        availability.Timestamp = DateTimeOffset.UtcNow; 
        telemetryClient.TrackAvailability(availability); 
        telemetryClient.Flush(); 
    } 
}

注意

使用 TrackAvailability() 创建的测试显示时会在测试名称旁边带有“CUSTOM”字样。

屏幕截图显示了列出的两个不同测试的可用性体验。

可用性警报

默认情况下，警报是自动启用的，但为了完全配置警报，必须先创建可用性测试。

设置	说明
准实时	建议使用准实时警报。在创建可用性测试后会配置此类警报。
警报位置阈值	建议最少 3/5 个位置。警报位置阈值和测试位置数目之间的最佳关系是警报位置阈值 = 测试位置数 - 2，至少有 5 个测试位置。

位置填充标记

使用 Azure 资源管理器部署标准测试或可用性 URL ping 测试时，可将以下填充标记用于地理位置属性。

由世纪互联运营的 Microsoft Azure

显示名称	填充名称
中国东部	mc-cne-azr
中国东部 2	mc-cne2-azr
中国北部	mc-cnn-azr
中国北部 2	mc-cnn2-azr

启用警报

注意

使用新的统一警报时，必须在警报体验中配置预警规则严重性和操作组的通知首选项。如果不执行以下步骤，则只会收到门户内通知。

保存可用性测试后，打开所做测试的上下文菜单，然后选择打开规则（警报）页。
在警报规则页上，打开警报，然后选择顶部导航栏中的编辑。在这里，可以设置严重性级别、规则说明，以及具有要用于此警报规则的通知首选项的操作组。

警报条件

自动启用的可用性警报在终结点不可用时触发一封电子邮件，在终结点再次可用时触发另一封电子邮件。通过这种体验创建的可用性警报是基于状态的。当满足警报条件时，如果网站被检测为不可用，会生成一条警报。如果在下一次评估警报条件时网站仍处于故障状态，则不会产生新警报。

例如，假设你的网站关闭了一小时，并且你设置了评估频率为 15 分钟的电子邮件警报。仅当网站关闭时，你会收到一封电子邮件，然后在网站重新上线时收到另一封电子邮件。你不会每 15 分钟收到连续警报，提醒你网站仍然不可用。

更改警报条件

你可能不希望在网站仅关闭一小段时间（例如在维护期间）时收到通知。可以将评估频率更改为高于预期停机时间的值，最长为 15 分钟。还可以提高警报位置阈值，这样只有当网站在特定数量的区域关闭时才会触发警报。

提示

对于较长的计划停机时间，请暂时停用警报规则或创建自定义规则。这会给到你更多的选项来考虑故障问题。

若要更改位置阈值、聚合周期和测试频率，请转到编辑警报规则页面（请参阅启用警报下的步骤 2），然后选择打开配置信号逻辑窗口的条件。

创建自定义警报规则

如果需要高级功能，可以从“警报”选项卡创建自定义警报规则。选择“创建”>“警报规则”。 “信号类型”选择“指标”以显示所有可用信号，然后选择“可用性”。

自定义警报规则提供更高的聚合周期值（最长 24 小时而不是 6 小时），更高的测试频率值（最长 1 小时而不是 15 分钟）。它还增加了通过选择不同的运算符、聚合类型和阈值来进一步定义逻辑的选项。

当 Y 个位置中有 X 个报告失败时发出警报：创建新的可用性测试时，会在新的统一警报体验中默认启用“Y 个位置中的 X 个”警报规则。可通过选择“经典”选项或选择禁用该警报规则来选择退出。通过执行上述步骤，将操作组配置为在警报触发时接收通知。如果不执行此步骤，则在规则触发时只会收到门户内通知。
根据可用性指标发出警报：使用新的统一警报时，也可以根据分段聚合可用性以及测试持续时间指标发出警报：
1. 在指标体验中选择 Application Insights 资源，然后选择可用性指标。
2. 菜单中的配置警报选项会带你转到新体验，可在其中选择特定测试或位置，并根据它们设置警报规则。还可以在此处配置此警报规则的操作组。
根据自定义分析查询发出警报：使用新的统一警报时，可以根据自定义日志查询发出警报。借助自定义查询，可以在有助于获得最可靠的可用性问题信号的任意条件下发出警报。如果使用 TrackAvailability SDK 发送自定义可用性结果，它同样适用。

可用性数据的指标包括可能通过调用 TrackAvailability SDK 提交的任何自定义可用性结果。可以使用“根据指标发出警报”支持根据自定义可用性结果发出警报。

自动发送警报

若要使用 Azure 资源管理器模板自动执行此过程，请参阅使用 Azure 资源管理器模板创建指标警报。

查看可用性测试结果

此部分介绍如何在 Azure 门户中查看可用性测试结果并使用 Log Analytics 查询数据。可用性测试结果可以使用折线图和散点图的视图进行可视化。

检查可用性

首先查看 Azure 门户中可用性体验中的图形。

默认情况下，可用性体验显示折线图。将视图更改为散点图（在图表上方切换），以查看包含诊断测试步骤详细信息的测试结果样本。测试引擎存储已失败的测试的诊断详细信息。对于成功的测试，将存储执行子集的诊断详细信息。若要查看测试、测试名称和位置，可将鼠标悬停在任何绿点或红点上。

选择特定测试或位置。或者可以缩短时间段，以查看围绕感兴趣的时间段的更多结果。使用搜索资源管理器查看所有执行的结果。或者，可以使用 Log Analytics 查询对此数据运行自定义报表。

若要查看端到端事务详细信息，请在“深入钻取”下选择“成功”或“失败”。然后选择示例。还可以通过选择图上的数据点来访问端到端事务详细信息。

屏幕截图显示如何选择示例可用性测试。

检查和编辑测试

若要编辑、暂时禁用或删除测试，请打开测试旁边的上下文菜单（省略号），然后选择编辑。进行更改后，将配置更改传播到所有测试代理最多可能需要 20 分钟。

提示

对服务执行维护时，可能需要禁用可用性测试或与这些测试关联的警报规则。

如果看到失败

通过在散点图上选择一个红十字，打开端到端事务详细信息视图。

在此门户中，可以：

查看故障排除报告，确定可能导致测试失败的原因。
检查从服务器收到的响应。
使用在处理失败的可用性测试时收集的相关服务器端遥测数据进行故障诊断。
在 Git 或 Azure Boards 中记录问题或工作项，以跟踪问题。该错误包含指向 Azure 门户中事件的链接。
在 Visual Studio 中打开 Web 测试结果。

若要了解有关端到端事务诊断体验的详细信息，请参阅事务诊断文档。

选择异常行可查看导致综合可用性测试失败的服务器端异常的详细信息。还可获取调试快照，进行更丰富的代码级诊断。

除了原始结果外，还可以在指标资源管理器中查看两个关键的可用性指标：

可用性：已成功的测试占执行的所有测试的百分比。
测试持续时间：执行的所有测试的平均测试持续时间。

Log Analytics 中的查询

可以使用 Log Analytics 查看可用性结果 (availabilityResults)、依赖项 (dependencies) 等。若要详细了解 Log Analytics，请参阅日志查询概述。

将经典 URL ping 测试迁移到标准测试

以下步骤将引导你完成创建标准测试的过程，以复制 URL ping 测试的功能。它使你能够更轻松地通过以前创建的 URL ping 测试来开始使用标准测试的高级功能。

重要

运行标准测试相关的成本。创建标准测试后，将对你就测试执行收费。在开始此过程之前，请参阅 Azure Monitor 定价。

先决条件

Application Insights 中的任何 URL ping 测试
Azure PowerShell 访问

开始使用

使用 Azure PowerShell (Connect-AzAccount + Set-AzContext) 连接到订阅。

列出当前订阅中的所有 URL ping 测试：

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

找到要迁移的 URL Ping 测试并记录其资源组和名称。

使用以下命令创建与 URL ping 测试具有相同逻辑的标准测试，这些命令适用于 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);

新的标准测试默认没有警报规则，因此不会创建干扰警报。不会对 URL ping 测试进行更改，因此可以继续依赖它来获取警报。

验证新标准测试的功能，然后更新引用 URL ping 测试的警报规则，以改为引用标准测试。
禁用或删除 URL ping 测试。若要使用 Azure PowerShell 执行此操作，可以使用以下命令：
```
Remove-AzApplicationInsightsWebTest -ResourceGroupName $resourceGroup -Name $pingTestName;
```

在防火墙保护下进行测试

若要确保防火墙后的终结点可用性，请启用公共可用性测试或在断开连接或无入口的情况下运行可用性测试。

公共可用性测试启用

确保内部网站具有公共域名系统 (DNS) 记录。如果无法解析 DNS，可用性测试将失败。有关详细信息，请参阅为内部应用程序创建自定义域名。

警告

可用性测试服务使用的 IP 地址是共享的，可以向其他测试公开受防火墙保护的服务终结点。单纯的 IP 地址筛选无法保护服务的流量，因此建议添加额外的自定义标头来验证 Web 请求的来源。有关详细信息，请参阅虚拟网络服务标记。

对流量进行身份验证

在标准测试中设置自定义标头以验证流量。

创建不带空格的字母数字字符串来标识此可用性测试（例如，MyAppAvailabilityTest）。从这里开始，我们将此字符串称为可用性测试字符串标识符。
在创建或更新可用性测试时，在标准测试信息部分下添加具有值 ApplicationInsightsAvailability:<your availability test string identifier> 的自定义标头 X-Customer-InstanceId。
确保服务会检查传入流量是否包括前面步骤中定义的标头和值。

或者，将可用性测试字符串标识符设置为查询参数。

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

将防火墙配置为允许来自可用性测试的传入请求

注意

此示例特定于网络安全组服务标记的使用情况。许多 Azure 服务都接受服务标记，每个服务都需要不同的配置步骤。

若要简化启用 Azure 服务的操作，而不逐个授权 IP 或维护最新的 IP 列表，请使用服务标记。跨 Azure 防火墙和网络安全组应用这些标记，从而允许可用性测试服务访问终结点。服务标记 ApplicationInsightsAvailability 适用于所有可用性测试。

如果使用 Azure 网络安全组，请转到你的网络安全组资源，在设置下打开入站安全规则体验，然后选择添加。
接下来，选择服务标记作为源，选择 ApplicationInsightsAvailability 作为源服务标记。为来自服务标记的传入流量使用端口 80 (http) 和 443 (https)。

若要在终结点在 Azure 之外或无法使用服务标记方式时管理访问，请将我们 Web 测试代理的 IP 地址加入允许列表。你可以使用 PowerShell、Azure CLI 或基于服务标记 API 的 REST 调用来查询 IP 范围。有关当前服务标记的完整列表及其 IP 详细信息，请下载 JSON 文件。

在网络安全组资源的设置下，打开入站安全规则体验，然后选择添加。
接下来，选择 IP 地址作为源。然后在源 IP 地址/CIRD 范围的逗号分隔列表中添加你的 IP 地址。

断开连接或无引入方案

使用 Azure 专用链接将 Application Insights 资源连接到内部服务终结点。
编写自定义代码，以定期测试内部服务器或终结点。使用核心 SDK 包中的 TrackAvailability() API 将结果发送到 Application Insights。

支持的 TLS 配置

为了提供更好的加密功能，所有可用性测试均使用传输层安全性 (TLS) 1.2 和 1.3 作为选定的加密机制。此外，每个版本还支持以下密码套件和椭圆曲线。

版本	密码套件	椭圆曲线
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 配置

重要

2025 年 5 月 1 日，为了与 Azure 广泛的旧版 TLS 停用保持一致，将在 Application Insights 可用性测试中停用 TLS 1.0/1.1 协议版本和列出的 TLS 1.2/1.3 旧版密码套件及椭圆曲线。

TLS 1.0 和 TLS 1.1

TLS 1.0 和 TLS 1.1 即将停用。

TLS 1.2

版本	密码套件	椭圆曲线
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	• curve25519

故障排除

警告

我们最近在可用性测试中启用了 TLS 1.3。如果你因此看到新的错误消息，请确保在启用了 TLS 1.3 的 Windows Server 2022 上运行的客户端可以连接到你的终结点。如果无法执行此操作，可以考虑在终结点上暂时禁用 TLS 1.3，以便可用性测试回退到旧版 TLS。

有关更多信息，请查看故障排除文章。

停机时间和中断工作簿

本节介绍一种简单方法，该方法通过 Application Insights 资源和 Azure 订阅中的单一管理平台计算和报告 Web 测试的服务级别协议 (SLA)。 “故障时间和中断”报表提供了强大的预生成查询和数据可视化功能，使你能够更加深入地了解客户连接、典型应用程序响应时间以及经历的故障时间。

可以通过两种方式从 Application Insights 资源访问 SLA 工作簿模板：

打开可用性体验，然后从顶部导航栏中选择 SLA 报告。
打开工作簿体验，然后选择停机时间和中断模板。

参数灵活性

工作簿中设置的参数会影响报告的其余部分。

Subscriptions、App Insights Resources 和 Web Test：这些参数确定大致的资源选项。它们基于 Log Analytics 查询，用于每个报表查询。
Failure Threshold 和 Outage Window：可以使用这些参数来确定自己的服务中断标准。例如，Application Insights 可用性警报的标准，该警报基于选定时段内的失败位置计数器。典型阈值为五分钟时段内三个位置。
Maintenance Period：可以使用此参数来选择典型维护频率。 Maintenance Window 是示例维护时段的日期/时间选择器。结果将忽略在确定的时段内出现的所有数据。
Availability Target %：此参数指定你的终点目标，采用自定义值。

概述页

概述页面包含有关以下项的概要信息：

总 SLA（不包括维护期，如果已定义）
端到端中断实例
应用程序故障时间

根据你的中断参数，从测试开始失败的那一刻起确定中断实例，直到它再次成功通过为止。如果测试在上午 8:00 开始失败，在上午 10:00 成功，则这整个数据周期都会被视为同一中断。你还可以调查报告期出现的最长中断时间。

一些测试可以链接回其 Application Insights 资源以供进一步调查，但这仅适用于基于工作区的 Application Insights 资源。

停机时间、中断和失败

“概述页旁边还有两个选项卡：

“中断和停机时间”选项卡包含按测试细分的总停机实例和总停机时间的相关信息。
“按位置列出的失败”选项卡有一个包含失败测试位置的地图，有助于确定潜在的问题连接区域。

其他功能

自定义：可以像编辑任何其他 Azure Monitor 工作簿一样编辑报表，并根据团队的需求自定义查询或可视化效果。
Log Analytics：可以在 Log Analytics 中运行所有查询，并在其他报表或仪表板中使用这些查询。删除参数限制并重用核心查询。
访问和共享：可与你的团队和领导共享报表，也可以将其固定在仪表板上供进一步使用。用户需要对存储实际工作簿的 Application Insights 资源拥有读取权限和访问权限。

常见问题解答

本部分提供常见问题的解答。

常规

是否可以在 Intranet 服务器上运行可用性测试？

可用性测试可在遍布全球的各个接入点上运行。可运用以下两种解决方案：

防火墙门：允许从长且可更改的 Web 测试代理列表中请求自己的服务器。
自定义代码：编写自己的代码，以从 Intranet 内部向服务器发送定期请求。可以为此运行 Visual Studio Web 测试。测试人员可以使用 TrackAvailability() API 将结果发送到 Application Insights。

可用性测试的用户代理字符串是什么？

用户代理字符串为 Mozilla/5.0 Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0; AppInsights)

TLS 支持

此弃用对我的 Web 测试行为有何影响？

可用性测试在每个受支持的 Web 测试位置中充当分布式客户端。每次执行 Web 测试时，可用性测试服务都会尝试联系 Web 测试配置中定义的远程终结点。它会发送 TLS 客户端 Hello 消息，其中包含当前支持的所有 TLS 配置。如果远程终结点与可用性测试客户端共享通用 TLS 配置，则 TLS 握手成功。否则，Web 测试会失败，并显示 TLS 握手失败。

如何确保 Web 测试不受影响？

为了避免任何影响，与 Web 测试交互的每个远程终结点（包括从属请求）都需要支持至少一种与可用性测试相同的协议版本、密码套件和椭圆曲线组合。如果远程终结点不支持所需的 TLS 配置，则需要进行更新，以支持上述弃用后 TLS 配置的某些组合。可以通过查看 Web 测试的事务详细信息（最后是成功执行的 Web 测试）来发现这些终结点。

如何验证远程终结点支持的 TLS 配置？

有多种工具可用于测试终结点支持的 TLS 配置。一种方法是遵循本页面上详述的示例。如果远程终结点无法通过公共 Internet 访问，则需要确保从有权调用终结点的计算机验证远程终结点上支持的 TLS 配置。

注意

有关在 Web 服务器上启用所需 TLS 配置的步骤，最好联系拥有 Web 服务器所运行的托管平台的团队（如果进程未知）。

2025 年 5 月 1 日之后，针对受影响测试的 Web 测试行为将是什么？

所有受此弃用影响的 TLS 握手失败的异常类型不会自行出现。但是，Web 测试一开始失败的最常见异常是 The request was aborted: Couldn't create SSL/TLS secure channel。还应能够在“TLS 传输”故障排除步骤中看到任何与 TLS 相关的故障，以了解可能会受到影响的 Web 测试结果。

是否可以查看 Web 测试当前正在使用的 TLS 配置？

无法查看在 Web 测试执行期间协商的 TLS 配置。只要远程终结点支持带有可用性测试的常见 TLS 配置，则弃用后不会有任何影响。

弃用会影响可用性测试服务中的哪些组件？

本文档中详述的 TLS 弃用应仅影响 2025 年 5 月 1 日之后的可用性测试 Web 测试执行行为。有关与 CRUD 操作的可用性测试服务交互的详细信息，请参阅 Azure 资源管理器 TLS 支持。此资源提供有关 TLS 支持和弃用时间线的更多详细信息。

在哪里可以获得 TLS 支持？

有关旧版 TLS 问题的任何常规问题，请参阅解决 TLS 问题。

通过

Application Insights 可用性测试

可用性测试类型

创建可用性测试

先决条件

开始使用

可用性警报

位置填充标记

由世纪互联运营的 Microsoft Azure

启用警报

警报条件

更改警报条件

创建自定义警报规则

自动发送警报

查看可用性测试结果

检查可用性

检查和编辑测试

如果看到失败

Log Analytics 中的查询

将经典 URL ping 测试迁移到标准测试

先决条件

开始使用

在防火墙保护下进行测试

公共可用性测试启用

对流量进行身份验证

将防火墙配置为允许来自可用性测试的传入请求

断开连接或无引入方案

支持的 TLS 配置

弃用 TLS 配置

TLS 1.0 和 TLS 1.1

TLS 1.2

故障排除

停机时间和中断工作簿

参数灵活性

概述页

停机时间、中断和失败

其他功能

常见问题解答

常规

是否可以在 Intranet 服务器上运行可用性测试？

可用性测试的用户代理字符串是什么？

TLS 支持

此弃用对我的 Web 测试行为有何影响？

如何确保 Web 测试不受影响？

如何验证远程终结点支持的 TLS 配置？

2025 年 5 月 1 日之后，针对受影响测试的 Web 测试行为将是什么？

是否可以查看 Web 测试当前正在使用的 TLS 配置？

弃用会影响可用性测试服务中的哪些组件？

在哪里可以获得 TLS 支持？

后续步骤

其他资源