この記事は、可用性の監視機能を使用しているときに遭遇する可能性のある一般的な問題のトラブルシューティングに役立ちます。This article will help you to troubleshoot common issues that may occur when using availability monitoring.

SSL/TLS エラーSSL/TLS errors

症状/エラー メッセージSymptom/error message 考えられる原因Possible causes
SSL/TLS のセキュリティで保護されているチャネルを作成できませんでしたCould not create SSL/TLS Secure Channel SSL のバージョン。SSL version. サポートされるのは、TLS 1.0、1.1、1.2 のみです。Only TLS 1.0, 1.1, and 1.2 are supported. SSLv3 はサポートされません。SSLv3 is not supported.
TLSv1.2 Record レイヤー: アラート (レベル: 致命的、説明: Record MAC が無効です)TLSv1.2 Record Layer: Alert (Level: Fatal, Description: Bad Record MAC) 詳細については、StackExchange スレッドを参照してください。See StackExchange thread for more information.
エラーの発生する URL が CDN (Content Delivery Network) の URLURL that is failing is to a CDN (Content Delivery Network) CDN の不適切な構成が原因である可能性があります。This may be caused by a misconfiguration on your CDN

考えられる回避策Possible workaround

  • 問題の発生する URL が常に依存リソースの URL である場合、Web テストの [従属要求の解析] は無効にすることをお勧めします。If the URLs that are experiencing the issue are always to dependent resources, it is recommended to disable parse dependent requests for the web test.

特定の場所からのみテストが失敗するTest fails only from certain locations

症状/エラー メッセージSymptom/error message 考えられる原因Possible causes
接続済みの呼び出し先が一定の時間を過ぎても正しく応答しなかったため、接続できませんでしたA connection attempt failed because the connected party did not properly respond after a period of time 特定の場所のテスト エージェントがファイアウォールによってブロックされています。Test agents in certain locations are being blocked by a firewall.
Load Balancer、Geo Traffic Manager、Azure Express Route を介して特定の IP アドレスの再ルーティングが生じています。Rerouting of certain IP addresses is occurring via (Load Balancers, Geo traffic managers, Azure Express Route.)
Azure ExpressRoute を使用している場合、非対称ルーティングが発生してパケットがドロップしている状況が考えられます。If using Azure ExpressRoute, there are scenarios where packets can be dropped in cases where Asymmetric Routing occurs.

プロトコル違反エラーでのテスト失敗Test failure with a protocol violation error

症状/エラー メッセージSymptom/error message 考えられる原因Possible causes 考えられる解決策Possible Resolutions
サーバーによってプロトコル違反が発生しました。The server committed a protocol violation. Section=ResponseHeader Detail=CR の後には LF を指定しなければなりませんSection=ResponseHeader Detail=CR must be followed by LF これは、形式に誤りのあるヘッダーが検出されたときに発生します。This occurs when malformed headers are detected. 具体的には、行末の指定で CRLF を使用していないヘッダーがあり、これは HTTP 仕様に違反しています。Specifically, some headers might not be using CRLF to indicate the end of line, which violates the HTTP specification. Application Insights では、この HTTP 仕様が適用され、形式が正しくないヘッダーを持つ応答は失敗します。Application Insights enforces this HTTP specification and fails responses with malformed headers. a.a. Web サイト ホスト プロバイダー/CDN プロバイダーに問い合わせて、問題のあるサーバーを修正してください。Contact web site host provider / CDN provider to fix the faulty servers.
b.b. 失敗した要求がリソース (スタイル ファイル、イメージ、スクリプトなど) である場合は、依存する要求の解析を無効にすることを検討してください。In case the failed requests are resources (e.g. style files, images, scripts), you may consider disabling the parsing of dependent requests. これを行うと、それらのファイルの可用性を監視できなくなることに注意してください。Keep in mind, if you do this you will lose the ability to monitor the availability of those files).


HTTP ヘッダーの緩和された検証を行うブラウザーでは、URL は 失敗しない場合があります。The URL may not fail on browsers that have a relaxed validation of HTTP headers. この問題の詳細については、こちらのブログ記事を参照してください: http://mehdi.me/a-tale-of-debugging-the-linkedin-api-net-and-http-protocol-violations/See this blog post for a detailed explanation of this issue: http://mehdi.me/a-tale-of-debugging-the-linkedin-api-net-and-http-protocol-violations/

一般的なトラブルシューティングの質問Common troubleshooting questions

サイトには問題がないように見えますがテストが失敗します。Site looks okay but I see test failures? Application Insights からアラートが通知されるのはどうしてですか。Why is Application Insights alerting me?

  • ご利用のテストでは [依存する要求の解析] が有効になっていますか。Does your test have Parse dependent requests enabled? それが有効になっていると、スクリプトやイメージなどのリソースに対して厳密なチェックが行われます。ブラウザー上で、この種のエラーはわかりにくい場合があります。That results in a strict check on resources such as scripts, images etc. These types of failures may not be noticeable on a browser. イメージ、スクリプト、スタイル シート、およびページによって読み込まれるその他のファイルすべてを確認してください。Check all the images, scripts, style sheets, and any other files loaded by the page. これらのいずれかにエラーがある場合、メインの HTML ページの読み込みに問題がない場合でも、テストはエラーとしてレポートされます。If any of them fails, the test is reported as failed, even if the main HTML page loads without issue. このようなリソース エラーをテストで検出しないようにするには、テスト構成で [依存する要求の解析] をオフにするだけです。To desensitize the test to such resource failures, simply uncheck the Parse Dependent Requests from the test configuration.

  • ネットワークの一時的な問題によるノイズの可能性を減らすには、[Enable retries for test failures](テストが失敗した場合に再試行を有効にする) 構成がオンになっていることを確認します。To reduce odds of noise from transient network blips etc., ensure Enable retries for test failures configuration is checked. 複数の場所からテストを行い、アラート ルールのしきい値を適宜管理して、過度のアラートの原因となっている場所固有の問題を防ぐこともできます。You can also test from more locations and manage alert rule threshold accordingly to prevent location-specific issues causing undue alerts.

  • 可用性エクスペリエンスで赤い点のいずれかをクリックするか、または Search エクスプローラーで任意の可用性エラーをクリックすると、エラーが報告された理由の詳細が表示されます。Click on any of the red dots from the Availability experience, or any availability failure from the Search explorer to see the details of why we reported the failure. テスト結果に加えて、サーバー側の相関関係を持つテレメトリ (有効になっている場合) は、テストが失敗した理由を理解するのに役立つはずです。The test result, along with the correlated server-side telemetry (if enabled) should help understand why the test failed. 一時的な問題が発生する原因は、一般にネットワークまたは接続の問題にあります。Common causes of transient issues are network or connection issues.

  • テストがタイムアウトになりましたか。Did the test time-out? 2 分後にテストを中止します。We abort tests after 2 minutes. ping または複数手順のテストが 2 分を経過しても完了しない場合は、エラーとして報告されます。If your ping or multi-step test takes longer than 2 minutes, we will report it as a failure. より短い時間で完了するようにテストを複数のテストに分割することを検討してください。Consider breaking the test into multiple ones that can complete in shorter durations.

  • すべての場所でエラーが報告されましたか、それとも一部の場所でのみエラーが報告されましたか。Did all locations report failure, or only some of them? 一部の場所でのみエラーが報告された場合は、ネットワーク/CDN の問題が原因です。If only some reported failures, it may be due to network/CDN issues. 繰り返しになりますが、赤色のドットをクリックすると、その場所でエラーが報告された理由を理解するのに役立つ情報が表示されます。Again, clicking on the red dots should help understand why the location reported failures.

アラートがトリガーされたとき、もしくは解決されたとき、あるいはその両方で、電子メールが届きませんでした。I did not get an email when the alert triggered, or resolved or both?

クラシック アラート構成を調べて、目的の電子メールが直接リストされること、または表示している配布リストが通知を受信するように構成されていることを確認します。Check the classic alerts configuration to confirm your email is directly listed, or a distribution list you are on is configured to receive notifications. そのようになっている場合は、配布リストの構成を調べて、外部の電子メールを受信できるように構成されていることを確認します。If it is, then check the distribution list configuration to confirm it can receive external emails. また、メール管理者が所有するポリシーがこの問題を引き起こす可能性のある構成になっていないか確認します。Also check if your mail administrator may have any policies configured that may cause this issue.

Webhook 通知が届きませんでした。I did not receive the webhook notification?

Web hook 通知を受信するアプリケーションが利用可能であること、さらにそのアプリケーションによって Web hook 要求が適切に処理されることを確認します。Check to ensure the application receiving the webhook notification is available, and successfully processes the webhook requests. 詳細については、こちらをご覧ください。See this for more information.

プロトコル違反エラーでテストが断続的に失敗します。Intermittent test failure with a protocol violation error?

エラー ("プロトコル違反..CR の後には LF を指定しなければなりません") は、サーバー (または依存関係) に問題があることを示しています。The error ("protocol violation..CR must be followed by LF") indicates an issue with the server (or dependencies). これは、応答に形式が正しくないヘッダーが設定されている場合に発生します。This happens when malformed headers are set in the response. ロード バランサーまたは CDN が原因である可能性があります。It can be caused by load balancers or CDNs. 具体的には、行末の指定で CRLF を使用していないヘッダーがあります。これは HTTP 仕様に違反しているため、.NET WebRequest レベルで失敗します。Specifically, some headers might not be using CRLF to indicate end of line, which violates the HTTP specification and therefore fail validation at the .NET WebRequest level. 応答を検査して、違反の可能性のあるヘッダーを見つけます。Inspect the response to spot headers, which might be in violation.


HTTP ヘッダーの緩和された検証を行うブラウザーでは、URL は 失敗しない場合があります。The URL may not fail on browsers that have a relaxed validation of HTTP headers. この問題の詳細については、こちらのブログ記事を参照してください: http://mehdi.me/a-tale-of-debugging-the-linkedin-api-net-and-http-protocol-violations/See this blog post for a detailed explanation of this issue: http://mehdi.me/a-tale-of-debugging-the-linkedin-api-net-and-http-protocol-violations/

サーバー側のアプリケーションに対して Application Insights を設定している場合は、サンプリング操作中のためである可能性があります。If you have Application Insights set up for your server-side application, that may be because sampling is in operation. 別の可用性の結果を選択します。Select a different availability result.

Web テストからコードを呼び出すことはできますか。Can I call code from my web test?

No.No. テストの手順は、.webtest ファイルに含まれている必要があります。The steps of the test must be in the .webtest file. 他の Web テストの呼び出しまたはループの使用は許可されていません。And you can't call other web tests or use loops. ただし、役に立つさまざまなプラグインがあります。But there are several plug-ins that you might find helpful.

"Web テスト" と "可用性テスト" に違いはありますか。Is there a difference between "web tests" and "availability tests"?

この 2 つの用語は、同じ意味で参照されることがあります。The two terms may be referenced interchangeably. 可用性テストは、複数ステップから成る Web テストに加えて単一の URL Ping テストも含む、より一般的な用語です。Availability tests is a more generic term that includes the single URL ping tests in addition to the multi-step web tests.

ファイアウォールの内側で稼働している内部サーバーに対して可用性テストを使用したいと考えています。I'd like to use availability tests on our internal server that runs behind a firewall.

解決策として、次の 2 つが考えられます。There are two possible solutions:

  • Web テスト エージェントの IP アドレスからの受信要求を許可するようにファイアウォールを構成します。Configure your firewall to permit incoming requests from the IP addresses of our web test agents.
  • 内部サーバーを定期的にテストする独自のコードを作成します。Write your own code to periodically test your internal server. このコードを、バック グラウンド プロセスとして、ファイアウォールの内側のテスト サーバーで実行します。Run the code as a background process on a test server behind your firewall. テスト プロセスは、コア SDK パッケージ内の TrackAvailability() API を使用して、その結果を Application Insights に送信できます。Your test process can send its results to Application Insights by using TrackAvailability() API in the core SDK package. この方法では、テスト サーバーに Application Insights のインジェスト エンドポイントへの送信アクセスが必要となりますが、受信要求を許可する代替方法と比べて、セキュリティのリスクは大幅に小さくなります。This requires your test server to have outgoing access to the Application Insights ingestion endpoint, but that is a much smaller security risk than the alternative of permitting incoming requests. 結果は可用性 Web テストブレードに表示されますが、エクスペリエンスはポータルによって作成されたテストに対して使用できるものより少し簡単になります。The results will appear in the availability web tests blades though the experience will be slightly simplified from what is available for tests created via the portal. カスタム可用性テストは、分析、検索、およびメトリックにも可用性の結果として表示されます。Custom availability tests will also appear as availability results in Analytics, Search, and Metrics.

複数ステップの Web テストのアップロードが失敗します。Uploading a multi-step web test fails

これを引き起こす可能性があるいくつかの原因:Some reasons this might happen:

  • 300 K のサイズ制限があります。There's a size limit of 300 K.
  • ループはサポートされていません。Loops aren't supported.
  • 他の Web テストへの参照はサポートされていません。References to other web tests aren't supported.
  • データ ソースはサポートされていません。Data sources aren't supported.

複数ステップのテストが完了しません。My multi-step test doesn't complete

1 テストあたりの要求は 100 個に制限されています。There's a limit of 100 requests per test. また、実行時間が 2 分を超えると、テストは停止します。Also, the test is stopped if it runs longer than two minutes.

クライアント証明書でテストを実行するにはどうすればよいですか。How can I run a test with client certificates?

現在これはサポートされていません。This is currently not supported.

(クラシック) アラート通知は誰が受け取りますか。Who receives the (classic) alert notifications?

このセクションは、クラシック アラートにのみ適用され、目的の受信者だけが通知を受け取るように、アラート通知を最適化するために役立ちます。This section only applies to classic alerts and will help you optimize your alert notifications to ensure that only your desired recipients receive notifications. クラシック アラートと新しいアラート エクスペリエンスの違いの詳細については、アラートの概要の記事を参照してください。To understand more about the difference between classic alertsand the new alerts experience refer to the alerts overview article. 新しいアラート エクスペリエンスのアラート通知を制御するには、アクション グループを使用します。To control alert notification in the new alerts experience use action groups.

  • クラシック アラート通知には、特定の受信者の使用をお勧めします。We recommend the use of specific recipients for classic alert notifications.

  • Y のうち X の場所からのエラーに関するアラートの場合、一括/グループ チェックボックス オプションが有効にされていれば、管理者/共同管理者ロールを持つユーザーに送信されます。For alerts on failures from X out of Y locations, the bulk/group check-box option, if enabled, sends to users with admin/co-admin roles. 本質的に、_サブスクリプション_の_すべて_の管理者が通知を受け取ります。Essentially all administrators of the subscription will receive notifications.

  • 可用性のメトリックに関するアラートの場合、一括/グループ チェックボックス オプションが有効にされていれば、サブスクリプション内の所有者、共同作成者、または閲覧者ロールを持つユーザーに送信されます。For alerts on availability metrics the bulk/group check-box option if enabled, sends to users with owner, contributor, or reader roles in the subscription. 実際には、サブスクリプションの Application Insights リソースにアクセスできる すべて のユーザーが範囲内になり、通知を受け取ります。In effect, all users with access to the subscription the Application Insights resource are in scope and will receive notifications.


現在、一括/グループ チェックボックス オプションを使用しており、それを無効にすると、変更を元に戻すことはできません。If you currently use the bulk/group check-box option, and disable it, you will not be able to revert the change.

ロールに基づいてユーザーに通知する必要がある場合は、新しいアラート エクスペリエンス/準リアルタイム アラートを使用します。Use the new alert experience/near-realtime alerts if you need to notify users based on their roles. アクション グループを使用して、共同作成者/所有者/閲覧者のいずれかのロール (1 つのオプションとして組み合わされていない) を持つユーザーに対し、電子メール通知を構成することができます。With action groups, you can configure email notifications to users with any of the contributor/owner/reader roles (not combined together as a single option).

次の手順Next steps