Application Insights の可用性監視で ping テストエラーを診断する
この記事では、Application Insights トラブルシューティング レポートにアクセスする方法について説明します。 このレポートを使用すると、ping テストが失敗する原因となる一般的な問題を簡単に診断できます。
注:
Web テスト関連の問題の多くは、古い DNS レコードまたは古い DNS レコードによって発生します。 最初のトラブルシューティング手順として、ローカル コンピューターで DNS キャッシュをフラッシュすることをお勧めします。
Windows で、 ipconfig /flushdns コマンドを 実行します。 他のオペレーティング システムの場合、同等のコマンドは異なります。
Application Insights のトラブルシューティング レポートを表示する
Application Insights のトラブルシューティング レポートを表示するには、次の手順に従います。
Application Insights リソースの [ 可用性 ] ページで、[ 可用性テストの選択] 見出しを見つけます。 その見出しの下で、個々の可用性テストの名前を選択するか、[ 全体 ] を選択して、すべてのテスト名の結合された結果を表示します。
次のどちらかの手順を実行します。
テスト名の [ 可用性の結果 ] ウィンドウで、[ ドリル イン ] 見出しを見つけて、[ 失敗 ] ボタンを選択します。 次 に、[可用性テストのサンプルをクリックします ] ウィンドウで、テスト名のテスト実行 (特定のリージョンと時間を表す) を選択します。
[可用性] グラフで、[散布図] ビューを選択し、散布図グラフ上のポイントの 1 つを選択します。
[ エンドツーエンド トランザクションの詳細 ] ページでイベントを選択し、[ 可用性プロパティ ] テーブル内の任意の場所を選択して、[ トラブルシューティング レポートの概要 ] セクションを開きます。
[ トラブルシューティング レポートの概要 ] セクションで、関連するエラー名を見つけて、その項目の [ステップに移動 ] リンクを選択して 、[トラブルシューティング レポート の詳細] を表示します。
トラブルシューティング レポートを使用して、障害の原因を特定する
次の表に、レポートに表示される可能性がある手順、エラー メッセージ、考えられる原因を示します。
| 手順 | エラー メッセージ | 考えられる原因 |
|---|---|---|
| 接続の再利用 | この問題に関する特定のエラー メッセージは返されません。 | Web テスト ステップは、以前に確立された接続に依存します。 そのため、DNS、接続、SSL の手順は必要ありません。 |
| DNS 解決 | リモート名を解決できませんでした: "<your-URL>" | DNS 解決プロセスが失敗します。 これは、DNS レコードが正しく構成されていないか、DNS サーバーの一時的な障害が原因で発生した可能性があります。 |
| 接続の確立 | 接続されたパーティーが一定期間後に適切に応答しなかったため、接続試行が失敗しました。 | サーバーが HTTP 要求に応答しません。 一般的な原因は、サーバー上のファイアウォールがテスト エージェントをブロックしていることです。 Azure Virtual Network内でテストするには、ご利用の環境に Availability サービス タグを追加します。 |
| 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 バイトを超える場合、コンテンツの一致も失敗します。 クライアントは、そのバイト数を読み取ると、応答本文の読み取りを停止し、接続を破棄します。 この動作により、クライアントから成功状態コードが |
注:
接続の再利用手順が存在する場合、次の手順は存在しません。
- DNS 解決
- 接続の確立
- TLS トランスポート
次の手順
TrackAvailability を使用して、カスタム可用性テストを送信します。
URL ping テストについて説明します。
お問い合わせはこちらから
質問がある場合やヘルプが必要な場合は、サポート要求を作成するか、Azure コミュニティ サポートにお問い合わせください。 Azure フィードバック コミュニティに製品フィードバックを送信することもできます。
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示