Application Insights 可用性測試

發行項
07/23/2024

部署 Web 應用程式或網站之後，您可以設定週期性測試來監視可用性和回應性。 Application Insights 會將來自全球各地的 Web 要求定期傳送給應用程式。如果您的應用程式沒有回應，或者回應速度太慢，其可以對您發出警示。每個 Application Insights 資源最多可以建立 100 項可用性測試。

可用性測試不需要對您要測試的網站進行任何變更，並適用於可從公用網際網路存取的任何 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 測試：2024 年 8 月 31 日，Application Insights 中的多步驟 Web 測試將會淘汰。我們建議這些測試的使用者在淘汰日期之前，轉換為替代可用性測試。在此日期之後，我們將關閉基礎結構，如此會中斷其餘的多步驟測試。
URL Ping 測試：在 2026 年 9 月 30 日，Application Insights 中的 URL Ping 測試將會淘汰。將會從您的資源中移除現有的 URL Ping 測試。檢閱標準測試和轉換的定價，以在 2026 年 9 月 30 日之前使用它們，以確保您可以繼續在 Application Insights 資源中執行單一步驟可用性測試。

提示

如果您目前使用其他可用性測試，例如 URL Ping 測試，則可以在其他測試的同時新增標準測試。如果您想要使用標準測試，而不是其他測試之一，請新增標準測試並刪除舊測試。

必要條件

工作區型 Application Insights 資源

開始使用

前往 Application Insights 資源，並選取 [可用性] 窗格。
選取 [新增標準測試]。

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

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

成功準則

設定	描述
測試逾時	降低此值可收到有關回應變慢的警示。如果未在這段時間內收到您網站的回應，則測試會視為失敗。如果已選取 [剖析相依要求] ，則必須在這段時間內收到所有映像、樣式檔、指令碼和其他相依資源。
HTTP 回應	視為成功的傳回狀態碼。號碼 200 這個代碼表示已傳回標準 Web 網頁。
內容比對	字串，例如「歡迎！」我們會測試每個回應中的區分大小寫完全相符。必須是單純字串，不含萬用字元。別忘了，如果頁面內容變更，則可能需要更新。內容相符僅支援英文字元。

重要

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

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

必要條件

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

基本程式碼範例

注意

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

根據預設，如果您逐步執行此範例，則將建立基本的可用性 HTTP GET 測試。若要遵循這些指示，您必須使用專用方案，以允許在 App Service 編輯器中編輯程式碼。

建立計時器觸發程序函數

建立 Azure Functions 資源。
- 如果您已有 Application Insights 資源：
  
  根據預設，Azure Functions 會建立 Application Insights 資源。如果您想要使用先前建立的資源，就必須在建立期間指定該資源。
  
  請遵循有關如何使用下列修改來建立 Azure Functions 資源的指示：
  
  在 [監視] 索引標籤上，選取 [Application Insights] 下拉式方塊，然後輸入或選取資源的名稱：
- 如果您尚未針對計時器觸發的函數建立 Application Insights 資源：
  
  根據預設，當您建立 Azure Functions 應用程式時，它會為您建立 Application Insights 資源。請遵循有關如何建立 Azure Functions 資源的指示。
注意

您可以在取用、進階或 App Service 方案上裝載函式。如果您要在虛擬網路後方進行測試或測試非公用端點，則必須使用進階方案來取代使用情況方案。在 [裝載] 索引標籤上選取您的方案。當您建立函數應用程式時，請確定已選取最新的 .NET 版本。
建立計時器觸發程序函數。
1. 在函數應用程式中，選取 [函數] 索引標籤。
2. 選取 [新增]。在 [新增函式] 窗格中，選取下列設定：
  - 開發環境：在入口網站中開發
  - 選取範本：計時器觸發程序
3. 選取 [新增] 以建立計時器觸發程序函數。

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

移至已部署的函數應用程式，然後在 [開發工具] 下，選取 [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/"); 
    } 
}

將 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 (最少五個測試位置)。

位置母體標籤

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

Azure

Display name	母體名稱
澳大利亞東部	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

Display name	母體名稱
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

Display name	母體名稱
中國東部	mc-cne-azr
中國東部 2	mc-cne2-azr
中國北部	mc-cnn-azr
中國北部 2	mc-cnn2-azr

啟用警示

警示現在預設為自動啟用，但為了完整設定警示，您一開始必須先建立可用性測試。

注意

使用新的整合警示時，必須在警示體驗中設定動作群組的相關警示規則嚴重性和通知喜好設定。若未進行下列步驟，您只會收到入口網站內部通知。

儲存可用性測試之後，在 [詳細資料] 索引標籤中您剛剛建立的測試旁，按一下省略符號。選取 [開啟規則 (警示) 頁面]。
設定所需的嚴重性層級、規則描述以及動作群組，其中有您想要用於此警示規則的通知喜好設定。

警示準則

自動啟用的可用性警示會在您定義的端點無法使用然後再次可用時觸發電子郵件。透過此體驗建立的可用性警示以狀態為基礎。當符合警示準則時，就會在偵測到網站無法使用時產生單一警示。如果下次評估警示準則時網站仍然關閉，則不會產生新的警示。

例如，假設您的網站已關閉一小時，且您已設定評估頻率為 15 分鐘的電子郵件警示。則您只會在網站關閉時收到一封電子郵件，然後在網站重新上線時收到另一封電子郵件。您不會每隔 15 分鐘收到連續的警示，提醒您網站仍然無法使用。

如果網站只關閉一小段時間，您可能不想收到通知，例如維護期間。您可以將評估頻率變更為高於預期停機時間的值，最多 15 分鐘。您也可以提高警示位置閾值，因此只有當網站在特定數量的區域中關閉時才會觸發警示。若是較長的排程停機時間，請暫時停用警示規則或建立自訂規則。這讓您在考慮停機時間時有更多選項。

變更警示準則

若要變更位置閾值、彙總期間和測試頻率，請在警示規則的編輯頁面上選取條件，開啟 [設定訊號邏輯] 視窗。

建立自訂警示規則

如果您需要進階功能，您可以在 [警示] 索引標籤建立自訂警示規則。選取 [建立]>[警示規則]。在 [訊號類型] 選取 [計量] 以顯示所有可用的訊號，然後選取 [可用性]。

自訂警示規則可提供更長時間的彙總期間 (最多 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 查詢資料。可以透過線條和散佈圖檢視以視覺化可用性測試結果。

檢查可用性

從檢閱 Application Insights 資源之 [可用性] 索引標籤上的圖表開始。

標準測試
TrackAvailability

顯示可用性頁面的螢幕擷取畫面，其中已醒目提示 [重新整理] 按鈕。

散佈圖檢視會顯示測試結果的樣本，其中包含診斷測試步驟詳細資料。測試引擎會儲存失敗測試的診斷詳細資料。對於成功的測試，系統會儲存執行子集的診斷詳細資料。將滑鼠停留在任何綠/紅點上，以查看測試、測試名稱和位置。

顯示程式行檢視的螢幕擷取畫面。

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

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

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

檢查和編輯測試

若要編輯、暫時停用或刪除測試，請選取測試名稱旁邊的省略號。設定變更可能需要 20 分鐘的時間，才能在變更之後傳播至所有的測試代理程式。

螢幕擷取畫面顯示了測試詳細資料檢視。編輯和停用網路測試。

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

如果您看到失敗

選取一個紅點。

顯示 [端對端交易詳細資料] 索引標籤的螢幕擷取畫面。

從可用性測試結果中，您可以看到所有元件的交易詳細資料。您可以在其中：

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

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

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

顯示伺服器端診斷的螢幕擷取畫面。

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

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

Log Analytics 中的查詢

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

移轉可用性測試

在本文中，我們會引導您完成從傳統 URL ping 測試移轉至新式且有效率的標準測試的流程。

我們會藉由提供明確的逐步指示來簡化此流程，以確保順暢的轉換，並為您的應用程式提供最新的監視功能。

將傳統 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 端點，這些端點會用於 URL Ping 測試。

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

驗證流量

在標準可用性測試中設定自訂標頭來驗證流量。

產生權杖或 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 範圍。有關當前服務標籤及其 I P詳細資訊的完整清單，請下載 JSON 檔案。
1. 在您的網路安全性群組資源中，選取 [設定] 下的 [輸入安全性規則]。然後選取 [新增]。
2. 接下來，選取 [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 設定

警告

在 2024 年 10 月 31 日，配合 Azure 寬版舊版 TLS 淘汰，將會淘汰 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

橢圓曲線：

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 監視器活頁簿一樣編輯報表。

螢幕擷取畫面顯示選取編輯按鈕以變更圓形圖視覺效果的 GIF。

您可以根據小組的需求自訂查詢或視覺效果。

Log Analytics

查詢全都可以在 Log Analytics 中執行，並用於其他報表或儀表板。

移除參數限制，並重複使用核心查詢。

報表可以與您的小組和領導階層共用，或釘選到儀表板以供進一步使用。使用者必須具有實際活頁簿儲存所在 Application Insights 資源的讀取權限/存取權。

常見問題集

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

一般

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

我們的 Web 測試是在分散於全球各地的網路節點上執行。有兩個解決方案：

防火牆門 - 允許從這個又長又可變更的 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 伺服器所執行主控平台的小組連絡 (如果不知道程序)。

在 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 Resource Manager TLS 支援。這項資源提供 TLS 支援和淘汰時程表的詳細資料。

哪裡可以取得 TLS 支援？

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

共用方式為

Application Insights 可用性測試

可用性測試類型

建立可用性測試

必要條件

開始使用

成功準則

可用性警示

位置母體標籤

Azure

Azure Government

由 21Vianet 營運的 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

存取和共用

常見問題集

一般

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

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

TLS 支援

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

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

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

在 2024 年 10 月 31 日之後，針對受影響的測試會有什麼 Web 測試行為？

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

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

哪裡可以取得 TLS 支援？

下一步

意見反應

意見反應

其他資源