Web アプリケーションの監視は、事前に記録されたブラウザーの対話をステップ実行するため、すべてのページで、適切なコンテンツ、欠落要素、パフォーマンス、アプリケーションまたはネットワークの問題が発生する可能性があるかどうかをチェックします。 特に、監視には、エラー (HTTP 500 コード、404 コードなど) のチェック、およびサーバー、ネットワーク、およびドメイン ネーム サーバー (DNS) プロセスの接続の問題が含まれます。 すべてのスクリプト実行の任意のステップで監視の問題が検出された場合、エラーの説明は 、オンラインレポート ログに記録されます。 また、検出された問題についてユーザーに通知するために、Dotcom-Monitor は指定された通知アドレスに アラート を送信します。

アラート アルゴリズム

Web アプリケーションの監視の主な目的は、ユーザーにアプリケーションの問題をできるだけ早く通知することです。 スクリプトの実行中に最初のエラーが検出されるとすぐにアラート通知が送信されます。 ユーザーがエラーに即座に対応できるようにするため、Web アプリケーション監視ソリューションは、監視セッションが通知を送信するまで待機しません。 エラーが解決しない場合は、後続の監視セッションごとに通知が送信されます。 問題が解決されると、 通知は、アップタイムアラートと共に送信されます。

スクリプトが、HTTP、TCP、またはコンテンツの検証の問題など、1 つの監視セッション中に複数のエラーを検出した場合、最初 に検出されたエラーのみでアラートが送信されます。 たとえば、HTTP エラーが最初に発生し、1 分後にコンテンツ検証エラーが発生した場合、アラート通知には HTTP エラー情報のみが含まれます。 この場合、ユーザーはコンテンツ エラーの説明を参照し、 オンライン レポートで影響を受ける可能性のあるサービスをリアルタイムで監視できます。

最初のエラー アラート アプローチにより、監視スクリプトの実行が終了するのを待たずに、タイムリーな通知が保証されます。

スクリプトの最後まで待って、すべてのアラート通知を送信してみませんか?

スクリプトによっては、非常に長く、実行が完了するまでに最大 15 分かかることがあります。 最初にエラーが発生した場合、ユーザーはすべてのアラートを受信するまで最大 15 分待つ必要があります。 私たちは、これは良いアプローチではないと信じています。 代わりに、Dotcom-Monitor は最初のエラーが検出されるとすぐにアラートを送信し、ユーザーが緊急の問題に直ちに対応できるようにします。

検出されたすべてのエラーに対してアラートを生成しないのはなぜですか?

一般に、監視デバイスには多数の HTTP 要素が含まれています。 各要素は、最大 2 つのエラー (接続エラーとタイムアウト エラー) を生成できます。 さらに、スクリプトにはコンテンツの検証エラーやナビゲーション エラーが含まれる場合があります。 たとえば、100 個の HTTP 要素を持つページの場合、エラーの量はスクリプトの実行ごとに 200 エラーを超える可能性があります。 すべてのエラーに対してアラートが送信される監視ソリューションでは、ユーザーは通知に圧倒される可能性があります。 同時に、一部のエラーは、最初の接続の問題の結果である可能性があります。 これらのエラーは、初期接続エラーを修正することで解決できます。 つまり、複数の通知は監視の目的に役立ちません。

EveryStep Web レコーダーで警告を抑制する方法

既知のエラーに対する警告を一時的に抑制する必要がある場合があります。 この操作は、記録されたスクリプトに ネットワーク フィルター のインライン関数を適用することで行うことができます。 たとえば、関連するエラーを修正する際にアラートを一時的に抑制したり、重要でない要素を監視から除外したりできます。