原文と必ずしも一致しない場合があります。正確な内容は、公式ドキュメントの原文[英語]をご覧ください。ダウンタイムのアラートダウンタイムアラートのトラブルシューティング停電(停止状態)はアプリのチャートに赤い縦線として表示されます。ここでは、ダウンタイムアラートに関するトラブルシューティングのヒントを紹介します。断続的な障害に対してフラグを立てます。可用性監視サービスが、他よりも敏感である傾向がある理由である。サーバーと、サイト間のネットワークリンクが不調の場合、他のモニターが問題を示していない場合でも、断続的な失敗のために定期的なタイムアウトアラートが表示されることがあります。あなたがサイトにアクセスできたとしても、一部のユーザーはまだアクセスできない場合があります。あなたのサイトの壊れたネットワークパスをキャッチすることがあります。これは多くの場合、ホスティングプロバイダにおける一時的なネットワークの故障です。ダウンタイムの評価ダウンタイムイベントが断続的な故障によるものかどうかを確認する方法は以下のとおりです。サービスプロバイダーのネットワークの状態を確認してください。チャートで確認してください。セクションで閲覧可能な)アプリケーションサーバーのキュー時間やサーバーの容量の増加を探します。チャートを確認してください。ページ読み込みタイミングの計測と可用性の監視は、互いに独立しています。停電で長時間おきた場合、ページ読み込みタイミングのスループットが著しく低下していることがわかると思います。サービスを試してみてください。サービスが頻繁にあなたのサイトを打つことはありませんので注意してください。短い期間の断続的な故障がアラートをトリガしないように、アラート生成の最小時間の閾値を見なおしてください。対して貧弱なネットワークで接続している場合、頻繁に誤警報が発生する可能性があります。このような誤警報を最小限に抑えるために、アラートを送信する前に必要なダウンタイムの時間(分単位)を増やすことができます。なるような変更に取り組んでいます。ブラウザが一般的に送るものとは大きく異なっています。すべてのケースで、これは違いを気にすることはありません。顧客のリクエストが拒否されることがあります。開ける場合もあります。ヘッダーだったり、ユーザーエージェントかもしれません。実行して、失敗を再現できるかどうかを確認してください。Relicのコードはほぼ上記のリクエストをエミュレートします。各々の環境の違いにより、このコマンドが成功した場合でもPingerのリクエストが失敗することがあります。サポートを受けてください。Relicは、より互換性のあるリクエストを作る事ができるかを持たせることができるかもしれません。名前解決の問題が発生したときレスポンスを受信しません。領域は、次の正常なレスポンスをキャプチャします。ダウンタイムイベント内にレスポンスコード200が表示されるのはこれが理由です。関連する情報は以下のとおりです。DEGICAについて。