Application Insights 可用性テスト
Web アプリまたは Web サイトをデプロイした後、繰り返すテストを設定して、可用性と応答性を監視できます。 Application Insights は、世界各地の複数のポイントから定期的にアプリケーションに Web 要求を送信します。 お使いのアプリケーションが応答していない場合、または応答が遅すぎる場合は、アラートを受信できます。 Application Insights リソースごとに最大 100 個の可用性テストを作成できます。
可用性テストでは、テストしている Web サイトに変更を加える必要はありません。パブリック インターネットからアクセスできる HTTP または HTTPS エンドポイントに対して動作します。 サービスが依存している REST API の可用性をテストすることもできます。
Note
可用性テストは、保存時の Azure データ暗号化ポリシーに従って暗号化されて格納されます。
可用性テストの種類
可用性テストには、次の 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 を使用してこのテストを作成して、エンドポイントが応答しているかどうかを検証し、その応答に関連するパフォーマンスを測定できます。 また、依存する要求の解析などの高度な機能と結合されたカスタム成功基準を設定し、再試行が可能になります。
重要
今後、可用性テストが 2 つ提供終了になる予定です。
マルチステップ 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 リソースに移動し、 [可用性] ウィンドウを選択します。
[標準テストの追加] を選択します。
次の表で説明されているテスト名、URL、およびその他の設定を入力します。 そのうえで [Create](作成) を選択します。
設定 説明 URL [URL] は、テストする任意の Web ページにすることができますが、パブリック インターネットから表示できる必要があります。 URL にはクエリ文字列を含めることができます。 したがって、たとえば限られた範囲でデータベースを実行できます。 URL が解決されてリダイレクトする場合、それに続いて最大で 10 個リダイレクトを使用できます。 依存する要求の解析 テストでは、テスト対象の Web ページの一部である画像、スクリプト、スタイル ファイル、およびその他のファイルが要求されます。 記録される応答時間には、これらのファイルの取得にかかる時間が含まれます。 テスト全体のタイムアウト時間内にこれらすべてのリソースを正常にダウンロードできない場合、テストは失敗します。 このオプションが選択されていない場合、テストでは指定した URL にあるファイルのみが要求されます。 このオプションを有効にすると、より厳密なチェックが行われます。 サイトを手動で参照しているときは気付かない場合があることが原因でテストが失敗する可能性があります。 解析される従属要求は最大 15 個であることに注意してください。 再試行を有効にする テストが失敗した場合に、少し間を置いてテストを再試行します。 エラーは試行が 3 回連続で失敗した場合にのみ報告されます。 その後、後続のテストが通常のテスト間隔で実行されます。 再試行は、次の成功まで一時的に中断されます。 このルールがテスト場所ごとに独立して適用されます。 このオプションはオンにすることをお勧めします。 再試行の際に平均でエラーの約 80% がなくなります。 SSL 証明書の検証テスト SSL 証明書が正しくインストールされていること、有効であること、信頼できること、ユーザーにエラーが発生しないことを確認するために、ご自身の Web サイト上で、その SSL 証明書を検証できます。 プロアクティブな有効期間チェック この設定により、ご自身の SSL 証明書の有効期限が切れる前に設定期間を定義できます。 有効期限が切れた後、テストは失敗します。 テスト間隔 各テストの場所からテストを実行する頻度を設定します。 既定の間隔が 5 分で、テストの場所が 5 か所の場合、サイトは平均して毎分テストされます。 テストの場所 サーバーはこれらの場所から指定の URL に Web 要求を送信します。 Web サイトの問題とネットワークの問題とを確実に区別するために、テストの場所は 5 か所以上にすることをお勧めします。 最大 16 個の場所を選択できます。 カスタム ヘッダー 操作パラメーターを定義するキーと値のペア。 HTTP 要求動詞 要求に対して実行するアクションを示します。 要求本文 ご自身の HTTP 要求に関連付けられているカスタム データ。 独自のファイルをアップロードしたり、コンテンツを入力したり、この機能を無効にしたりできます。
成功の基準
設定 | 説明 |
---|---|
テストのタイムアウト | この値を引き下げると、応答が遅い場合に警告されます。 テストは、この期間内にサイトから応答が返されない場合に、エラーとしてカウントされます。 [従属要求の解析] をオンにした場合、すべての画像、スタイル ファイル、スクリプト、その他依存するリソースがこの期間内に受信される必要があります。 |
HTTP 応答 | 成功としてカウントされる、返される状態コード。 番号 200 は通常の Web ページが返されたことを示すコードです。 |
コンテンツの一致 | "Welcome!" などの文字列。それぞれの応答内に、大文字と小文字を区別した完全一致があるかどうかをテストします。 文字列は、(ワイルドカードを含まない) プレーン文字列である必要があります。 ページ コンテンツが変更された場合は、この文字列の更新が必要になる可能性があることに注意してください。 コンテンツの一致では、英字のみがサポートされています。 |
可用性のアラート
設定 | 説明 |
---|---|
ほぼリアルタイム | 準リアルタイムのアラートを使用することが推奨されます。 この種類のアラートの構成は、可用性テストの作成後に実行されます。 |
アラートの場所のしきい値 | 少なくとも 3/5 の場所にすることをお勧めします。 アラートの場所のしきい値とテストの場所の数の最適な関係は、アラートの場所のしきい値 = テストの場所の数 - 2 です。テストの場所は、少なくとも 5 か所にします。 |
位置情報の作成タグ
Azure Resource Manager を使って可用性 URL の ping テストをデプロイするときに、次の作成タグを地理的位置属性に使用できます。
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 バージニア州 | usgov-va-azr |
USGov アリゾナ | usgov-phx-azr |
USGov テキサス | usgov-tx-azr |
USDoD 東部 | usgov-ddeast-azr |
USDoD 中部 | usgov-ddcentral-azr |
21Vianet が運用する Microsoft Azure
表示名 | 作成名 |
---|---|
中国東部 | mc-cne-azr |
中国東部 2 | mc-cne2-azr |
中国北部 | mc-cnn-azr |
中国北部 2 | mc-cnn2-azr |
アラートを有効にする
現在、アラートは既定で自動的に有効になりますが、アラートを完全に構成するには、可用性テストを最初に作成する必要があります。
Note
新しい統合アラートの場合、アラート ルールの重大度と通知の基本設定をアクション グループと一緒に、アラート エクスペリエンスで構成する必要があります。 次の手順を行わないと、ポータル内通知を受け取るだけとなります。
可用性テストを保存した後、[詳細] タブで、作成したテストの横の省略記号を選択します。 [Open Rules (Alerts) page] (ルール (アラート) ページを開く) を選択します。
重大度レベル、ルールの説明、およびこのアラート ルールに使用する、通知の基本設定が含まれているアクション グループを設定します。
アラートの条件
自動的に有効になる可用性アラートにより、定義したエンドポイントが使用できなくなったとき、および再び使用可能になったときに電子メールがトリガーされます。 このエクスペリエンスによって作成される可用性アラートは、状態に基づきます。 アラートの条件が満たされると、Web サイトが使用不可として検出された場合に 1 つのアラートが生成されます。 次にアラートの条件が評価されたときに Web サイトがまだダウンしている場合、新しいアラートは生成されません。
たとえば、Web サイトが 1 時間ダウンし、評価頻度が 15 分のメール アラートを設定してあるとします。 Web サイトがダウンした時点でのみメールが届き、その Web サイトがオンラインに戻った時点で別のメールが届きます。 Web サイトがまだ使用不可であることを通知するアラートが 15 分ごとに継続的に届くことはありません。
メンテナンス中など、Web サイトが短時間だけダウンした場合には通知を受け取りたくない場合があります。 評価頻度を、予想されるダウンタイムよりも長い値 (最大 15 分) に変更できます。 また、アラートの場所のしきい値を大きくすることもできます。そうすると、Web サイトが特定の数のリージョンでダウンしている場合にのみアラートがトリガーされます。 スケジュールされたダウンタイムが長い場合は、アラート ルールを一時的に非アクティブ化するか、カスタム ルールを作成します。 そうすれば、ダウンタイムを考慮に入れるためのより多くのオプションが提供されます。
アラートの条件を変更する
場所のしきい値、集計期間、テストの頻度を変更するには、アラート ルールの編集ページで条件を選択し、[シグナル ロジックの構成] ウィンドウを開きます。
カスタム アラート ルールを作成する
高度な機能が必要な場合は、[アラート] タブでカスタムのアラート ルールを作成できます。[アラート ルールの作成(>A)] を選択します。 使用可能なシグナルをすべて表示するには、[シグナルの種類] で [メトリック] を選択し、[可用性] を選択します。
カスタムのアラート ルールでは、より大きい値を使用できます。集計期間については 6 時間ではなく最大 24 時間、テストの頻度については 15 分ではなく最大 1 時間です。 さまざまな演算子、集計の種類、しきい値を選択することで、ロジックを詳細に定義するためのオプションも追加されます。
Y 箇所中 X 箇所で障害が報告された場合にアラートを生成する: 新しい可用性テストを作成するとき、新しい統合アラート エクスペリエンスでは Y 箇所中 X 箇所のアラート ルールが既定で有効になります。 オプトアウトするには、"クラシック" オプションを選択するか、またはアラート ルールを無効にすることを選択します。 前述の手順に従って、アラートがトリガーされたときに通知を受信するようにアクション グループを構成します。 この手順を行わないと、ルールがトリガーされたとき、ポータル内通知を受け取るだけとなります。
可用性メトリックに関するアラート: 新しい統合アラートを使用すると、セグメント化された可用性の集計メトリックおよびテスト継続期間メトリックに関してもアラートを生成できます。
[メトリック] エクスペリエンス内で Application Insights リソースを選択し、[可用性] メトリックを選択します。
メニューから [アラートを構成する] オプションを選択すると、新しいエクスペリエンスが表示され、アラート ルールの設定対象とする特定のテストまたは場所を選択できます。 ここでは、このアラート ルールに対してアクション グループを構成することもできます。
カスタム分析クエリに関するアラート: 新しい統合アラートを使用すると、カスタム ログ クエリに関するアラートを生成できます。 カスタム クエリを使用すると、可用性の問題を示す最も確かなシグナルを取得するのに役立つ任意の条件に基づいてアラートを生成することができます。 また、これは 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 テストを使用して、標準テストの高度な機能をより簡単に利用し始めることができます。
重要
コストは、標準テストの実行に関連付けられます。 標準テストを作成すると、テストの実行に対して課金されます。 このプロセスを開始する前に、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 テストと同じロジックを使用して標準テストを作成します。
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);
新しい標準テストには既定でアラート ルールがないため、わずらわしいアラートは作成されません。 URL ping テストは変更されないため、これについては引き続きアラートを利用できます。
新しい標準テストの機能を確認したら、URL ping テストを参照するアラート ルールを更新して、代わりに標準テストを参照するようにします。 次に、URL ping テストを無効化または削除します。
Azure PowerShell を使用して URL ping テストを削除する場合は、次のコマンドを使用できます。
Remove-AzApplicationInsightsWebTest -ResourceGroupName $resourceGroup -Name $pingTestName;
ファイアウォールの内側でのテスト
ファイアウォールの内側でエンドポイントの可用性を確保するには、パブリック可用性テストを有効にするか、切断された、またはイングレスのシナリオで可用性テストを実行します。
パブリック可用性テストの有効化
内部 Web サイトにパブリック ドメイン ネーム システム (DNS) レコードがあることを確認します。 DNS を解決できない場合、可用性テストは失敗します。 詳細については、内部アプリケーションのカスタム ドメイン名の作成に関するページを参照してください。
警告
可用性テスト サービスによって使用される IP アドレスは共有され、ファイアウォールで保護されたサービス エンドポイントを他のテストに公開できます。 IP アドレスのフィルター処理だけではサービスのトラフィックのセキュリティは確保されないため、Web 要求の配信元を確認するために追加のカスタム ヘッダーを追加することをお勧めします。 詳細については、「仮想ネットワーク サービス タグ」を参照してください。
トラフィックを認証する
トラフィックを検証するために、標準の可用性テストでカスタム ヘッダーを設定します。
可用性テストからのトラフィックを識別するためのトークンまたは GUID を生成します。
可用性テストを作成または更新するときに、カスタム ヘッダー "X-Customer-InstanceId" を [標準テスト情報] セクションの値
ApplicationInsightsAvailability:<GUID generated in step 1>
と共に追加します。これまでの手順で定義したヘッダーと値が受信トラフィックに含まれていることをサービスで必ず確認します。
または、トークンをクエリ パラメーターとして設定します。 たとえば、https://yourtestendpoint/?x-customer-instanceid=applicationinsightsavailability:<your guid>
のようにします。
可用性テストからの受信要求を許可するようにファイアウォールを構成する
Note
この例は、ネットワーク セキュリティ グループのサービス タグの使用に固有です。 多くの Azure サービスはサービス タグを受け入れますが、それぞれに異なる構成手順が必要です。
個々の IP を承認したり、最新の IP リストを維持したりせずに Azure サービスを簡単に有効にするには、サービス タグを使用します。 これらのタグを Azure Firewall とネットワーク セキュリティ グループの全体に適用して、可用性テスト サービスがエンドポイントにアクセスできるようにします。 サービス タグ
ApplicationInsightsAvailability
は、すべての可用性テストに適用されます。Azure ネットワーク セキュリティ グループを使用する場合は、ネットワーク セキュリティ グループ リソースに移動し、[設定] で [受信セキュリティ規則] を選択します。 その後、 [追加] を選択します。
次に、ソースとして [サービス タグ] を選択し、ソース サービス タグとして [ApplicationInsightsAvailability] を選択します。 サービス タグからの着信トラフィック用にオープン ポート 80 (http) と 443 (https) を使用します。
エンドポイントが Azure の外部にある場合、またはサービス タグがオプションではない場合にアクセスを管理するには、Web テスト エージェントの IP アドレスを許可リストに登録します。 PowerShell、Azure CLI、または Service Tag API を使用した REST 呼び出しを使用して、IP 範囲のクエリを実行できます。 現在のサービス タグとその IP の詳細の包括的な一覧については、JSON ファイルをダウンロードしてください。
ネットワーク セキュリティ グループ リソースで、[設定] の [受信セキュリティ規則] を選択します。 その後、 [追加] を選択します。
次に、ソースとして [IP アドレス] を選択します。 次に、[ソース IP アドレス/CIRD 範囲] のコンマ区切りの一覧に IP アドレスを追加します。
切断またはイングレスなしシナリオ
Azure Private Link を使用して、Application Insights リソースを内部サービス エンドポイントに接続します。
内部サーバーまたはエンドポイントを定期的にテストするカスタム コードを作成します。 コア SDK パッケージ内の TrackAvailability() API を使用して、結果を Application Insights に送信します。
サポートされる TLS 構成
クラス最高の暗号化を提供するために、すべての可用性テストでは、選択した暗号化メカニズムとしてトランスポート層セキュリティ (TLS) 1.2 および 1.3 が使用されます。 さらに、各バージョンでは、以下の暗号スイートと楕円曲線もサポートされます。
Note
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 バージョンにフォールバックさせるために、エンドポイントで TLS 1.3 を一時的に無効にすることを検討してください。
詳細については、トラブルシューティングに関する記事を参照してください。
専用のトラブルシューティングに関する記事をご覧ください。
ダウンタイム、SLA、および停止のブック
この記事では、Application Insights リソースと Azure サブスクリプションにわたる 1 つのペインで、Web テストのサービス レベル アグリーメント (SLA) を簡単に計算してレポートする方法を紹介します。 ダウンタイムと停止レポートには、顧客の接続、一般的なアプリケーションの応答時間、および発生したダウンタイムについて理解を深められるように、強力な構築済みのクエリとデータ視覚化が用意されています。
SLA ブック テンプレートには、次の 2 つの方法で Application Insights リソースからアクセスできます。
パラメーターの柔軟性
ブックに設定されているパラメーターは、レポートの残りの部分に影響します。
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 構成を検証するようにする必要があります。
Note
Web サーバーで必要な TLS 構成を有効にする手順に関して、プロセスが不明な場合は、Web サーバーが実行されているホスティング プラットフォームを所有するチームに連絡することが適切です。
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 の問題の解決」を参照してください。