次の方法で共有

URL ping テストを使用して可用性を監視する

  • [アーティクル]

"URL ping テスト" という名前は、少し間違っています。 これらのテストでは、インターネット制御メッセージ プロトコル (ICMP) を使用して、お使いのサイトの可用性を確認することはありません。 代わりに、より高度な HTTP 要求機能を使用して、エンドポイントが応答しているかどうかが検証されます。 その応答に関連付けられているパフォーマンスが測定されるほか、 依存する要求の解析などの高度な機能と結合されたカスタム成功基準を設定する機能も追加され、再試行が可能になります。

可用性テストを作成するには、既存の Application insights リソースを使用するか、Application Insights リソースを作成する必要があります。

重要

2026 年 9 月 30 日に、 URL ping テストは廃止されます。 それまでに、標準テストに移行してください。

  • コストは、標準テストの実行に関連付けられます。 標準テストを作成すると、テストの実行に対して課金されます。
  • このプロセスを開始する前に、Azure Monitor の価格に関するページを参照してください。

Note

URL の ping テストは、クラシック テストとして分類されます。 これは、 [可用性] ウィンドウ上の [Add Classic Test](クラシック テストの追加) の下にあります。 高度な機能の詳細については、「標準テスト」をご覧ください。

重要

URL ping テスト は、パブリック インターネットの DNS インフラストラクチャに依存して、テスト対象のエンドポイントのドメイン名を解決します。 プライベート DNS を使用している場合は、パブリック ドメイン ネーム サーバーがテストのすべてのドメイン名を解決できる必要があります。 これが可能ではない場合は、代わりにカスタム TrackAvailability テストを使用できます。

テストを作成する

最初の可用性要求を作成するには:

  1. ご自身の Application Insights リソース内で [可用性] ウィンドウを開き、[Add Classic Test](クラシック テストの追加) を選択します。

    [可用性] ウィンドウと、クラシック テストを追加するためのボタンを示すスクリーンショット。

  2. ご自身のテストに名前を付けて、SKU に URL ping を選択します。

  3. テストする URL を入力します。

  4. 次の表を使用し、ニーズに合わせて設定を調整します。 ［作成］ を選択します

    設定 説明
    URL [URL] にはテストする任意の Web ページを指定できますが、パブリック インターネットからアクセス可能である必要があります。 URL にはクエリ文字列を含めることができます。 たとえば、限られた範囲でデータベースを実行できます。 URL がリダイレクトに解決される場合は、最大 10 個のリダイレクトを使用できます。
    依存する要求の解析 テストでは、テスト対象の Web ページの一部である画像、スクリプト、スタイル ファイル、およびその他のファイルが要求されます。 記録される応答時間には、これらのファイルの取得にかかる時間が含まれます。 テスト全体のタイムアウト時間内にこれらすべてのリソースを正常にダウンロードできない場合、テストは失敗します。 このオプションが有効になっていない場合、テストによって要求されるのは、指定した URL にあるファイルのみになります。 このオプションを有効にすると、より厳密なチェックが行われます。 サイトを手動で参照しているときは気付かないことが原因でテストが失敗する場合があります。
    再試行を有効にする テストが失敗した場合に、少し間を置いてテストを再試行します。 エラーは試行が 3 回連続で失敗した場合にのみ報告されます。 その後、後続のテストが通常のテスト間隔で実行されます。 再試行は、次の成功まで一時的に中断されます。 このルールがテスト場所ごとに独立して適用されます。 このオプションはオンにすることをお勧めします。 再試行時に平均でエラーの約 80% がなくなります。
    [テスト間隔] この設定により、各テストの場所からテストを実行する頻度が決まります。 既定の間隔が 5 分で、テストの場所が 5 か所の場合、サイトは平均で毎分テストされます。
    テストの場所 この設定の値が示す場所から、サーバーによって、ご自身の URL に Web 要求が送信されます。 Web サイト内の問題とネットワークの問題を確実に区別できるように、テストの場所は 5 か所以上にすることをお勧めします。 最大 16 個の場所を選択できます。

ご自身の URL がパブリック インターネットから見えない場合は、テスト トランザクションのみが通過できるように、お使いのファイアウォールを選択的に開くことを選択できます。 可用性テスト エージェント用のファイアウォールの例外について詳しくは、IP アドレス ガイドを参照してください。

Note

複数の場所 (少なくとも 5 か所) からテストを行うことを強くお勧めします。 このアプローチは、特定の場所での一時的な問題による誤検知を防止するのに役立ちます。 また、テストの場所の数をアラートの場所のしきい値 + 2 にすると、最適な構成になることもわかりました。

成功の基準

設定 説明
テストのタイムアウト この値を引き下げると、応答が遅い場合に警告されます。 テストは、この期間内にサイトから応答が返されない場合に、エラーとしてカウントされます。 [従属要求の解析] をオンにした場合、すべての画像、スタイル ファイル、スクリプト、その他依存するリソースがこの期間内に受信される必要があります。
HTTP 応答 成功としてカウントされる、返される状態コード。 通常の Web ページが返されたことを示すコードは 200 です。
[内容検索] それぞれの応答内に、大文字と小文字を区別した文字列の完全一致があるかどうかをテストします。 文字列は、ワイルドカードを含まないプレーン文字列である必要があります ("Welcome!" など)。 ページ コンテンツが変更された場合は、この文字列の更新が必要になる可能性があることに注意してください。 コンテンツの一致では、英語のみがサポートされています。

警告

設定 説明
ほぼリアルタイム (プレビュー) 準リアルタイムで動作するアラートを使用することをお勧めします。 この種類のアラートは、ご自身の可用性テストを作成した後に構成します。
アラートの場所のしきい値 アラートの場所のしきい値とテストの場所の数の最適な関係は、アラートの場所のしきい値 = テストの場所の数 - 2 です。テストの場所は 5 か所以上にします。

位置情報の作成タグ

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

Azure Government

表示名 作成名
USGov バージニア州 usgov-va-azr
USGov アリゾナ usgov-phx-azr
USGov テキサス usgov-tx-azr
USDoD 東部 usgov-ddeast-azr
USDoD 中部 usgov-ddcentral-azr

Azure 中国

表示名 作成名
中国東部 mc-cne-azr
中国東部 2 mc-cne2-azr
中国北部 mc-cnn-azr
中国北部 2 mc-cnn2-azr

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

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

可用性テストの結果は、折れ線グラフと散布図の両方で視覚化できます。

数分後に、 [更新] を選択すると、テスト結果が表示されます。

[更新] ボタンが強調表示されている [可用性] ページを示すスクリーンショット。

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

折れ線グラフを示すスクリーンショット。

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

テストを調べて編集する

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

テストの詳細と、テストの編集オプションおよび無効化オプションを示すスクリーンショット。

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

エラーが発生した場合のアクション

赤い点を選択します。

エンドツーエンドのトランザクション詳細のタブを示すスクリーンショット。

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

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

エンドツーエンドのトランザクション診断の詳細については、トランザクション診断のドキュメントをご覧ください。

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

サーバー側の診断を示すスクリーンショット。

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

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

Automation

次のステップ