常问问题

打开列表中的目标设备进行编辑。 在浏览器的地址栏中，您将看到类似：

https://user.dotcom-monitor.com/ClientID/DeviceEdit?pid=dc7f4ff2ca944dekjh1078b96707002& deviceId=63698 & taskId=132834 

设备 Id=63698 是设备ID。
任务Id=132834是任务ID。

默认情况下，交换服务器可识别电子邮件地址是否为本地地址。 如果是这种情况，服务器不会通过公共互联网发送电子邮件。 这是大多数电子邮件服务器的默认值。

如果您想测试跨公共互联网的发送和接收，我们建议您使用我们的往返电子邮件监视器 – 第^三方电子邮件帐户，如 Gmail。

我们的往返电子邮件监控要求在您所在的位置或^第三方 （gmail） 使用 POP3 或 IMAP 协议。

有三种方法可以通过往返来测试：

测试出站

1. 设置 SMTP 通过输入 SMTP 服务器地址通过 SMTP 服务器从我们的外部监视位置发送电子邮件。 （这将测试您的 SMTP 服务器是否正常工作）
2. 输入要将电子邮件发送到（例如gmail.com）
3. 输入 gmail POP3/IMAP 服务器地址，以便监视位置可以从 SMTP 服务器检索电子邮件。

测试入站

1. 设置 SMTP 通过输入 gmail SMTP 服务器地址通过 gmail SMTP 服务器地址从我们的外部监控位置发送电子邮件。
2. 输入要将电子邮件发送到的电子邮件地址（系统中的帐户）
3. 输入 POP3/IMAP 服务器地址，以便监视位置可以从 SMTP 服务器检索电子邮件。

测试出站和入站

1. 设置 SMTP 通过输入 SMTP 服务器地址通过 SMTP 服务器从我们的外部监视位置发送电子邮件。
2. 输入要将电子邮件发送到（例如gmail.com）
3. 设置 gmail 帐户以自动转发回服务器上的 POP3/IMAP 电子邮件帐户。
4. 输入 POP3/IMAP 服务器地址，以便监视位置可以从服务器检索电子邮件。

测试主动同步

ActiveSync 协议还执行往返。 活动同步 DOES 测试从远程设备（我们的监视位置）发送电子邮件以及通过该远程设备从服务器检索电子邮件的能力。 但是，它不会将电子邮件从一个活动同步服务器发送到另一个活动同步服务器，因为发送和接收帐户是同一服务器上的同一帐户，因此它找到到本地地址的最短路由不需要将邮件发送到公共 Internet，直到从远程设备（我们的监视位置）检索该消息。

以下是往返和 ActiveSync 之间的区别 - 您可以使用第三方电子邮件提供商（如 gmail）在多个服务器上移动电子邮件，而电子邮件则驻留在使用 Activesync 的 1 台服务器上：

第三方往返电子邮件路径

1. Dotcom-Monitor"电子邮件客户端"通过公共互联网发送消息
2. 客户的 SMTP 服务器将消息转发到公共互联网上^的第三方帐户
3. ^{第 3}部分 （gmail） 电子邮件服务器 接收邮件
4. ^{第 3}部分 （gmail） 自动转发给客户电子邮件服务器通过公共互联网
5. Dotcom 监视器"电子邮件客户端"请求客户 POP3 或 IMAP 服务器通过公共互联网发送电子邮件（或直接从^第三方 gmail 发送电子邮件，如果您不自动转发）

活动同步电子邮件路径

1. Dotcom-Monitor"电子邮件客户端"通过公共互联网发送消息
2. 客户 ActiveSync 服务器转发邮件，并发现该帐户是本地的，因此它会直接发送到帐户，而不是将其发送到公共互联网
3. Dotcom 监视器"电子邮件客户端"请求客户主动同步服务器通过公共互联网发送电子邮件

在可用帐户列表中的"选择帐户起始"页上提供的帐户 ID。

登录后，指向左侧边栏上的 “帐户 ”菜单，找到您的帐户ID。

部门识别码

登录主帐户后，您可以在"帐户"和"帐户设置 > "" > ID。

Each test in LoadView has a unique ID. Using the test ID you can call a specific scenario while configuring LoadView integration (e.g., for Jenkins or CircleCl builds).

The Test ID can be found on the test page.

The approach provides the ability to carefully define how Dotcom-Monitor interprets responses as either “Up” or “Down” responses. This is accomplished using filters.

Filtering defines the Up/Down states using the following adjustable criteria:

• Error is reported for a specified number of minutes
• Error is confirmed by a specified number of agents
• Error is detected in a specified number of tasks.

All filters and their settings are available at Configure > Filters. After a filter is applied to a device all of the device’s notifications are based on the filter’s criteria. “Default Filter” is assigned to all new devices. The default filter has a balanced configuration and is suitable for most monitoring devices.

Uptime/Downtime Calculations

The formula for the Downtime calculation is as follows:

1. Downtime Duration is tied directly to the configurations within the filter:

• The Downtime period starts when a filter’s conditions are met. For example, when the number of agents which report a failure equals the number of agents specified in the filter, and as also specified the conditions are met for the number of minutes and tasks, then a downtime alert is sent.
• The Uptime period starts when the filter’s conditions are no longer met. Specifically, Uptime starts when the number of agents, minutes, or tasks, which have reported “up” success, no longer meet the conditions needed for the filtered “down” conditions. For example, an “up” state is indicated when the number of error (“down”) responses received by agents becomes less than the number of error (“down”) responses that agents need, as set in the filter, in order to indicate a “down” condition.

2. Duration of “Undefined” state. An Undefined state can be set when the status of each agent involved in monitoring becomes Undefined. An agent status is considered as Undefined if the agent does NOT provide any response (error or success) in a certain amount of time:

Response Wait Time Duration = (the overall agents number+1) × monitoring frequency + 15 min

For example, we use three monitoring agents and a monitoring frequency of 5 minutes. Each agent will wait for a response for Response Wait Time Duration = (3+1)×5+15 min = 35 min. Once the time expired and no response received, an agent reports Undefined.

3. Duration of “Postponed” state.  Postponing a device at any moment will stop any monitoring activity until it is re-enabled.

4. Duration Excluded by Schedule. Another entity that can significantly affect Uptime/Downtime calculations is Schedules. This is an option for managing your monitoring during routine maintenance. Monitoring can be postponed for specific days of the week as well as specific hours and minutes during a day. To set up a schedule, follow the instruction.

LoadView 使用来自亚马逊 Web服务（AWS） 和 Azure 云服务的负载喷油器服务器。 Dotcom 监视器有 17 个地理区域，可以说明负载喷油器服务器，并且可以从中生成负载。 在每个区域中，可以实例化大约500个负载喷射器。

由于测试执行算法的差异，容量限制取决于监视平台类型：

• 对于 HTTP （S） 测试， 每个负载喷油器可以处理大约 1000 个并发 HTTP 用户。
• 对于 Web 页 或 Web 应用程序测试， 每个负载喷油器可以处理大约 25 个并 发用户。

使用以下公式计算特定负载测试类型的限制：

500 x 16 x 每个负载喷油器的并发用户 数 = 最大 用户负载

在下面查找生成的负载容量限制：

"上海"（中国）监测机构位于中国政府直接管理的"中国防火墙"后面。 中国政府对所有互联网流量都有过滤规则，它不是公开的。 这些过滤规则经常被修改，这反过来又会影响中国上海代理商的监测结果。

https://youtu.be/4py8zE5EtFc?si=LnpflrvFK1ESWYWQ

您可以在
“设备管理器
”屏幕上同时编辑多个设备的监控代理位置。

1. 单击左侧边栏上的 设备 。
2. 在 设备管理器中，通过选中每个设备旁边的框来选择要更新的设备。
3. 单击组操作工具栏上的“位置”按钮。
4. 在 “监视代理 ”窗口中，添加或删除位置。
5. 保存更改。

简而言之，UserView 和浏览器查看平台的任务在真实浏览器中加载网页并执行所有页面组件，而 HTTP（S） 任务使用模拟的"合成"浏览器，并且仅下载请求的页面元素而不呈现。

有关详细信息，请参阅通过 HTTP（S） 和浏览器查看/用户视图进行监视之间的差异以及HTTP（S） 和浏览器查看/用户查看任务之间的时间测量差异。

API 被 IP 地址锁定，仅允许授权用户访问。 配置 Web API 集成（管理 > 集成 > 新集成）后，必须通过 Web API 启用对 Dotcom 监视器帐户之外的数据的访问。 有关详细信息，请访问 如何将 Web API 访问的 IP 列入白名单 。

有关如何使用 API 的更多信息，请访问 API 入门页面。

Dotcom-Monitor 会根据以下计划自动清除系统的数据。

对于活动帐户：

• 生成的报告文件（如 CSV 或 PDF 文档）从生成之日起保留 3 年。
• 来自所有任务的响应时间数据将保留 6 个月。 在详细的瀑布图（如 DNS、第一个数据包响应时间和单个元素加载时间）中找到的所有响应时间数据都包含在六个月的保留期内。
• 汇总数据将保留 3 年。 例如，HTTP 页加载任务的元素级别详细信息在 1 年后将不再可用，但加载页面的聚合时间仍将保留 3 年。 这包括任何计算的汇总数据，如计算的停机时间和停机时间。 因此，如果指定的查询时间范围短于保存的聚合数据，则运行超过一年的图表或报表可能不会返回任何数据。
• 录像在 6 天后被清除。 要了解有关视频录制工作方式的更多内容，请参阅视频录制文章。

此保留策略适用于所有任务类型。

试用帐户数据不会根据此计划保留，并且可能在试用期到期后的任何时间删除。

关闭的帐户数据可以在帐户的最后一个用户登录后的 60 天内从系统中清除。

设置带有警报的任务并开始运行后，您可能会发现自己收到多个警报，但当您检查服务或网站时，一切看起来都不错。 请务必注意警报的内容，以便找出导致错误的原因。 某些错误可能包含自定义的 Dotcom-Monitor 错误代码，而其他错误代码可能包含 http 状态代码，可帮助您破译错误的原因。

由于 Dotcom-Monitor 监视功能的详细性质，您可能需要调整警报、报告或录制的脚本，以排除某些元素或错误，以消除误报。 其中一些原因包括：

• 一个或多个监视位置正在超时，而其他位置则成功。
• 已对您的网站进行了更改，并且不再找到预期的某些元素。
• 您网站上的内容反应缓慢，导致系统认为它不再存在，
• 网络流量导致您的网站速度变慢并超过超时限制。
• 通过互联网或一个监控位置的网络流量中的"打盹"
• 第三方元素加载缓慢，超时。
• 已更改第三方元素的 URL。

您可以通过创建筛选器并将筛选器应用于违规设备的警报和报告来调整这些误报。

您还可以在设备上启用误报检查。 这将触发来自发现监视失败的位置的级联检查，以确认设备多次出错

在 Dotcom-Monitor 系统中创建大量对象项（设备/任务/筛选器/计划/等）的最简单方法是打开支持票证并请求支持团队寻求帮助。

请准备好提供一个电子表格，其中包含要创建的所有对象的列表。 如果需要，应将电子表格附加到支持票证，以便支持人员可以为您进行必要的更改。

您可以通过单击设备旁边的操作、选择"警报静默"和"所需时间段的静音"，使单个 设备警报在设备管理器中静音长达 24 小时。

要同时使多个设备静音，请单击要静音的每台设备旁边的复选框，然后单击列表顶部的“警报静音”按钮，然后选择所需的时间段。

您还可以使用 API 使警报静音超过 24 小时。 有关如何执行此操作的信息，签出API：禁用设备的警报。

Dotcom-Monitor 系统提供了一组强大的监控工具，应仔细调整这些工具，以检测每个受监视目标所需的性能级别。 由于警报因素的数量和种类，您可能需要调整监视器上的一些设置，以消除误报。

要确定您收到的警报是否有效，请查看本文，了解识别误报。

如果您仍不希望以当前配置的方式接收警报，则在收到警报的时间从设备管理器运行联机报告将让您更深入地了解触发警报的内容。

最长时间已过期

如果联机报表上的错误显示"（300） 任务最大超时已过期"，则意味着任务完成的时间比为任务指定的最大超时长。 这可能指向一个合法问题，但由您确定在什么时刻需要接收警报。 如果您觉得收到警报太多，可以编辑任务并增加最大超时限制。

位置特定错误

如果从多个位置进行监视，但仅遇到来自单个位置的问题，则可以检查以下几项操作。

IP 受限访问

如果服务器访问受限于 IP 地址，则应确保将所有监视位置的 IP 地址添加到 IP 地址访问列表中。

需要安全证书

如果服务器需要证书才能访问内容，则必须打开支持票证才能将证书上载到每个监视位置。

中国长城

如果您遇到来自中国某地的问题，您可能会看到"中国防火墙"的结果。 由于中国政府严格控制从国内访问的内容，有时内容会被过滤掉，因为某些站点的不可访问性或带宽被限制，以便网站中的元素超时。 在这些情况下，由于中国政府控制着网络，因此你通常几乎做不了什么。

联系支持

如果您遇到来自一个或多个特定位置的问题，您可以打开支持票证，我们的支持团队将与您合作确定其他可能的问题。 有时 DNS 服务器路由可能不正确、反向 DNS 查找或特定于监视位置的问题。

用户查看超时

如果您正在运行 UserView 脚本，您可能需要向脚本添加 延迟 ，以便让网站有更多的时间正确加载所有元素。 您还可以重复此步骤，例如在添加延迟后单击 href，因此，如果链接未在第一次呈现在页面上，它将尝试再次单击它。

有许多因素可以确定警报消息是否将发送到谁，以及警报消息将发送给谁。

过滤 器

创建设备时，默认筛选器将自动应用于所有设备。 默认筛选器要求在触发警报之前收到多个位置（除非您只选择一个位置）。 当一个位置出现小网络打盹时，这样做是为了消除误报警报。 您可以创建不需要多个位置的筛选器，但请注意，由于 Internet 上的流量不受控制的性质，您可能会收到许多误报警报。

附表

如果已对设备应用计划，则设备将不会在计划外期间受到监视，因此不会记录任何数据以发出警报。 我们建议您不要将计划直接应用于您的设备，以便即使不希望全天候接收警报，系统也会全天候受到监控。 您可以将计划应用于不同的警报组，以便不同的组仅在工作班次期间接收警报。

升级期间

设置组警报时，可以指定组是否应在检测到错误时立即收到通知，或者是否应在首次检测到错误和发送错误之间出现延迟。 例如，您可能有一个第二层支持组，仅在第一层支持收到警报 30 分钟后继续发生错误时才会收到通知。

误报检查

默认情况下，"误报"检查处于打开状态。 这意味着，如果监视位置遇到错误，它将尝试在发送错误消息之前重新创建错误。 我们不建议禁用此功能，因为它会增加收到误报警报的风险，但是，如果您的任务需要特别长的时间才能完成一次迭代，您可能希望关闭误报检查，以便立即收到错误，而不是在检测到第一个错误后 10 分钟（5 分钟完成第一个任务），然后当检测到错误时，再用 5 分钟确认错误）

警报组

请注意，可以设置警报组并将其用于多个设备。 如果您注意到某人未收到警报，请确保其联系信息存在于所有必要的组中。 编辑或从组中删除人员时要小心，因为该组可能用于其他设备。

当网站仍然部分或完全访问时，可能会出现许多不同的错误。 在您的网站仍然可用时，可能会出现的一些最常见的错误包括：

• 已超出超时

如果错误指定已发生超时，请编辑监视任务详细信息并查找"最大超时"值。 如果您收到许多超时错误，您可能需要考虑增加最大超时值或完全删除它。 或者，您可以对站点执行更新以提高加载速度，或在内容分发网络 （CDN） 中托管单个元素。 如果尚未指定"最大超时"值，则任务的默认超时为 120 秒。

• 找不到正在验证的文本或图像

如果任务包括在页面上找到验证特定关键字或图像，则当缺少预期元素时，其余内容可能仍可以正确加载。

• 页面上的元素加载缓慢，导致脚本失败

如果任务在元素完全加载之前查找元素，则某些验证可能会失败。 如果任务是UserView脚本，则可能需要在验证此特定元素之前添加时间延迟。

• DNS 服务器子集的 DNS 解析可能失败

有时，由于 Internet 或本地服务提供商的各种网络问题，指定的或顶级 DNS 服务器之一可能无法完全限定到站点的 DNS 解析。 在这种情况下，大多数浏览器将继续查询下一个可用的 DNS 服务器并完成解析，但根据监视的设置方式，您仍可能收到警报。 有关如何排除 DNS 错误的详细信息，请访问我们的知识库 文章。

在 Online 报表详细信息中，当我展开单个监视会话以查看这些步骤的精细详细信息时，为什么我们看到错误，但总体监视任务正在成功？

在很多情况下，单个元素或对被监视服务器的调用将导致标记或错误响应。 此类响应通常用红色感叹号标记标记，文本可能略为灰显。

1. 这种类型的标记事件的一个原因可能是被监视的网站需要基本身份验证。 在这种情况下，URL 的第一个请求将被标记为错误，因为服务器返回 401 响应，让浏览器知道需要基本身份验证。 然后从监视器发送下一个请求，包括基本身份验证凭据，返回成功的响应，因此从技术上讲，任务已成功完成。
2. 另一个可能的原因可能是请求的元素已经从监视脚本中的上一个请求加载，一旦实现，请求就会被取消，但任务作为一个整体再次成功完成。
3. 有关此类异常的更多见解，请通过打开支持票证随时联系支持人员。