Application Insights で可用性テストの失敗を診断する
この記事では、Application Insights のトラブルシューティング レポートにアクセスする方法について説明します。 このレポートを使用すると、可用性テストが失敗する原因となる一般的な問題を簡単に診断できます。
Note
Web テスト関連の多くの問題は、古い DNS レコードまたは古い DNS レコードによって発生します。 最初のトラブルシューティング手順として、ローカル コンピューターで DNS キャッシュをフラッシュすることをお勧めします。
Windows で、 ipconfig /flushdns コマンドを実行します。 その他のオペレーティング システムでは、同等のコマンドが異なります。
Application Insights のトラブルシューティング レポートを表示する
Application Insights のトラブルシューティング レポートを表示するには、次の手順に従います。
Application Insights リソースの Availability ページで、 可用性テストの選択 見出しを見つけます。 その見出しの下で、個々の可用性テストの名前を選択するか、 Overall を選択して、すべてのテスト名の結合された結果を表示します。
以下のいずれかのアクションを実行します:
テスト名の [ Availability results ] ウィンドウで、 Drill into 見出しを見つけて、[ Failed ] ボタンを選択します。 次に、 可用性テストのサンプルの ペインで、テスト名のテスト実行 (特定のリージョンと時間を表す) を選択します。
Availability グラフで、Scatter Plot ビューを選択し、散布図グラフ上のいずれかのポイントを選択します。
エンド ツー エンドのトランザクションの詳細 ページで、イベントを選択し、Availability Properties テーブル内の任意の場所を選択して、レポートの概要 セクションを開きます。
レポートの概要セクションで、関連するエラー名を見つけて、そのアイテムの [ステップ先リンクを選択して、トラブルシューティング レポート詳細を表示します。
トラブルシューティング レポートを使用して、障害の原因を特定する
次の表に、レポートで見つかる可能性のある手順、エラー メッセージ、考えられる原因を示します。
| Step | エラー メッセージ | 考えられる原因 |
|---|---|---|
| 接続の再利用 | この問題に関する特定のエラー メッセージは返されません。 | Web テスト ステップは、以前に確立された接続に依存します。 そのため、DNS、接続、または SSL の手順は必要ありません。 |
| DNS 解決 | リモート名を解決できませんでした: "<our-URL>" | DNS 解決プロセスが失敗します。 これは、DNS レコードが正しく構成されていないか、DNS サーバーの一時的なエラーが原因で発生した可能性が最も高いです。 |
| 接続の確立 | 接続済みの呼び出し先が一定の時間を過ぎても正しく応答しなかったため、接続の試みが失敗しました。 | サーバーが HTTP 要求に応答しません。 一般的な原因は、サーバー上のファイアウォールがテスト エージェントをブロックしていることです。 Azure Virtual Network 内でテストするには、可用性サービス タグを環境に追加します。 |
| TLS トランスポート | クライアントとサーバーは共通のアルゴリズムを保持していないため通信できません。 | サポートされるのは、TLS 1.0、1.1、1.2 のみです。 SSL はサポートされていません。 この手順では、SSL 証明書は検証されません。セキュリティで保護された接続のみが確立されます。 この手順は、エラーが発生した場合にのみ表示されます。 |
| 受信応答ヘッダー | データをトランスポート接続から読み取れません。 接続はクローズされました。 | サーバーが応答ヘッダーでプロトコル エラーをコミットします。 たとえば、応答が完全に読み取られていない場合、サーバーは接続を閉じます。 |
| 受信応答本文 | 転送接続からデータを読み取ることができません: 接続は閉じられました。 | サーバーが応答本文でプロトコル エラーをコミットします。 たとえば、応答が完全に読み取られていない場合や、チャンクされた応答本文でチャンク サイズが間違っている場合、サーバーは接続を閉じます。 |
| リダイレクト制限検証 | この Web ページのリダイレクト数が多すぎます。 この要求が自動リダイレクトの制限を超えたため、このループはここで終了します。 | リダイレクトは、テストごとに 10 に制限されます。 |
| 状態コード検証 | 200 - OK が予期された状態 400 - BadRequest と一致しません。 |
返された状態コードは成功としてカウントされます。 "200" コードは、通常の Web ページが返されたことを示します。 |
| コンテンツの検証 | 必要なテキスト '<expected-response-text>' が応答に表示されませんでした。 | 文字列は、応答で大文字と小文字が区別される正確な一致ではありません。 たとえば、文字列 "Welcome!" は、ワイルドカード文字 (アスタリスクなど) を含まないプレーン文字列である必要があります。 ページのコンテンツが変更された場合は、文字列を更新する必要がある場合があります。 コンテンツの一致では、英語のみがサポートされています。 応答本文の長さが 1,000,000 バイトを超える場合、コンテンツの一致も失敗します。 クライアントは、そのバイト数を読み取ると、応答本文の読み取りを停止し、接続を切断します。 この動作により、クライアントが成功状態コードを返した場合でも、サーバーで |
| Azure portal でテスト結果が見つからない | この問題に関する特定のエラー メッセージは返されません。 可用性テストのエンド ツー エンド トランザクションの詳細を表示すると、Azure portal でテスト結果が見つかりません。 | UTF8 以外の文字は、Web テスト結果を表示するためにサポートされていません。 可用性テストを使用して呼び出されるエンドポイントからの応答に UTF8 以外の文字がないことを確認します。 |
| サポートされていない URL | この URL はサポートされていません | 可用性テストでは、パブリックに使用可能な IP アドレスとホスト名を介した通信のみが許可されます。 このエラーは、パブリック インターネット経由でルーティングできない内部 IP アドレスと通信しようとすると発生する可能性があります。 このエラーを解決するには、Web テストでパブリック IP アドレスのみが定義されていること、および Web テストで DNS 参照が返される有効なパブリックルーティング可能な IP アドレスのみに依存していることを確認します。 |
Note
接続の再利用手順が存在する場合、次の手順は存在しません。
- DNS 解決
- 接続の確立
- TLS トランスポート
次のステップ
TrackAvailability を使用して、カスタム可用性テストを送信します。
お問い合わせはこちらから
質問がある場合やヘルプが必要な場合は、サポート要求を作成するか、Azure コミュニティ サポートにお問い合わせください。 Azure フィードバック コミュニティに製品フィードバックを送信することもできます。