Application Insights 可用性測試

發行項
10/15/2024

Application Insights 可讓您設定週期性 Web 測試，以監視來自世界各地的網站或應用程式的可用性和回應性。這些可用性測試會定期將 Web 要求傳送至您的應用程式，並在您的應用程式沒有回應或回應時間太慢時發出警示。

可用性測試不需要對您要測試的網站或應用程式進行任何修改。它們適用於可從公用網際網路存取的任何 HTTP 或 HTTPS 端點，包括您服務相依的 REST API。這表示您不僅可以監視自己的應用程式，還可以監視對應用程式功能至關重要的外部服務。每個 Application Insights 資源最多可以建立 100 項可用性測試。

注意

會根據 Azure 待用資料加密原則將所儲存的可用性測試加密。

可用性測試類型

共有四種可用性測試：

標準測試：一種可用性測試類型，可藉由傳送單一要求以檢查網站的可用性，類似於取代 URL Ping 測試。除了驗證端點是否回應和測量效能之外，標準測試還包括 TLS/SSL 憑證有效性、主動式存留期檢查、HTTP 要求動詞 (例如、GET、HEAD 和 POST) 自訂標頭，以及與 HTTP 要求相關聯的自訂資料。

瞭解如何建立標準測試。
自訂 TrackAvailability 測試：如果決定建立自訂應用程式以執行可用性測試，您可以使用 TrackAvailability() 方法，將結果傳送至 Application Insights。

瞭解如何建立自定義 TrackAvailability 測試。
(已淘汰) 多步驟 Web 測試：您可以播放一連串 Web 要求的記錄，以測試更複雜的案例。多步驟 Web 測試會在 Visual Studio Enterprise 中建立，並上傳至入口網站，您可以在其中加以執行。
(已淘汰) URL Ping 測試：您可以透過 Azure 入口網站建立這個測試，以驗證端點是否回應並測量與該回應相關聯的效能。您也可以設定自訂成功準則與更進階功能，例如剖析相依要求和允許重試。

重要

有兩個可用性測試即將淘汰：

多步驟 Web 測試：2024 年 8 月 31 日，Application Insights 中的多步驟 Web 測試將會淘汰。我們建議這些測試的使用者在淘汰日期之前，轉換為替代可用性測試。在此日期之後，我們將關閉基礎結構，如此會中斷其餘的多步驟測試。
URL Ping 測試：在 2026 年 9 月 30 日，Application Insights 中的 URL Ping 測試將會淘汰。將會從您的資源中移除現有的 URL Ping 測試。檢閱標準測試和轉換的定價，以在 2026 年 9 月 30 日之前使用它們，以確保您可以繼續在 Application Insights 資源中執行單一步驟可用性測試。

必要條件

工作區型 Application Insights 資源

開始使用

移至 Application Insights 資源，並開啟 [可用性] 體驗。
從頂端導覽列選取 [新增標準測試]。

輸入測試名稱、URL 和下表所述的其他設定，然後選取 [建立]。

區段	設定	描述
基本資訊
	URL	URL 可以是您想要測試的任何網頁，但必須可從公用網際網路看見它。 URL 可以包含查詢字串。例如，您可以訓練一下您的資料庫。如果 URL 解析為重新導向，我們會跟隨它，最多 10 個重新導向。
	剖析相依要求	測試會要求提供影像、指令碼、樣式檔案，以及其他屬於受測試網頁的檔案。記錄的回應時間包含取得這些檔案所需的時間。如果無法在逾時內為整個測試成功下載任一資源，則測試將會失敗。如果未選取這個選項，測試只會要求您指定之 URL 中的檔案。啟用此選項會產生更嚴苛的檢查。手動瀏覽網站時，測試可能會在不明顯的情況下失敗。我們最多只會剖析 15 個從屬參照要求。
	可用性測試失敗時進行重試	當測試失敗時，系統就會在短時間內進行重試。只有在連續三次重試失敗後，才會回報失敗。後續測試則會以一般測試頻率執行。重試會暫時停止，直到下次成功為止。此規則可個別套用在每個測試位置。我們建議使用這個選項。平均來說，大約 80% 失敗會在重試後消失。
	啟用 SSL 憑證有效性	您可以確認網站上的 SSL 憑證，以確定其已正確安裝、有效、受信任，且不會向任何使用者提供任何錯誤。 SSL 憑證驗證只會在最終重新導向的 URL 上執行。
	主動式存留期檢查	這項設定可讓您定義 SSL 憑證到期之前的設定時間週期。到期後測試將會失敗。
	測試頻率	設定從每個測試位置執行測試的頻率。預設頻率為 5 分鐘且有五個測試位置，則您的網站平均每一分鐘會執行測試。
	測試位置	我們的伺服器將 Web 要求從這些位置傳送至 URL 的位置。建議的測試位置數目下限為五個，以確保您可以區分網站問題與網路問題。您最多可以選取 16 個位置。
標準測試資訊
	HTTP 要求動詞	指出您想要對要求採取的動作。
	要求本文	與 HTTP 要求相關聯的自訂資料。您可以上傳自己的檔案、輸入內容，或停用此功能。
	新增自訂標頭	定義作業參數的索引鍵值組。「主機」和「使用者代理程式」標頭會保留於可用性測試中，無法修改或覆寫。
成功準則
	測試逾時	降低此值可收到有關回應變慢的警示。如果未在這段時間內收到來自您網站的回應，則測試會視為失敗。如果已選取 [剖析相依要求]，則必須在這段時間內收到所有映像、樣式檔、指令碼和其他相依資源。
	HTTP 回應	視為成功的傳回狀態碼。編號 200 這個代碼表示已傳回標準 Web 網頁。
	內容比對	字串，例如「歡迎！」我們會測試每個回應中的區分大小寫完全相符。必須是單純字串，不含萬用字元。別忘了，如果頁面內容變更，則可能需要更新。內容相符僅支援英文字元。

重要

TrackAvailability() 需要開發人員投入精力撰寫及維護可能很複雜的自訂程式碼。

標準測試應一律使用，因為它們需要的投資不多、無需維護，而且幾乎沒有必要條件。

此範例僅設計來向您示範 TrackAvailability() API 呼叫在 Azure Functions 應用程式內的運作機制。其不會示範如何撰寫將此範例轉換為功能完整之可用性測試所需的底層 HTTP 測試程式碼或商務邏輯。

必要條件

工作區型 Application Insights 資源
存取 Azure Functions 應用程式的原始程式碼
能夠針對 TrackAvailability() 撰寫專為您特定業務需求量身打造之自訂程式碼的開發人員專業知識

開始使用

注意

若要遵循這些指示，您必須使用 App Service 方案或 Functions 進階方案，以允許在 App Service 編輯器中編輯程式碼。

如果您要在虛擬網路後進行測試，或測試非公用端點，則必須使用 Functions 進階方案。

建立計時器觸發程序函數

建立 Azure Functions 資源時考量下列事項：
- 如果您還沒有適用於計時器觸發函式的 Application Insights 資源，則預設會在您建立 Azure Functions 應用程式時建立。
- 如果您已經有 Application Insights 資源，請在建立 Azure Functions 應用程式時移至 [監視] 索引標籤，然後在 [Application Insights] 下拉式清單中選取或輸入現有資源的名稱：
請遵循指示來建立計時器觸發的函式。

在 App Service 編輯器中新增並編輯程式碼

移至已部署的 Azure Functions 應用程式，然後在 [開發工具] 下，選取 [App Service 編輯器] 索引標籤。

若要建立新檔案，請以滑鼠右鍵按一下您的計時器觸發程序函數 (例如 TimerTrigger1) 下方，然後選取 [新增檔案]。接著輸入檔案名稱，然後選取 [輸入]。

建立名為 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 (最少五個測試位置)。

位置母體標籤

當您使用 Azure Resource Manager 部署標準測試或 URL Ping 測試時，可以使用下列地理位置屬性的母體標籤。

提供者	Display name	母體名稱
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 Government
	USGov Virginia	usgov-va-azr
	US Gov 亞利桑那州	usgov-phx-azr
	USGov Texas	usgov-tx-azr
	US DoD 東部	usgov-ddeast-azr
	US DoD 中部	usgov-ddcentral-azr
由 21Vianet 營運的 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 個回報失敗所發出的警示：當您建立新的可用性測試，預設會在新的整合警示體驗中啟用 X/Y 個位置警示規則。您可以選取「傳統」選項來選擇退出，也可以選擇停用警示規則。依照前述步驟，設定警示觸發時收到通知的動作群組。若未進行此步驟，當規則觸發時，您只會收到入口網站內部通知。
可用性計量的警示：若使用新的整合警示，您也可以對分段彙總可用性和測試持續時間計量設定警示：
1. 在 [計量] 體驗中選取 Application Insights 資源，然後選取 [可用性] 計量：
2. 功能表的 [設定警示] 選項會帶您前往新的體驗，您可以在其中選取特定測試或位置來據以設定警示規則。您也可以在這裡設定此警示規則的動作群組。
自訂分析查詢的警示：若使用新的整合警示，您可以設定自訂記錄檔查詢的警示。使用自訂查詢，您可以設定任何任意條件的警示，協助您取得可用性問題的最可靠訊號。如果您要使用 TrackAvailability SDK 傳送自訂可用性結果，這也同樣適用。

可用性資料的計量包括您可能透過呼叫 TrackAvailability SDK 提交的任何自訂可用性結果。您可以使用計量支援的警示，設定自訂可用性結果的警示。

自動化警示

若要使用 Azure Resource Manager 範本將此流程自動化，請參閱使用 Azure Resource Manager 範本建立計量警示。

查看可用性測試結果

本章節說明如何在 Azure 入口網站中檢閱可用性測試結果，並使用 Log Analytics 查詢資料。可以透過線條和散佈圖檢視以視覺化可用性測試結果。

檢查可用性

從在 Azure 入口網站中檢閱 [可用性] 體驗中的圖表開始。

根據預設，[可用性] 體驗會顯示折線圖。將檢視變更為 [散佈圖] (在圖表上方切換)，以查看其中具有診斷測試步驟詳細資料的測試結果範例。測試引擎會儲存失敗測試的診斷詳細資料。對於成功的測試，系統會儲存執行子集的診斷詳細資料。若要查看測試、測試名稱和位置，請將滑鼠停留在任何綠色點或紅十字上方。

選取特定的測試或位置。或者，您可以縮短時間週期，以查看更多與感興趣時段相關的結果。使用搜尋總管，查看所有執行的結果。或者，您可以使用 Log Analytics 查詢，針對此資料執行自訂報告。

若要查看端對端交易詳細資料，請選取 [向下切入] 下的 [成功] 或 [失敗]。然後選取範例。您也可以選取圖形上的資料點，以取得端對端交易詳細資料。

顯示選取範例可用性測試的螢幕擷取畫面。

檢查和編輯測試

若要編輯、暫時停用或刪除測試，請依測試開啟操作功能表 (省略符號)，然後選取 [編輯]。設定變更可能需要 20 分鐘的時間，才能在變更之後傳播至所有的測試代理程式。

提示

建議在對服務執行維護時，停用可用性測試或與其相關聯的警示規則。

如果您看到失敗

選取 [散佈圖] 上的紅色十字，以開啟 [端對端交易詳細資料] 檢視。

您可以在其中：

檢閱疑難排解報告，以判斷造成測試失敗的原因。
檢查從伺服器收到的回應。
使用在處理失敗的可用性測試時收集的相關聯伺服器端遙測來診斷失敗。
在 Git 或 Azure Boards 中記錄問題或工作項目來追蹤問題。 Bug 包含 Azure 入口網站中事件的連結。
在 Visual Studio 中開啟 Web 測試結果。

若要深入了解端對端交易診斷體驗，請參閱交易診斷文件。

選取例外狀況資料列，以查看造成綜合可用性測試失敗之伺服器端例外狀況的詳細資料。您也可以取得偵錯快照集進行更多樣化的程式碼層級診斷。

除了原始結果，您也可以在計量瀏覽器中檢視兩個主要可用性計量︰

可用性︰所有測試執行中測試成功的百分比。
測試持續期間︰所有測試執行中的平均測試持續期間。

Log Analytics 中的查詢

您可以使用 Log Analytics 來檢視可用性結果 (availabilityResults)、相依性 (dependencies) 等等。若要深入了解 Log Analytics，請參閱記錄查詢概觀。

將傳統 URL ping 測試移轉至標準測試

下列步驟會逐步引導您完成流程，建立標準測試以復寫 URL ping 測試的功能。它可讓您使用先前建立 URL ping 測試更輕鬆地開始使用標準測試的進階功能。

重要

與執行 標準測試 相關聯的成本。建立標準測試之後，您將需支付測試執行的費用。在開始此流程之前，請參閱 Azure 監視器定價。

必要條件

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 位址篩選並不能保護服務的流量，因此建議新增額外的自訂標頭來驗證網頁請求的來源。如需詳細資訊，請參閱虛擬網路服務標籤。

驗證流量

在標準測試中設定自定義標頭，以驗證流量。

建立不含空格的英數字元字串，以識別此可用性測試 (例如 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 範圍。有關當前服務標籤及其 I P詳細資訊的完整清單，請下載 JSON 檔案。

在您的網路安全性群組資源中，於 [設定] 下開啟 [輸入安全性規則] 體驗，然後選取 [新增]。
接下來，選取 [IP 位址] 作為來源。然後在來源 IP 位址/CIRD 範圍中的逗號分隔清單中新增 IP 位址。

已中斷連線或沒有輸入案例

使用 Azure Private Link 將您的 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 設定

重要

2025 年 5 月 1 日，與 Azure 寬版 TLS 淘汰一致，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	• curve25519
TLS 1.3		• 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 監視器活頁簿一樣編輯報告，並根據小組的需求自訂查詢或視覺效果。
Log Analytics：查詢全都可以在 Log Analytics 中執行，並用於其他報告或儀表板。移除參數限制，並重複使用核心查詢。
存取和共用：報告可以與您的小組和領導階層共用，或釘選到儀表板以供進一步使用。使用者需要實際活頁簿儲存所在 Application Insights 資源的讀取權限和存取權。

常見問題集

本節提供常見問題的答案。

一般

我是否可以在內部網路伺服器上執行可用性測試？

可用性測試會在分散在世界各地的目前狀態點上執行。有兩個解決方案：

防火牆門 - 允許從這個又長又可變更的 Web 測試代理程式清單傳送要求給您的伺服器。
自訂程式碼：撰寫您自己的程式碼，以從內部網路內傳送定期要求給您的伺服器。您可以針對這個目的執行 Visual Studio Web 測試。測試者可以使用 TrackAvailability() API 將結果傳送給 Application Insights。

什麼是可用性測試的使用者代理程式字串？

使用者代理程式字串是 Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0; AppInsights)

TLS 支援

這項淘汰會對我的 Web 測試行為有何影響？

可用性測試會做為每個受支援 Web 測試位置中的分散式用戶端。每次執行 Web 測試時，可用性測試服務都會嘗試連絡 Web 測試設定中所定義的遠端端點。會傳送 TLS Client Hello 訊息，其中包含所有目前支援的 TLS 設定。如果遠端端點與可用性測試用戶端共用一般 TLS 設定，TLS 交握就會成功。否則，Web 測試會因為 TLS 交握失敗而失敗。

如何確保我的 Web 測試不會受到影響？

為了避免任何影響，您 Web 測試有所互動的每個遠端端點 (包括相依要求) 都必須支援至少一個可用性測試所支援的相同通訊協定版本、加密套件和橢圓曲線的組合。如果遠端端點不支援所需的 TLS 設定，則必須以支援上述淘汰後 TLS 設定的一些組合進行更新。您可以透過檢視 Web 測試的交易詳細資料來探索這些端點 (最好是成功執行 Web 測試)。

如何驗證遠端端點支援的 TLS 設定？

有數個工具可用來測試端點支援的 TLS 設定。其中一種方式是遵循此頁面上詳述的範例。如果您的遠端端點無法透過公用網際網路使用，您必須確定從可存取您端點的機器驗證遠端端點上支援的 TLS 設定來呼叫您的端點。

注意

如需在網頁伺服器上啟用所需 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 Resource Manager TLS 支援。這項資源提供 TLS 支援和淘汰時程表的詳細資料。

哪裡可以取得 TLS 支援？

若有舊版 TLS 問題的任何一般疑問，請參閱解決 TLS 問題。

共用方式為

Application Insights 可用性測試

可用性測試類型

建立可用性測試

必要條件

開始使用

可用性警示

位置母體標籤

啟用警示

警示準則

變更警示準則

建立自訂警示規則

自動化警示

查看可用性測試結果

檢查可用性

檢查和編輯測試

如果您看到失敗

Log Analytics 中的查詢

將傳統 URL ping 測試移轉至標準測試

必要條件

開始使用

在防火牆後方進行測試

啟用公用的可用性測試

驗證流量

設定您的防火牆以允許來可用性測試的後續要求

已中斷連線或沒有輸入案例

支援的 TLS 設定

即將淘汰 TLS 設定

TLS 1.0 和 TLS 1.1

TLS 1.2 和 TLS 1.3

疑難排解

停機與中斷活頁簿

參數彈性

概觀分頁

停機時間、中斷和失敗

其他功能

常見問題集

一般

我是否可以在內部網路伺服器上執行可用性測試？

什麼是可用性測試的使用者代理程式字串？

TLS 支援

這項淘汰會對我的 Web 測試行為有何影響？

如何確保我的 Web 測試不會受到影響？

如何驗證遠端端點支援的 TLS 設定？

2025 年 5 月 1 日之後，Web 測試行為會針對受影響的測試有何影響？

我是否可以檢視 Web 測試目前所使用的 TLS 設定？

淘汰會影響可用性測試服務中的哪些元件？

哪裡可以取得 TLS 支援？

下一步

意見反應

其他資源