Search
中文
English中文
Get started免费开始
浏览器渲染监控定时任务告警前端故障排查
7 min

如何将 AdsCrawl 与 Cronitor 配合使用：浏览器检查 + 告警

将 AdsCrawl 浏览器自动化与 Cronitor 监控相结合，捕捉渲染故障，而不仅仅是 HTTP 200 状态码。包含设置、代码和告警工作流。

AAnonymous

如何将 AdsCrawl 与 Cronitor 配合使用：浏览器检查 + 告警

200 OK 并不意味着你的页面真的能正常工作。现代网站采用客户端渲染，因此服务器可能返回完美的状态码，而浏览器却显示空白屏幕、布局错乱或结账流程停滞。AdsCrawl 提供真实的浏览器会话来检查用户看到的内容，Cronitor 则将这些检查转化为定时任务，并在出现异常时发出告警。两者结合，弥合了“服务器已响应”与“页面正常工作”之间的差距。

本指南解释了这两个工具如何协同工作、如何设置定期浏览器检查，以及这种组合能解决哪些单独工具无法处理的问题。

为什么要结合使用 AdsCrawl 和 Cronitor？

AdsCrawl 是浏览器自动化和数据提取基础设施。它通过统一的 API 运行远程 Chrome 会话，捕获截图，提取 HTML 和 Markdown，并暴露 CDP 控制以进行更深入的检查。Cronitor 是开发者监控工具：它监视 cron 任务、心跳、合成正常运行时间检查和网站性能，然后通过电子邮件、Slack、Teams、Discord 或 webhook 向相关人员发出告警。

简而言之：AdsCrawl 回答页面实际渲染出什么，Cronitor 回答该渲染当前是否健康，如果不健康谁需要知道。

没有 Cronitor，AdsCrawl 运行是手动的，或者埋没在管道中且没有告警。没有 AdsCrawl，Cronitor 的合成检查可以验证 HTTP 状态、延迟和响应正文内容，但无法像真实浏览器那样执行 JavaScript 或检查渲染后的 DOM。两者结合，可以按计划获得浏览器级别的真实情况，并内置告警功能。

工作流如何协同

该模式是由 AdsCrawl 驱动的心跳式检查：

  1. Cronitor 定义计划。 在 Cronitor 中创建一个检查或心跳监视器，期望以固定间隔（例如每 15 分钟）收到信号。
  2. 定时运行器调用 AdsCrawl。 cron 任务、GitHub Action 或无服务器函数调用 AdsCrawl API 打开浏览器会话，导航到目标 URL，并捕获证据。
  3. AdsCrawl 返回渲染后的证据。 你会获得截图、提取的 HTML 或 Markdown，或者可以查询特定 DOM 状态的 CDP 会话。
  4. 运行器评估结果。 检查预期文本、元素是否存在、布局标记或非空白渲染。
  5. 运行器向 Cronitor 报告。 发送成功心跳，或带有上下文的失败信息。如果心跳缺失或检查失败，Cronitor 会通知合适的人员。

这样可以让 AdsCrawl 专注于浏览器工作，Cronitor 专注于调度、状态和告警路由。

为浏览器检查设置 AdsCrawl

首先查看 AdsCrawl 文档 了解身份验证、会话创建和内容捕获端点。核心流程是：身份验证、创建会话、导航、捕获和关闭。

一个最小的 Node.js 示例，捕获目标页面的截图和 HTML：

const response = await fetch('https://api.adscrawl.net/v1/sessions', {
  method: 'POST',
  headers: {
    'Authorization': `Bearer ${process.env.ADSCRAWL_API_KEY}`,
    'Content-Type': 'application/json'
  },
  body: JSON.stringify({
    url: 'https://example.com/checkout',
    capture: ['screenshot', 'html'],
    waitUntil: 'networkidle'
  })
});

const result = await response.json();
// result.screenshot -> base64 或 URL
// result.html -> JavaScript 执行后的渲染 DOM

对于在出现有意义状态之前需要交互的页面，使用 CDP 会话进行点击、滚动或等待选择器。AdsCrawl 的远程 CDP 支持意味着你可以编写与用户相同的操作脚本，然后捕获结果。

请记住一些实用规则：

  • 使用 waitUntil: 'networkidle' 或显式选择器等待，以便捕获渲染后的状态，而不是初始外壳。
  • 将截图保留较短的时间窗口，以便将失败的运行与已知良好的基线进行比较。
  • 当网站对新会话行为不同时，重用指纹配置文件。
  • 注意你的信用使用量；频繁检查会累积，因此根据页面的实际波动性调整间隔。

如果你在决定之前正在比较浏览器 API，请参阅我们的 AdsCrawl vs Scrapfly vs ApiFlash 分析，了解会话模型和定价的差异。

为浏览器检查告警设置 Cronitor

如何将 AdsCrawl 与 Cronitor 配合使用：浏览器检查 + 告警 - 为浏览器检查告警设置 Cronitor

如何将 AdsCrawl 与 Cronitor 配合使用：浏览器检查 + 告警 - 为浏览器检查告警设置 Cronitor.

Cronitor 的首屏截图。

Cronitor 的 开发者文档 涵盖了任务、检查、心跳和告警。对于此工作流，有两种可行的模式。

模式 A：心跳监视器

在 Cronitor 中创建一个心跳监视器，期望每 N 分钟收到一次 ping。你的 AdsCrawl 运行器在成功时发送心跳，失败时保持静默。如果 Cronitor 在宽限窗口内没有收到预期的节拍，它就会发出告警。

这是最简单的模式，当你的运行器能够可靠执行时效果很好。它还能捕获运行器本身挂掉的情况，而纯粹的通过/失败检查会遗漏这一点。

模式 B：带断言的合成检查

创建一个 Cronitor 检查，指向你的运行器暴露的小型端点，或者使用 Cronitor 的检查断言针对反映最后一次 AdsCrawl 结果的状态端点。这样可以在浏览器结果之上获得 Cronitor 的 12+ 区域测试和基于阈值的告警。

在实践中，许多团队同时使用两者：心跳证明管道运行过，检查验证结果。

按严重程度配置告警路由。单次渲染失败可以发送到 Slack 频道；连续三次失败应该呼叫某人。Cronitor 支持电子邮件、Slack、Teams、Discord、PagerDuty 和 webhook，因此你可以将渠道与紧急程度匹配。

一个实际示例：监控 JavaScript 密集的结账流程

假设你运营一个电子商务网站，其结账页面完全在客户端渲染。即使支付组件加载失败，你的服务器也会返回 200。

  1. Cronitor 心跳 checkout-render 期望每 10 分钟收到一次 ping。
  2. 一个定时函数调用 AdsCrawl 打开 https://example.com/checkout，等待 [data-testid="payment-form"] 选择器，并捕获 HTML 和截图。
  3. 该函数检查支付表单是否存在，以及页面是否显示错误状态。
  4. 成功时，它 ping Cronitor。失败时，它发送带有截图 URL 和缺失选择器的失败事件。
  5. Cronitor 在 Slack 中告警 #eng-oncall，并在连续两次失败后升级到 PagerDuty。

这正好捕获了 HTTP 监控遗漏的故障模式：页面加载了但无法工作。它还为响应者提供了故障发生时的截图和 DOM 快照，大大缩短了诊断时间。

如果你已经在使用其他监控工具，同样的模式也适用。我们的 将 AdsCrawl 与 UptimeRobot 配合使用 指南介绍了等效的设置。

这种组合解决了哪些问题

  • 静默渲染失败。 客户端错误、缺失资源和损坏的第三方脚本不会出现在状态码中。浏览器检查可以。
  • 管道盲点。 如果你的 AdsCrawl 运行器停止执行，心跳监视器可以捕获。单独的通过/失败检查则不能。
  • 嘈杂检查导致的告警疲劳。 Cronitor 的阈值和宽限窗口让你忽略短暂的波动，只对持续的问题发出告警。
  • 诊断缓慢。 附加到告警的截图和 DOM 快照为响应者提供证据，而不是猜测。
  • 第三方依赖的覆盖缺口。 如果供应商脚本破坏了你的页面，你自己的服务器指标不会揭示。渲染检查会。

在心跳和合成检查之间选择

情况 推荐的 Cronitor 模式
你控制运行器并希望检测其故障 心跳监视器
你希望对渲染结果进行多区域验证 带断言的合成检查
你需要管道存活和结果验证 心跳加检查
你希望根据性能阈值告警，而不仅仅是通过/失败 带预算的合成检查

如果你对此不熟悉，从心跳开始。一旦你知道页面的“健康”状态是什么样，再添加合成检查。

相关阅读

来源与进一步阅读

  • Cronitor — 为开发者打造的监控 - 监控代理、cron 任务、网站、API 以及介于两者之间的一切。任务、正常运行时间检查、心跳、状态页面和分析集于一个工具中。

常见问题

Cronitor 能直接运行 AdsCrawl 吗？

不能。Cronitor 负责调度和告警；AdsCrawl 执行浏览器会话。你需要一个小型运行器（cron 任务、无服务器函数或 CI 任务）来调用 AdsCrawl，然后向 Cronitor 报告。

我应该多久运行一次浏览器检查？

将间隔与页面变化的频率以及故障的代价相匹配。对于关键页面，每 5-15 分钟是常见的；对于低风险页面，每小时也可以。与 AdsCrawl 信用使用量平衡。

在渲染页面中我应该断言什么？

断言那些表明页面实际正常工作的内容：关键元素的存在、预期文本、没有错误横幅以及非平凡的 DOM 大小。截图对人类有用，但如果没有基线比较，自动断言更难。

这会取代传统的正常运行时间监控吗？

不会，它是对其的补充。保留 HTTP 级别的检查以获得快速、廉价的可用性信号，并为渲染重要的页面添加浏览器检查。同时运行两者可以为你提供分层覆盖。

我可以使用 AdsCrawl 的 CDP 会话进行更深入的检查吗？

可以。远程 CDP 访问允许你查询计算样式、检查网络请求并在页面上下文中评估 JavaScript，这对于超越 DOM 存在的断言很有用。

结论

AdsCrawl 和 Cronitor 解决了同一问题的不同方面。AdsCrawl 为你提供一个真实浏览器，看到用户所看到的；Cronitor 确保该视图按计划被检查，并在出现问题时通知正确的人。设置很简单：一个定时运行器、一个 AdsCrawl 捕获调用、一个简单的断言，以及一个 Cronitor 心跳或检查。回报是捕获状态码永远不会揭示的故障，并且每个告警都附有证据。

Related Articles

Browse all articles