Application Insights 可用性テスト

Web アプリまたは Web サイトをデプロイした後、繰り返すテストを設定して、可用性と応答性を監視できます。 Application Insights は、世界各地の複数のポイントから定期的にアプリケーションに Web 要求を送信します。 お使いのアプリケーションが応答していない場合、または応答が遅すぎる場合は、アラートを受信できます。 Application Insights リソースごとに最大 100 個の可用性テストを作成できます。

可用性テストでは、テストしている Web サイトに変更を加える必要はありません。パブリック インターネットからアクセスできる HTTP または HTTPS エンドポイントに対して動作します。 サービスが依存している REST API の可用性をテストすることもできます。

可用性テストの種類

可用性テストには、次の 4 種類があります。

• 標準テスト: これは、非推奨の URL ping テストと同様に、1 つの要求を送信して Web サイトの可用性をチェックする可用性テストの一種です。 標準テストには、エンドポイントが応答し、パフォーマンスを測定しているかどうかの検証に加え、TLS/SSL 証明書の有効性、プロアクティブな有効期間チェック、HTTP 要求動詞 (GET、HEAD、POST など)、カスタム ヘッダー、HTTP 要求に関連付けられたカスタム データなども含まれます。

• カスタム TrackAvailability テスト: 可用性テストを実行するカスタム アプリケーションを作成することにした場合、TrackAvailability() メソッドを使用して、結果を Application Insights に送信できます。

• (非推奨) 複数ステップの Web テスト: この一連の Web 要求の記録を再生して、より複雑なシナリオをテストできます。 複数ステップ Web テストは Visual Studio Enterprise で作成され、ポータルにアップロードされ、ここでそれらを実行できます。

• (非推奨) URL ping テスト: Azure portal を使用してこのテストを作成して、エンドポイントが応答しているかどうかを検証し、その応答に関連するパフォーマンスを測定できます。 また、依存する要求の解析などの高度な機能と結合されたカスタム成功基準を設定し、再試行が可能になります。

可用性テストを作成する

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.video2.skills-academy.com/"); 
    } 
}

可用性のアラート

位置情報の作成タグ

Azure Resource Manager を使って可用性 URL の ping テストをデプロイするときに、次の作成タグを地理的位置属性に使用できます。

Azure

Azure Government

21Vianet が運用する Microsoft Azure

アラートを有効にする

現在、アラートは既定で自動的に有効になりますが、アラートを完全に構成するには、可用性テストを最初に作成する必要があります。

1. 可用性テストを保存した後、[詳細] タブで、作成したテストの横の省略記号を選択します。 [Open Rules (Alerts) page] (ルール (アラート) ページを開く) を選択します。

   

2. 重大度レベル、ルールの説明、およびこのアラート ルールに使用する、通知の基本設定が含まれているアクション グループを設定します。

アラートの条件

自動的に有効になる可用性アラートにより、定義したエンドポイントが使用できなくなったとき、および再び使用可能になったときに電子メールがトリガーされます。 このエクスペリエンスによって作成される可用性アラートは、状態に基づきます。 アラートの条件が満たされると、Web サイトが使用不可として検出された場合に 1 つのアラートが生成されます。 次にアラートの条件が評価されたときに Web サイトがまだダウンしている場合、新しいアラートは生成されません。

たとえば、Web サイトが 1 時間ダウンし、評価頻度が 15 分のメール アラートを設定してあるとします。 Web サイトがダウンした時点でのみメールが届き、その Web サイトがオンラインに戻った時点で別のメールが届きます。 Web サイトがまだ使用不可であることを通知するアラートが 15 分ごとに継続的に届くことはありません。

メンテナンス中など、Web サイトが短時間だけダウンした場合には通知を受け取りたくない場合があります。 評価頻度を、予想されるダウンタイムよりも長い値 (最大 15 分) に変更できます。 また、アラートの場所のしきい値を大きくすることもできます。そうすると、Web サイトが特定の数のリージョンでダウンしている場合にのみアラートがトリガーされます。 スケジュールされたダウンタイムが長い場合は、アラート ルールを一時的に非アクティブ化するか、カスタム ルールを作成します。 そうすれば、ダウンタイムを考慮に入れるためのより多くのオプションが提供されます。

アラートの条件を変更する

場所のしきい値、集計期間、テストの頻度を変更するには、アラート ルールの編集ページで条件を選択し、[シグナル ロジックの構成] ウィンドウを開きます。

カスタム アラート ルールを作成する

高度な機能が必要な場合は、[アラート] タブでカスタムのアラート ルールを作成できます。[アラート ルールの作成(>A)] を選択します。 使用可能なシグナルをすべて表示するには、[シグナルの種類] で [メトリック] を選択し、[可用性] を選択します。

カスタムのアラート ルールでは、より大きい値を使用できます。集計期間については 6 時間ではなく最大 24 時間、テストの頻度については 15 分ではなく最大 1 時間です。 さまざまな演算子、集計の種類、しきい値を選択することで、ロジックを詳細に定義するためのオプションも追加されます。

• Y 箇所中 X 箇所で障害が報告された場合にアラートを生成する: 新しい可用性テストを作成するとき、新しい統合アラート エクスペリエンスでは Y 箇所中 X 箇所のアラート ルールが既定で有効になります。 オプトアウトするには、"クラシック" オプションを選択するか、またはアラート ルールを無効にすることを選択します。 前述の手順に従って、アラートがトリガーされたときに通知を受信するようにアクション グループを構成します。 この手順を行わないと、ルールがトリガーされたとき、ポータル内通知を受け取るだけとなります。

• 可用性メトリックに関するアラート: 新しい統合アラートを使用すると、セグメント化された可用性の集計メトリックおよびテスト継続期間メトリックに関してもアラートを生成できます。

  1. [メトリック] エクスペリエンス内で Application Insights リソースを選択し、[可用性] メトリックを選択します。

  2. メニューから [アラートを構成する] オプションを選択すると、新しいエクスペリエンスが表示され、アラート ルールの設定対象とする特定のテストまたは場所を選択できます。 ここでは、このアラート ルールに対してアクション グループを構成することもできます。

• カスタム分析クエリに関するアラート: 新しい統合アラートを使用すると、カスタム ログ クエリに関するアラートを生成できます。 カスタム クエリを使用すると、可用性の問題を示す最も確かなシグナルを取得するのに役立つ任意の条件に基づいてアラートを生成することができます。 また、これは TrackAvailability SDK を使用してカスタムの可用性の結果を送信する場合にも当てはまります。

  可用性データに関するメトリックにはカスタムの可用性の結果が含まれます。これは、TrackAvailability SDK を呼び出すことによって送信できます。 メトリックに関するアラートのサポートを使用することにより、カスタムの可用性の結果に関するアラートを生成することができます。

アラートを自動化する

Azure Resource Manager テンプレートを使用してこのプロセスを自動化する方法については、Azure Resource Manager テンプレートを使用したメトリック アラートの作成に関するページを参照してください。

可用性テストの結果を表示する

このセクションでは、Azure portal で可用性テストの結果を確認し、Log Analytics を使用してデータにクエリを実行する方法について説明します。 可用性テストの結果は、折れ線グラフと散布図の両方で視覚化できます。

可用性を確認する

まず、Application Insights リソースの [Availability] (可用性) タブでグラフを確認します。

散布図には、診断テスト手順の詳細が含まれたテスト結果のサンプルが表示されます。 テスト エンジンは、失敗したテストの診断の詳細を格納します。 成功したテストの場合、診断の詳細は実行のサブセットに対して格納されます。 緑色/赤色の点の上にポインターを置くと、テスト、テスト名、および場所が表示されます。

特定のテストまたは場所を選択します。 または期間を短くして、目的の期間に関するより詳細な結果を表示できます。 検索エクスプローラーを使用して、すべての実行の結果を表示します。 または Log Analytics クエリを使用して、このデータに対してカスタム レポートを実行できます。

エンドツーエンドのトランザクションの詳細を表示するには、[詳細の表示] で [成功] または [失敗] を選択します。 次に、サンプルを選択します。 グラフでデータ ポイントを選択することにより、エンドツーエンドのトランザクションの詳細も取得できます。

テストを調べて編集する

テストの編集、一時的な無効化、削除を行うには、テスト名の横の省略記号を選択します。 変更を行った後、すべてのテスト エージェントに構成の変更が反映されるまで、最大 20 分かかる場合があります。

サービスに対するメンテナンスを実行している間、関連付けられた可用性テストまたはアラート ルールを無効にすることもできます。

エラーが発生した場合

赤い点を選択します。

可用性のテスト結果から、すべてのコンポーネントにわたるトランザクションの詳細を確認できます。 ここで、次のことを行うことができます。

• トラブルシューティング レポートを確認して、テストが失敗する原因を特定しますが、アプリケーションは引き続き利用できます。
• サーバーから受信した応答を調べる。
• 失敗した可用性テストの処理中に収集された、サーバー側の相関関係を持つテレメトリを使用してエラーを診断する。
• 懸案や作業の項目を Git または Azure Boards に記録して問題を追跡する。 バグには、このイベントへのリンクが含まれます。
• Visual Studio で Web テスト結果を開く。

エンドツーエンドのトランザクションの診断エクスペリエンスの詳細については、トランザクション診断のドキュメントを参照してください。

例外の行を選択すると、代理可用性テストが失敗した原因であるサーバー側の例外の詳細が表示されます。 コード レベルの豊富な診断のデバッグ スナップショットを取得することもできます。

生の結果に加えて、メトリックス エクスプローラーに 2 つの重要な可用性メトリックを表示することもできます。

• 可用性: すべてのテスト実行にわたる、成功したテストの割合 (%)。
• テスト期間: すべてのテスト実行にわたる平均のテスト期間。

Log Analytics のサンプル クエリ

Log Analytics を使用して、可用性の結果、依存関係、その他を見ることができます。 Log Analytics の詳細については、ログ クエリの概要に関するページを参照してください。

可用性テストを移行する

この記事では、従来の URL ping テストから最新かつ効率的な標準テストに移行するプロセスについて説明します。

シームレスな移行を確実にし、最新の監視機能をアプリケーションに提供するための明確かつ詳細な手順を提供することで、このプロセスを簡略化します。

従来の URL ping テストを標準テストに移行する

次の手順では、URL ping テストの機能をレプリケートする標準テストの作成プロセスについて説明します。 これにより、以前作成した URL ping テストを使用して、標準テストの高度な機能をより簡単に利用し始めることができます。

必須コンポーネント

• Application Insights での URL ping テスト
• Azure PowerShell のアクセス

作業の開始

1. Azure PowerShell (Connect-AzAccount + Set-AzContext) を使用してサブスクリプションに接続します。

2. 現在のサブスクリプションのすべての URL ping テストを一覧表示してください。

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

3. 移行したい URL ping テストを見つけて、そのリソース グループと名前を記録してください。

4. 次のコマンドで、URL ping テストと同じロジックを使用して標準テストを作成します。

   Note

   次のコマンドは、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);
   

5. 新しい標準テストには既定でアラート ルールがないため、わずらわしいアラートは作成されません。 URL ping テストは変更されないため、これについては引き続きアラートを利用できます。

6. 新しい標準テストの機能を確認したら、URL ping テストを参照するアラート ルールを更新して、代わりに標準テストを参照するようにします。 次に、URL ping テストを無効化または削除します。

7. Azure PowerShell を使用して URL ping テストを削除する場合は、次のコマンドを使用できます。

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

ファイアウォールの内側でのテスト

ファイアウォールの内側でエンドポイントの可用性を確保するには、パブリック可用性テストを有効にするか、切断された、またはイングレスのシナリオで可用性テストを実行します。

パブリック可用性テストの有効化

内部 Web サイトにパブリック ドメイン ネーム システム (DNS) レコードがあることを確認します。 DNS を解決できない場合、可用性テストは失敗します。 詳細については、内部アプリケーションのカスタム ドメイン名の作成に関するページを参照してください。

トラフィックを認証する

トラフィックを検証するために、標準の可用性テストでカスタム ヘッダーを設定します。

1. 可用性テストからのトラフィックを識別するためのトークンまたは GUID を生成します。

2. 可用性テストを作成または更新するときに、カスタム ヘッダー "X-Customer-InstanceId" を [標準テスト情報] セクションの値 ApplicationInsightsAvailability:<GUID generated in step 1> と共に追加します。

3. これまでの手順で定義したヘッダーと値が受信トラフィックに含まれていることをサービスで必ず確認します。

   

または、トークンをクエリ パラメーターとして設定します。 たとえば、https://yourtestendpoint/?x-customer-instanceid=applicationinsightsavailability:<your guid> のようにします。

可用性テストからの受信要求を許可するようにファイアウォールを構成する

• 個々の IP を承認したり、最新の IP リストを維持したりせずに Azure サービスを簡単に有効にするには、サービス タグを使用します。 これらのタグを Azure Firewall とネットワーク セキュリティ グループの全体に適用して、可用性テスト サービスがエンドポイントにアクセスできるようにします。 サービス タグ ApplicationInsightsAvailability は、すべての可用性テストに適用されます。

  1. Azure ネットワーク セキュリティ グループを使用する場合は、ネットワーク セキュリティ グループ リソースに移動し、[設定] で [受信セキュリティ規則] を選択します。 その後、 [追加] を選択します。

     

  2. 次に、ソースとして [サービス タグ] を選択し、ソース サービス タグとして [ApplicationInsightsAvailability] を選択します。 サービス タグからの着信トラフィック用にオープン ポート 80 (http) と 443 (https) を使用します。

     

• エンドポイントが Azure の外部にある場合、またはサービス タグがオプションではない場合にアクセスを管理するには、Web テスト エージェントの IP アドレスを許可リストに登録します。 PowerShell、Azure CLI、または Service Tag API を使用した REST 呼び出しを使用して、IP 範囲のクエリを実行できます。 現在のサービス タグとその IP の詳細の包括的な一覧については、JSON ファイルをダウンロードしてください。

  1. ネットワーク セキュリティ グループ リソースで、[設定] の [受信セキュリティ規則] を選択します。 その後、 [追加] を選択します。

  2. 次に、ソースとして [IP アドレス] を選択します。 次に、[ソース IP アドレス/CIRD 範囲] のコンマ区切りの一覧に IP アドレスを追加します。

     

切断またはイングレスなしシナリオ

1. Azure Private Link を使用して、Application Insights リソースを内部サービス エンドポイントに接続します。

2. 内部サーバーまたはエンドポイントを定期的にテストするカスタム コードを作成します。 コア 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 1.3

暗号スイート

• TLS_AES_256_GCM_SHA384
• TLS_AES_128_GCM_SHA256

楕円曲線:

• NistP384
• NistP256

TLS 構成の非推奨化

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

トラブルシューティング

ダウンタイム、SLA、および停止のブック

この記事では、Application Insights リソースと Azure サブスクリプションにわたる 1 つのペインで、Web テストのサービス レベル アグリーメント (SLA) を簡単に計算してレポートする方法を紹介します。 ダウンタイムと停止レポートには、顧客の接続、一般的なアプリケーションの応答時間、および発生したダウンタイムについて理解を深められるように、強力な構築済みのクエリとデータ視覚化が用意されています。

SLA ブック テンプレートには、次の 2 つの方法で Application Insights リソースからアクセスできます。

• [可用性] ペインを開き、画面の上部にある [SLA レポート] を選択します。

  

• [Workbooks] ペインを開き、[ダウンタイムと停止] を選択します。

  

パラメーターの柔軟性

ブックに設定されているパラメーターは、レポートの残りの部分に影響します。

• Subscriptions、App Insights Resources、Web Test: これらのパラメーターによって、大まかなリソースのオプションが決まります。 これらは Log Analytics クエリに基づいており、すべてのレポート クエリで使われます。
• Failure Threshold と Outage Window: これらのパラメーターを使って、サービス停止の独自の条件を決定できます。 たとえば、選択した期間にエラーが発生した場所のカウンターに基づいた、Application Insights の可用性アラートの条件です。 一般的なしきい値は、5 分間に 3 つの場所となります。
• Maintenance Period: このパラメーターを使って、通常のメンテナンス頻度を選択できます。 Maintenance Window は、メンテナンス期間例の日時セレクターです。 特定の期間に発生したすべてのデータは、結果では無視されます。
• Availability Target %: このパラメーターを使ってターゲット目標を指定し、カスタム値を受け取ります。

[概要] ページ

概要ページには、お客様の以下に関する概要情報が含まれています。

• SLA の合計 (定義されている場合はメンテナンス期間を除く)
• エンドツーエンドの停止インスタンス
• アプリケーション ダウンタイム

停止インスタンスは、停止パラメーターに基づき、テストが失敗するようになってから成功するまでの時間で定義されます。 テストが午前 8:00 に失敗するようになり、午前 10:00 に再び成功した場合は、データのその期間全体が同じ停止と見なされます。

また、報告期間中に発生した最長の停止を調査することもできます。

一部のテストは、さらに調査するために Application Insights リソースにリンクすることができます。 ただし、これを利用できるのはワークスペースベースの Application Insights リソースのみです。

ダウンタイム、障害、および失敗

[停止とダウンタイム] タブには、停止インスタンスの合計と、テスト別に分類されたダウンタイムの合計に関する情報があります。

[Failures by Location] (場所別の失敗) タブには、問題がある可能性のある接続領域を特定するのに役立つ、テストに失敗した場所の geo マップがあります。

レポートの編集

レポートは、他の Azure Monitor ブックと同様に編集できます。

チームのニーズに基づいて、クエリや視覚化をカスタマイズできます。

Log Analytics

クエリはすべて Log Analytics で実行し、他のレポートまたはダッシュボードで使用することができます。

パラメーターの制限を解除して、コア クエリを再利用してください。

アクセスと共有

レポートをチームやリーダーと共有することや、ダッシュボードにピン留めしてさらに使用することができます。 ユーザーは、実際のブックが格納されている Application Insights リソースに対する読み取りアクセス許可とアクセス権を持っている必要があります。

よく寄せられる質問

このセクションでは、一般的な質問への回答を示します。

全般

イントラネット サーバー上で可用性テストを実行することはできますか?

Microsoft の Web テストは、世界中に分布する Points of Presence で実行されます。 以下に示す 2 つのソリューションがあります。

• ファイアウォール ドア: 頻繁に変更される多数の 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 構成すべてを含む TLS クライアント Hello メッセージが送信されます。 リモート エンドポイントが可用性テスト クライアントと共通の TLS 構成を共有している場合、TLS ハンドシェイクが成功します。 それ以外の場合、Web テストは TLS ハンドシェイクの失敗によって失敗します。

Web テストが影響を受けないようにするにはどうすればよいですか?

影響を回避するために、Web テストがやり取りを行う各リモート エンドポイント (依存要求を含む) は、可用性テストがサポートするのと同じプロトコル バージョン、暗号スイート、楕円曲線の内の少なくとも 1 つの組み合わせをサポートする必要があります。 リモート エンドポイントが必要な TLS 構成をサポートしていない場合は、上記の非推奨化後の TLS 構成のいずれかの組み合わせをサポートするように更新する必要があります。 これらのエンドポイントは、(できれば成功した Web テスト実行の) Web テストのトランザクションの詳細を表示することで検出できます。

リモート エンドポイントでどの TLS 構成がサポートされているかを検証するにはどうすればよいですか?

エンドポイントがどの TLS 構成をサポートしているかをテストするために利用できるツールがいくつか存在します。 1 つの方法は、こちらのページで詳しく説明されている例に従うことです。 リモート エンドポイントがパブリック インターネット経由で利用できない場合は、エンドポイントを呼び出すアクセス権を持つマシンから、リモート エンドポイントでサポートされている TLS 構成を検証するようにする必要があります。

2024 年 10 月 31 日以降、影響を受けるテストの Web テストの動作はどのようなものになりますか?

この非推奨化の影響を受けるすべての TLS ハンドシェイクの失敗で発生する決まった例外型は存在しません。 しかし、Web テストの失敗で発生することになる最も一般的な例外は The request was aborted: Couldn't create SSL/TLS secure channel となるでしょう。 また、影響を受ける可能性がある Web テスト結果に関する TLS 転送のトラブルシューティング手順でも、TLS 関連のエラーを確認できるはずです。

自分の Web テストで現在どの TLS 構成が使用されているかを表示できますか?

Web テストの実行中にネゴシエートされた TLS 構成を表示することはできません。 リモート エンドポイントが可用性テストで一般的な TLS 構成をサポートしている限り、非推奨化後にどのような影響も発生しないはずです。

非推奨化が影響を与える可用性テスト サービス内のコンポーネントはどれですか?

このドキュメントで詳しく説明されている TLS の非推奨化が可用性テストの Web テスト実行の動作に影響を与えるのは、2024 年 10 月 31 日以降となるはずです。 CRUD 操作に関する可用性テスト サービスとのやり取りの詳細については、「Azure Resource Manager TLS サポート」を参照してください。 このリソースは、TLS のサポートと非推奨化のタイムラインの詳細について説明しています。

TLS に関するサポートはどこで受けることができますか?

従来の TLS の問題に関する一般的な質問については、「TLS の問題の解決」を参照してください。

次のステップ

• トラブルシューティング
• Azure Resource Manager テンプレートの Web テスト
• Web テスト REST API