你当前正在访问 Microsoft Azure Global Edition 技术文档网站。如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

Application Insights 可用性测试

项目
07/17/2024

部署 Web 应用或网站之后，可以设置重复测试来监视可用性和响应能力。 Application Insights 将来自全球各地的 Web 请求定期发送到应用程序。如果你的应用程序未响应或响应速度太慢，则会发出警报。对于每个 Application Insights 资源，最多可以创建 100 个可用性测试。

可用性测试不需要对所测试的网站进行任何更改，并且适用于可从公共 Internet 访问的任何 HTTP 或 HTTPS 终结点。你还可以测试服务所依赖的 REST API 的可用性。

注意

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

可用性测试类型

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

标准测试：这是一种可用性测试，它通过发送单个请求来检查网站的可用性，类似于已弃用的 URL ping 测试。除了验证终结点是否正在响应并测量性能外，标准测试还包括 TLS/SSL 证书有效性、主动生存期检查、HTTP 请求谓词（例如 GET、HEAD 和 POST 等）、自定义标头以及与 HTTP 请求关联的自定义数据。
自定义 TrackAvailability 测试：如果你决定创建自定义应用程序以运行可用性测试，可以使用 TrackAvailability() 方法将结果发送到 Application Insights。
（已弃用）多步骤 Web 测试：可以播放这一系列 Web 请求记录来测试更复杂的场景。多步骤 Web 测试在 Visual Studio Enterprise 中创建并上传到门户，你可以在其中运行这些测试。
（已弃用）URL ping 测试：可通过 Azure 门户创建此测试，以验证终结点是否正在响应，并度量与该响应关联的性能。还可以设置自定义成功标准，以及更多高级功能，例如分析从属请求、允许重试。

重要

即将停用两项可用性测试：

多步骤 Web 测试：Application Insights 中的多步骤 Web 测试将于 2024 年 8 月 31 日停用。建议这些测试的用户在停用日期之前过渡到备用可用性测试。在此日期之后，我们将关闭基础基础结构，这将中断剩余的多步骤测试。
URL ping 测试：Application Insights 中的 URL ping 测试将于 2026 年 9 月 30 日停用。现有的 URL ping 测试将从你的资源中删除。查看标准测试的定价并在 2026 年 9 月 30 日之前转换为使用它们，以确保你可以继续在 Application Insights 资源中运行单步可用性测试。

提示

如果当前正在使用其他可用性测试，如 URL ping 测试，则可以一并添加标准测试与其他测试。如果你希望使用标准测试而不是其他测试之一，请添加标准测试并删除旧测试。

先决条件

基于工作区的 Application Insights 资源

开始使用

前往 Application Insights 资源并选择“可用性”窗格。
选择“添加标准测试”。

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

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

成功条件

设置	说明
测试超时	减少此值可以接收有关响应变慢的警报。如果未在这段时间内收到站点的响应，则将测试视为失败。如果选择了“分析依赖请求”，则必须在这段时间内收到所有图像、样式文件、脚本和其他依赖资源。
HTTP 响应	视为成功的返回状态代码。数字 200 这一代码指示返回了正常网页。
内容匹配	类似于“Welcome!”的字符串。我们会测试每个响应中是否出现精确匹配项（区分大小写）。它必须是不带通配符的纯字符串。别忘了，如果页面内容更改，可能需要更新。内容匹配仅支持英文字符。

重要

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

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

先决条件

基于工作区的 Application Insights 资源
能够访问 Azure Functions 中的函数应用的源代码
能够为 TrackAvailability() 编写符合你的特定业务需求的自定义代码的开发人员专业知识

基本代码示例

注意

此示例只是为了向你展示 TrackAvailability() API 调用在 Azure 函数中的工作机制，而不是为了展示如何编写基础 HTTP 测试代码或业务逻辑，后者是将此示例转变为功能完全正常的可用性测试所需的。

默认情况下，如果逐步完成此示例，你将创建一个基本的可用性 HTTP GET 测试。若要按照这些说明操作，必须使用专用计划才能在应用服务编辑器中编辑代码。

创建计时器触发器函数

创建 Azure Functions 资源。
- 如果已有 Application Insights 资源：
  
  默认情况下，Azure Functions 创建 Application Insights 资源。如果要使用之前创建的资源，则必须在创建期间进行相应的指定。
  
  按照有关如何创建 Azure Functions 资源的说明进行以下修改：
  
  在“监视”选项卡上，选择“Application Insights”下拉框，然后输入或选择资源的名称：
- 如果尚未为计时器触发的函数创建 Application Insights 资源：
  
  默认情况下，在创建 Azure Functions 应用程序时，它将为你创建一个 Application Insights 资源。按照有关如何创建 Azure Functions 资源的说明进行操作。
注意

可以在消耗、高级或应用服务计划中托管函数。如果要在虚拟网络后面进行测试，或者要测试非公共终结点，则需使用高级计划来代替消耗计划。在“托管”选项卡上选择计划。确保在创建函数应用时选择最新的 .NET 版本。
创建计时器触发器函数。
1. 在函数应用中，选择“函数”选项卡。
2. 选择添加。在“添加函数”窗格中，选择以下配置：
  - 开发环境：在门户中进行开发
  - 选择模板：计时器触发器
3. 选择“添加”以创建计时器触发器函数。

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

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

若要创建新文件，请在计时器触发器函数（例如“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/"); 
    } 
}

将 REGION_NAME 环境变量定义为有效的 Azure 可用性位置。

在 Azure CLI 中运行以下命令，列出可用区域。
```
az account list-locations -o table
```

将以下代码复制到 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, please 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(); 
    } 
}

多步骤 Web 测试代码示例

请按照上述相同的说明操作，并将以下代码粘贴到 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/"); 

        // TODO: Replace with your business logic for an additional monitored endpoint, and logic for additional steps as needed
        await httpClient.GetStringAsync("https://www.learn.microsoft.com/"); 
    } 
}

可用性警报

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

位置填充标记

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

Azure

显示名称	填充名称
澳大利亚东部	emea-au-syd-edge
巴西南部	latam-br-gru-edge
Central US	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 Government

显示名称	填充名称
USGov Virginia	usgov-va-azr
US Gov 亚利桑那州	usgov-phx-azr
US Gov 德克萨斯州	usgov-tx-azr
USDoD 东部	usgov-ddeast-azr
USDoD 中部	usgov-ddcentral-azr

由世纪互联运营的 Microsoft Azure

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

启用警报

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

注意

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

保存可用性测试后，在详细信息选项卡上，选择你刚才做的测试旁边的省略号。选择打开规则（警报）页。
设置严重性级别、规则说明，以及具有要用于此警报规则的通知首选项的操作组。

警报条件

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

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

你可能不希望在网站仅关闭一小段时间（例如在维护期间）时收到通知。可以将评估频率更改为高于预期停机时间的值，最长为 15 分钟。还可以提高警报位置阈值，这样只有当网站在特定数量的区域关闭时才会触发警报。对于较长的计划停机时间，请暂时停用警报规则或创建自定义规则。这会给到你更多的选项来考虑故障问题。

更改警报条件

若要更改位置阈值、聚合周期和测试频率，请在警报规则的编辑页上选择条件，以打开“配置信号逻辑”窗口。

创建自定义警报规则

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

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

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

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

自动发送警报

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

查看可用性测试结果

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

检查可用性

首先查看 Application Insights 资源的“可用性”选项卡上的图。

标准测试
TrackAvailability

“可用性”页面的屏幕截图，其中突出显示了“刷新”按钮。

散点图t视图显示其中有诊断测试步骤详细信息的测试结果示例。测试引擎存储已失败的测试的诊断详细信息。对于成功的测试，将存储执行子集的诊断详细信息。将鼠标悬停在任何绿点/红点上，可查看测试、测试名称和位置。

显示折线图的屏幕截图。

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

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

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

检查和编辑测试

若要编辑、临时禁用或删除测试，请选择测试名称旁边的省略号。进行更改后，将配置更改传播到所有测试代理最多可能需要 20 分钟。

显示“查看测试详细信息”的屏幕截图。编辑和禁用 Web 测试。

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

如果看到失败

选择红点。

该屏幕截图显示“端到端事务详细信息”选项卡。

从可用性测试结果中，可以看到所有组件的事务详细信息。在此门户中，可以：

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

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

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

显示服务器端诊断的屏幕截图。

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

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

Log Analytics 中的查询

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

迁移可用性测试

在本文中，我们将指导你完成从经典 URL ping 测试迁移到新式高效标准测试的过程。

我们通过提供明确的分步说明来简化此过程，以确保无缝转换，并为应用程序提供最新的监视功能。

将经典 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 测试相同的逻辑创建标准测试。

注意

以下命令适用于 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 删除 URL ping 测试，可以使用以下命令：

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

在防火墙保护下进行测试

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

公共可用性测试启用

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

警告

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

对流量进行身份验证

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

生成令牌或 GUID 来标识来自可用性测试的流量。
在创建或更新可用性测试时，在“标准测试信息”部分下添加具有值 ApplicationInsightsAvailability:<GUID generated in step 1> 的自定义标头“X-Customer-InstanceId”。
确保服务会检查传入流量是否包括前面步骤中定义的标头和值。

或者，将令牌设置为查询参数。例如 https://yourtestendpoint/?x-customer-instanceid=applicationinsightsavailability:<your guid>。

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

注意

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

若要简化启用 Azure 服务的操作，而不逐个授权 IP 或维护最新的 IP 列表，请使用服务标记。跨 Azure 防火墙和网络安全组应用这些标记，从而允许可用性测试服务访问终结点。服务标记 ApplicationInsightsAvailability 适用于所有可用性测试。
1. 如果使用 Azure 网络安全组，请转到你的网络安全组资源，在“设置”下选择“入站安全规则”。然后选择“添加” 。
2. 接下来选择“服务标记”作为源，然后选择“ApplicationInsightsAvailability”作为源服务标记。为来自服务标记的传入流量使用端口 80 (http) 和 443 (https)。
若要在终结点在 Azure 之外或无法使用服务标记方式时管理访问，请将我们 Web 测试代理的 IP 地址加入允许列表。你可以使用 PowerShell、Azure CLI 或基于服务标记 API 的 REST 调用来查询 IP 范围。有关当前服务标记的完整列表及其 IP 详细信息，请下载 JSON 文件。
1. 在网络安全组资源中的“设置”下，选择“入站安全规则”。然后选择“添加” 。
2. 接下来，选择“IP 地址”作为源。然后在源 IP 地址/CIRD 范围的逗号分隔列表中添加你的 IP 地址。

断开连接或无引入方案

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

支持的 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 配置

警告

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

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

椭圆曲线：

curve25519

TLS 1.3

椭圆曲线

curve25519

故障排除

警告

我们最近在可用性测试中启用了 TLS 1.3。如果你因此看到新的错误消息，请确保在启用了 TLS 1.3 的 Windows Server 2022 上运行的客户端可以连接到终结点。如果无法执行此操作，可以考虑在终结点上暂时禁用 TLS 1.3，以便可用性测试回退到旧版 TLS。
有关详细信息，请参阅故障排除文章。请参阅专用疑难解答文章。

故障时间、SLA 和中断工作簿

本文介绍一种简单方法，该方法通过 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 测试可在遍布全球的各个接入点上运行。可运用以下两种解决方案：

防火墙门：允许从长且可更改的 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 服务器所运行的托管平台的团队（如果进程未知）。

2024 年 10 月 31 日之后，针对受影响测试的 Web 测试行为将是什么？

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

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

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

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

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

在哪里可以获得 TLS 支持？

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

通过

Application Insights 可用性测试

可用性测试类型

创建可用性测试

先决条件

开始使用

成功条件

可用性警报

位置填充标记

Azure

Azure Government

由世纪互联运营的 Microsoft Azure

启用警报

警报条件

更改警报条件

创建自定义警报规则

自动发送警报

查看可用性测试结果

检查可用性

检查和编辑测试

如果看到失败

Log Analytics 中的查询

迁移可用性测试

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

先决条件

开始使用

在防火墙保护下进行测试

公共可用性测试启用

对流量进行身份验证

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

断开连接或无引入方案

支持的 TLS 配置

TLS 1.2

TLS 1.3

弃用 TLS 配置

TLS 1.0 和 TLS 1.1

TLS 1.2

TLS 1.3

故障排除

故障时间、SLA 和中断工作簿

参数灵活性

概述页

停机时间、中断和失败

编辑报表

Log Analytics

访问和共享

常见问题解答

常规

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

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

TLS 支持

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

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

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

2024 年 10 月 31 日之后，针对受影响测试的 Web 测试行为将是什么？

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

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

在哪里可以获得 TLS 支持？

后续步骤

反馈

反馈

其他资源