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

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

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

テストを作成する

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

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 アドレス ガイドを参照してください。

成功の基準

警告

位置情報の作成タグ

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

Azure Government

Azure 中国

Azure

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

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

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

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

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

テストを調べて編集する

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

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

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

赤い点を選択します。

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

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

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

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

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

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

Automation

• PowerShell スクリプトを使用して、可用性テストを自動的に設定します。
• アラートが発生したときに呼び出される webhook を設定します。

次のステップ

• 可用性のアラート
• 複数ステップ Web テスト
• トラブルシューティング
• Azure Resource Manager テンプレートの Web テスト