随着 Web 应用程序通过预先录制的浏览器交互进行监视步骤，它会检查每个页面中是否包含适当的内容、缺少的元素、性能以及潜在的应用程序或网络问题。 具体而言，监视包括检查错误（例如 HTTP 500 和 404 代码）以及服务器、网络和域名服务器 （DNS） 进程的连接问题。 如果在”每个步骤”脚本执行的任何步骤中都检测到任何监视问题，则错误说明将记录在联机报告日志中。 此外，为了通知用户检测到的问题，Dotcom-Monitor 会向指定的通知地址发送警报。

警报算法

Web 应用程序监视的主要目标是尽快通知用户有关其应用程序的任何问题。 在脚本执行期间检测到第一个错误时，将立即发送警报通知。 我们希望用户能够立即对任何错误做出反应，因此我们的 Web 应用程序监视解决方案不会等到监视会话发送发送通知。 如果错误仍然存在，将在每个后续监视会话上发送通知。 问题解决后，将发送带有“超时警报“的通知。

如果脚本在单个监视会话（如 HTTP、TCP 或内容验证问题）期间检测到多个错误，则仅在检测到的第一个错误时发送警报。 例如，如果首先发生 HTTP 错误，并在一分钟后出现内容验证错误，则警报通知将仅包含 HTTP 错误信息。 在这种情况下，用户可以在联机报告中看到内容错误描述并监视可能实时受到影响的其他服务。

第一个错误警报方法可确保及时通知，而无需等待监视脚本执行的结束。

为什么不等到脚本结束才能发送所有警报通知？

某些脚本可能很长，最多需要 15 分钟才能完成执行。 如果一开始就发生错误，用户将需要等待最多 15 分钟才能收到所有警报。 我们认为，这不是一个好办法。 相反，Dotcom-Monitor 会在检测到第一个错误后立即发送警报，从而允许用户对紧急问题立即做出反应。

为什么不对检测到的每个错误生成警报？

通常，监视设备包含大量 HTTP 元素。 每个元素最多可以生成两个错误，一个连接错误和一个超时错误。 此外，脚本可以包含内容验证和导航错误。 例如，对于具有 100 个 HTTP 元素的页面，每个脚本执行的错误量可能超过 200 个错误。 在监视针对每个错误发送警报的解决方案中，用户可能会因通知而不知所措。 同时，某些错误可能是初始连接问题造成的。 可以通过修复初始连接错误来解决这些错误。 换句话说，多个通知不会用于监视目的。

如何使用”每个步骤 Web 记录器”来抑制警报

可能需要暂时禁止对已知错误的警报。 通过将网络筛选器内联函数应用于录制的脚本，可以执行此操作。 例如，您可以在修复相关错误时暂时禁止警报，或从监视中筛选出微不足道的元素。