Application Insights 可用性テスト

  • [アーティクル]

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

可用性テストは、パブリック インターネットからアクセスできる任意の HTTP または HTTPS エンドポイントに対して設定できます。 テストする Web サイトに対して、何らかの変更を行う必要はありません。 実際には、自分が所有しているサイトである必要もありません。 サービスが依存している REST API の可用性をテストできます。

テストの種類

重要

今後、可用性テストが 2 つ提供終了になる予定です。 2024 年 8 月 31 日、Application Insights のマルチステップ Web テストは廃止されます。 これらのテストをご利用の場合、提供終了日より前に、代替可用性テストに移行することをお勧めします。 この日付が過ぎると、基礎インフラストラクチャが撤去され、残りのマルチステップ テストが中断されます。 2026 年 9 月 30 日、Application Insights の URL ping テストは廃止されます。 既存の URL ping テストはリソースから削除されます。 標準テストの価格と、その利用への切り替えを 2026 年 9 月 30 日より前に確認して、Application Insights リソースでシングル ステップの可用性テストを引き続き実行できるようにします。

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

  • 標準テスト: この単一の要求テストは、URL ping テストに似ています。 これには、TLS/SSL 証明書の有効性、プロアクティブな有効期間チェック、HTTP 要求動詞 (GET、HEAD、または POST など)、カスタム ヘッダー、HTTP 要求に関連付けられたカスタム データが含まれます。
  • カスタム TrackAvailability テスト: 可用性テストを実行するカスタム アプリケーションを作成することにした場合、TrackAvailability() メソッドを使用して、結果を Application Insights に送信できます。
  • クラシック テスト (以前のバージョンの可用性テスト)
    • URL ping テスト (非推奨): Azure portal を通してこのテストを作成し、エンドポイントが応答しているかを検証し、その応答に関するパフォーマンスを測定できます。 また、依存する要求の解析などの高度な機能と結合されたカスタム成功基準を設定し、再試行が可能になります。
    • 複数ステップ Web テスト (非推奨): 一連の Web 要求のこの記録を再生して、より複雑なシナリオをテストできます。 複数ステップ Web テストは Visual Studio Enterprise で作成され、ポータルにアップロードされ、ここでそれらを実行できます。

重要

より古いクラシック テスト (URL の ping テストと複数ステップ Web テスト) ではどちらも、パブリック インターネットの DNS インフラストラクチャを使用して、テストされたエンドポイントのドメイン名を解決します。 プライベート DNS を使用している場合は、パブリック ドメイン ネーム サーバーがテストのすべてのドメイン名を解決できる必要があります。 それができない場合は、代わりにカスタム TrackAvailability テストを使用できます。

Application Insights リソースごとに最大 100 個の可用性テストを作成できます。

注意

可用性テストは、保存時の Azure データ暗号化ポリシーに従って暗号化されて格納されます。

TLS サポート

クラス最高の暗号化を提供するために、可用性テストはすべて、暗号化メカニズムとしてトランスポート層セキュリティ (TLS) 1.2 以上を使用します。

警告

2024 年 10 月 31 日の Azure 全体でのレガシ TLS の廃止に伴い、Application Insights の可用性テストでは、TLS 1.0/1.1 プロトコル バージョンと TLS 1.2/1.3 レガシ暗号スイートと楕円曲線が廃止されます。

サポートされる 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 日以降に廃止されるのは、以下の TLS 1.2 と TLS 1.3 のセクションに記載されている暗号スイートと楕円曲線だけです。 TLS 1.2/1.3、および「サポートされている 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

よく寄せられる質問

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

全般

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

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 の問題の解決」を参照してください。

トラブルシューティング

警告

可用性テストでは最近 TLS 1.3 が有効にされました。 結果として新しいエラー メッセージが表示される場合、TLS 1.3 を有効にしている Windows Server 2022 で実行されているクライアントがエンドポイントに接続できることを確認してください。 これができない場合、可用性テストを古い TLS バージョンにフォールバックさせるために、エンドポイントで TLS 1.3 を一時的に無効にすることを検討してください。
詳細については、トラブルシューティングに関する記事を参照してください。 専用のトラブルシューティングに関する記事をご覧ください。

次のステップ