任意の Web サイトの可用性を監視するMonitor the availability of any website

お使いの Web アプリ/Web サイトをデプロイした後、繰り返されるテストを設定して、可用性と応答性を監視できます。After you've deployed your web app/website, you can set up recurring tests to monitor availability and responsiveness. Application Insights は、世界各地の複数のポイントから定期的にアプリケーションに Web 要求を送信します。Azure Application Insights sends web requests to your application at regular intervals from points around the world. お使いのアプリケーションが応答していない場合、または応答が遅すぎる場合は、アラートを受信できます。It can alert you if your application isn't responding, or if it responds too slowly.

可用性テストは、パブリック インターネットからアクセスできる任意の HTTP または HTTPS エンドポイントに対して設定できます。You can set up availability tests for any HTTP or HTTPS endpoint that is accessible from the public internet. テストする Web サイトに対して、何らかの変更を行う必要はありません。You don't have to make any changes to the website you're testing. 実際には、自分が所有しているサイトである必要もありません。In fact, it doesn't even have to be a site you own. サービスが依存している REST API の可用性をテストできます。You can test the availability of a REST API that your service depends on.

可用性テストの種類:Types of availability tests:

可用性テストには、次の 3 種類があります。There are three types of availability tests:

  • URL の Ping テスト: Azure Portal で作成できる簡単なテストです。URL ping test: a simple test that you can create in the Azure portal.
  • 複数ステップ Web テスト:一連の Web 要求の記録であり、さらに複雑なシナリオをテストするために再生できます。Multi-step web test: A recording of a sequence of web requests, which can be played back to test more complex scenarios. 複数ステップ Web テストは Visual Studio Enterprise で作成され、ポータルにアップロードされて実行されます。Multi-step web tests are created in Visual Studio Enterprise and uploaded to the portal for execution.
  • カスタム可用性追跡テスト:可用性テストを実行するカスタム アプリケーションを作成する場合は、TrackAvailability() メソッドを使用して Application Insights に結果を送信できます。Custom Track Availability Tests: If you decide to create a custom application to run availability tests, the TrackAvailability() method can be used to send the results to Application Insights.

Application Insights リソースごとに最大 100 個の可用性テストを作成できます。You can create up to 100 availability tests per Application Insights resource.

Application Insights リソースの作成Create an Application Insights resource

可用性テストを作成するためには、まず、Application Insights リソースを作成する必要があります。In order to create an availability test, you first need to create an Application Insights resource. リソースが既に作成されている場合は、次のセクションに進んで URL Ping テストを作成します。If you have already created a resource, proceed to the next section to create a URL Ping test.

Azure portal で、 [リソースの作成] > [開発者ツール] > [Application Insights] を選択し、Application Insights リソースを作成します。From the Azure portal, select Create a resource > Developer Tools > Application Insights and create an Application Insights resource.

URL の Ping テストを作成するCreate a URL ping test

"URL ping テスト" という名前は、少し間違っています。The name "URL ping test" is a bit of a misnomer. 誤解のないように言うと、このテストでは、サイトの可用性をチェックするために ICMP (インターネット制御メッセージ プロトコル) は使用されません。To be clear, this test is not making any use of ICMP (Internet Control Message Protocol) to check your site's availability. 代わりに、より高度な HTTP 要求機能を使用して、エンドポイントが応答しているかどうかが検証されます。Instead it uses more advanced HTTP request functionality to validate whether an endpoint is responding. さらに、その応答に関連付けられているパフォーマンスが測定され、依存する要求の解析などの高度な機能と結合されたカスタム成功基準を設定する機能が追加されて、再試行が可能になります。It also measures the performance associated with that response, and adds the ability to set custom success criteria coupled with more advanced features like parsing dependent requests, and allowing for retries.

最初の可用性要求を作成するには、[可用性] ウィンドウを開いて、 [テストの作成] を選択します。To create your first availability request, open the Availability pane and select Create Test.

少なくとも自分の Web サイトの URL を入力

テストを作成するCreate a test

SettingSetting 説明Explanation
URLURL [URL] にはテストする任意の Web ページを指定できますが、パブリック インターネットからアクセス可能である必要があります。The URL can be any web page you want to test, but it must be visible from the public internet. URL にはクエリ文字列を含めることができます。The URL can include a query string. したがって、たとえば限られた範囲でデータベースを実行できます。So, for example, you can exercise your database a little. URL が解決されてリダイレクトする場合、それに続いて最大で 10 個リダイレクトを使用できます。If the URL resolves to a redirect, we follow it up to 10 redirects.
依存する要求の解析Parse dependent requests テストでは、テスト対象の Web ページの一部である画像、スクリプト、スタイル ファイル、およびその他のファイルが要求されます。Test requests images, scripts, style files, and other files that are part of the web page under test. 記録される応答時間には、これらのファイルの取得にかかる時間が含まれます。The recorded response time includes the time taken to get these files. テスト全体のタイムアウト時間内にこれらすべてのリソースを正常にダウンロードできない場合、テストは失敗します。The test fails if any of these resources cannot be successfully downloaded within the timeout for the whole test. このオプションがオンになっていない場合、テストからは指定した URL にあるファイルのみが要求されます。If the option is not checked, the test only requests the file at the URL you specified. このオプションを有効にすると、より厳密なチェックが行われます。Enabling this option results in a stricter check. サイトを手動で参照しているときは気付かないことが原因でテストが失敗する場合があります。The test could fail for cases, which may not be noticeable when manually browsing the site.
再試行を有効にするEnable retries テストが失敗した場合に、少し間を置いてテストを再試行します。when the test fails, it is retried after a short interval. エラーは試行が 3 回連続で失敗した場合にのみ報告されます。A failure is reported only if three successive attempts fail. その後、後続のテストが通常のテスト間隔で実行されます。Subsequent tests are then performed at the usual test frequency. 再試行は、次の成功まで一時的に中断されます。Retry is temporarily suspended until the next success. このルールがテスト場所ごとに独立して適用されます。This rule is applied independently at each test location. このオプションはオンにすることをお勧めしますWe recommend this option. 再試行の際に平均でエラーの約 80% がなくなります。On average, about 80% of failures disappear on retry.
テスト間隔Test frequency 各テストの場所からテストを実行する頻度を設定します。Sets how often the test is run from each test location. 既定の間隔が 5 分で、テストの場所が 5 か所の場合、サイトは平均して毎分テストされます。With a default frequency of five minutes and five test locations, your site is tested on average every minute.
テストの場所Test locations 指定の URL にサーバーによって Web 要求が送信される送信元の場所です。Are the places from where our servers send web requests to your URL. Web サイトの問題とネットワークの問題とを確実に区別するために、最低でもテストの場所を 5 か所にすることが推奨されますOur minimum number of recommended test locations is five in order to insure that you can distinguish problems in your website from network issues. 最大 16 個の場所を選択できます。You can select up to 16 locations.

パブリック インターネットから指定の URL にアクセスできない場合は、テスト トランザクションのみが通過できるようにお使いのファイアウォールを選択的に開くことを選択できますIf your URL is not visible from the public internet, you can choose to selectively open up your firewall to allow only the test transactions through. 可用性テスト エージェント用のファイアウォールの例外について詳しくは、IP アドレス ガイドを参照してください。To learn more about the firewall exceptions for our availability test agents, consult the IP address guide.


複数の場所 (少なくとも 5 か所) からテストを行うことを強くお勧めします。We strongly recommend testing from multiple locations with a minimum of five locations. これにより、特定の場所での一時的な問題による誤検知を防止します。This is to prevent false alarms that may result from transient issues with a specific location. さらに、テストの場所の数をアラートの場所のしきい値 + 2 にすると最適な構成になることがわかっています。In addition we have found that the optimal configuration is to have the number of test locations be equal to the alert location threshold + 2.

成功の基準Success criteria

SettingSetting 説明Explanation
テストのタイムアウトTest timeout この値を引き下げると、応答が遅い場合に警告されます。Decrease this value to be alerted about slow responses. テストは、この期間内にサイトから応答が返されない場合に、エラーとしてカウントされます。The test is counted as a failure if the responses from your site have not been received within this period. [従属要求の解析] をオンにした場合、すべての画像、スタイル ファイル、スクリプト、その他依存するリソースがこの期間内に受信される必要があります。If you selected Parse dependent requests, then all the images, style files, scripts, and other dependent resources must have been received within this period.
HTTP 応答HTTP response 成功としてカウントされる、返される状態コード。The returned status code that is counted as a success. 200 は、通常の Web ページが返されたことを示すコードです。200 is the code that indicates that a normal web page has been returned.
コンテンツの一致Content match "Welcome!" などの文字列。A string, like "Welcome!" それぞれの応答に大文字小文字を区別した完全一致があるかどうかをテストします。We test that an exact case-sensitive match occurs in every response. 文字列は、(ワイルドカードを含まない) プレーン文字列である必要があります。It must be a plain string, without wildcards. ページ コンテンツが変更された場合は、この文字列も更新する必要がある可能性があることに注意してください。Don't forget that if your page content changes you might have to update it. コンテンツの一致では、英語のみがサポートされています。Only English characters are supported with content match


SettingSetting 説明Explanation
準リアルタイム (プレビュー)Near-realtime (Preview) 準リアルタイムのアラートを使用することが推奨されます。We recommend using Near-realtime alerts. この種類のアラートの構成は、可用性テストの作成後に実行されます。Configuring this type of alert is done after your availability test is created.
クラシックClassic 新しい可用性テストでクラシック アラートを使用することはもう推奨されていません。We no longer recommended using classic alerts for new availability tests.
アラートの場所のしきい値Alert location threshold 少なくとも 3/5 の場所にすることをお勧めします。We recommend a minimum of 3/5 locations. アラートの場所のしきい値とテストの場所の数の最適な関係は、アラートの場所のしきい値 = テストの場所の数 - 2 です。テストの場所は、少なくとも 5 か所にします。The optimal relationship between alert location threshold and the number of test locations is alert location threshold = number of test locations - 2, with a minimum of five test locations.

可用性テストの結果を表示するSee your availability test results

可用性テストの結果は、折れ線グラフと散布図の両方で視覚化できます。Availability test results can be visualized with both line and scatter plot views.

数分後に、 [更新] をクリックすると、テスト結果が表示されます。After a few minutes, click Refresh to see your test results.


散布図には、診断テスト手順の詳細が含まれたテスト結果のサンプルが表示されます。The scatterplot view shows samples of the test results that have diagnostic test-step detail in them. テスト エンジンは、失敗したテストの診断の詳細を格納します。The test engine stores diagnostic detail for tests that have failures. 成功したテストの場合、診断の詳細は実行のサブセットに対して格納されます。For successful tests, diagnostic details are stored for a subset of the executions. 緑色/赤色の点の上にポインターを置くと、テスト、テスト名、および場所が表示されます。Hover over any of the green/red dots to see the test, test name, and location.


特定のテスト、場所を選択するか、または期間を短くすると、目的の期間に関するより詳細な結果が表示されます。Select a particular test, location, or reduce the time period to see more results around the time period of interest. Search エクスプローラーを使用してすべての実行の結果を表示するか、または分析クエリを使用してこのデータに対してカスタム レポートを実行します。Use Search Explorer to see results from all executions, or use Analytics queries to run custom reports on this data.

テストを調べて編集するInspect and edit tests

テストの編集、一時的な無効化、または削除を行うには、テスト名の横の省略記号をクリックします。To edit, temporarily disable, or delete a test click the ellipses next to a test name. 変更を行った後、すべてのテスト エージェントに構成の変更が反映されるまで、最大 20 分かかる可能性があります。It may take up to 20 minutes for configuration changes to propagate to all test agents after a change is made.


サービスに対するメンテナンスを実行している間、関連付けられた可用性テストまたはアラート ルールを無効にすることもできます。You might want to disable availability tests or the alert rules associated with them while you are performing maintenance on your service.

エラーが発生した場合If you see failures

赤い点をクリックします。Click a red dot.


可用性のテスト結果から、すべてのコンポーネントにわたるトランザクションの詳細を確認できます。From an availability test result, you can see the transaction details across all components. ここで、次のことを行うことができます。Here you can:

  • サーバーから受信した応答を調べる。Inspect the response received from your server.
  • 失敗した可用性テストの処理中に収集された、サーバー側の相関関係を持つテレメトリを使用してエラーを診断する。Diagnose failure with correlated server-side telemetry collected while processing the failed availability test.
  • 懸案や作業の項目を Git または Azure Boards に記録して問題を追跡する。Log an issue or work item in Git or Azure Boards to track the problem. バグには、このイベントへのリンクが含まれます。The bug will contain a link to this event.
  • Visual Studio で Web テスト結果を開く。Open the web test result in Visual Studio.

エンドツーエンドのトランザクションの診断エクスペリエンスの詳細については、こちらを参照してください。Learn more about the end to end transaction diagnostics experience here.

例外の行をクリックすると、代理可用性テストが失敗した原因であるサーバー側の例外の詳細が表示されます。Click on the exception row to see the details of the server-side exception that caused the synthetic availability test to fail. コード レベルの豊富な診断の デバッグ スナップショットを取得することもできます。You can also get the debug snapshot for richer code level diagnostics.


生の結果に加えて、メトリックス エクスプローラーに 2 つの重要な可用性メトリックを表示することもできます。In addition to the raw results, you can also view two key Availability metrics in Metrics Explorer:

  1. 可用性:すべてのテスト実行にわたる、成功したテストの割合 (%)。Availability: Percentage of the tests that were successful, across all test executions.
  2. テスト期間:すべてのテスト実行にわたる平均のテスト期間。Test Duration: Average test duration across all test executions.



専用のトラブルシューティングに関する記事をご覧ください。Dedicated troubleshooting article.

次の手順Next steps