网站合成监控实战：可用性检查与事务脚本
可用性监控只回答"网站有没有挂"，而**合成监控（Synthetic Monitoring）**更进一步：它从全球多个探针地点主动发起请求，模拟真实用户点击、登录、下单的完整路径，在用户受影响之前发现问题。按 Datadog 的定义，合成测试通过"来自全球各地的模拟请求与操作"观察系统表现，可覆盖 HTTP、SSL、DNS、WebSocket、TCP、UDP、ICMP 与 gRPC 等多个网络层，并对回归、坏特性、高响应时间与异常状态码发出告警。
从可用性检查开始
最轻量的合成监控就是可用性检查（uptime check）。以 UptimeRobot 为代表的工具按固定间隔从多地点请求你的 URL，检查返回状态码、响应时间，甚至在页面中搜索关键字。落地时建议至少覆盖三层：
- HTTP 检查：验证首页返回 200 与预期内容，这是最基础的存活探测。
- 关键字检查：请求页面并确认包含特定文本（如登录框或商品标题），能发现"返回 200 但页面内容异常"的情况。
- 多地点检查：选择至少 3 个与用户分布重合的地区，避免"单点探测正常，实际部分地区访问失败"。
检查频率要在"发现速度"和"成本/误报"之间取舍。每分钟一次适合核心交易页面，5 分钟一次适合一般站点，10-30 分钟一次适合低频内容页。
浏览器事务脚本
可用性检查只覆盖单次请求，无法验证业务流程。浏览器事务测试（browser transaction test）用无头浏览器录制并回放关键路径，例如：打开首页 → 搜索商品 → 加入购物车 → 结账。这类测试的价值在于捕获"后端正常但前端链路断裂"的问题，比如按钮失效、脚本报错、表单无法提交。
在 Checkly 或 Datadog 等平台中，事务脚本通常支持代码化（Playwright/Puppeteer）与录制两种方式。建议从业务价值最高的 5-10 条路径开始，优先覆盖登录、支付、注册这类"断了就流失用户"的流程，而不是追求脚本数量。脚本要尽量避免依赖外部测试数据，并用确定性选择器定位元素，减少因页面调整导致的误报。
脚本里最容易踩的坑
写事务脚本最常见的失败不是断言写错，而是选择器太脆。下面两行对比很能说明问题：
// 易碎：依赖特定 class，页面改版就挂
await page.click('.add-to-cart-v2');
// 稳健：按 role 加文本定位，接近真实用户的点击路径
await page.getByRole('button', { name: '加入购物车' }).click();
同理，测试账号不要用真实的注册用户，尽量让被测环境提供测试专用的 mock 数据，避免脚本每次跑都产生真实的订单或邮件。
工具怎么选：一张对比表
| 工具 | 免费额度 | 探针地点 | 浏览器事务 | 适合场景 |
|---|---|---|---|---|
| UptimeRobot | 50 个监控、5 分钟间隔 | 多地点 | 不支持 | 纯可用性检查 |
| Checkly | 有限免费额度 | 全球 + 私有探针 | Playwright | 代码化与 API 检查 |
| Datadog Synthetics | 无免费层 | 托管 + 私有地点 | 录制/代码 | 已有 Datadog 全家桶 |
| Grafana Synthetic | 按量计费 | 全球节点 | k6 浏览器 | 已有 Grafana 生态 |
对刚起步的独立站，UptimeRobot 免费版加两条 Checkly 浏览器脚本是一个低成本的组合：前者兜底"网站挂了没人知道"，后者盯住下单这条命脉。工具之后可以换，但"至少有一个自动检查"这件事越早越好。
全球地点与告警
合成监控的告警与探针地点强相关。Datadog 允许从托管地点或私有地点发起测试，私有地点还能监控内网 API 与未公网暴露的服务。配置告警时注意两点：
- 连续失败判定：单次失败可能是网络抖动，建议配置"连续 N 次失败"或"失败率阈值"再触发告警，减少误报。
- 分级通知：轻微异常走邮件/IM，核心业务不可用才走电话/短信，配合 监控报警指南中的分级策略。
凌晨两点被叫醒之后：一次真实告警复盘
一家跨境电商小团队第一次被合成监控救下是在凌晨两点。他们的规则是"连续 3 次失败才通知"，间隔 5 分钟。那天支付网关回调接口 2:03 开始返回 500，2:18 触发邮件加 Slack，值班的人 2:25 起来一看是第三方网关限流，进控制台调高配额，2:40 恢复，用户几乎没有感知。
这个案例说明两件事：一是"连续失败"阈值避免了一闪而过的抖动把全组人吵醒；二是多地点探针能帮你分辨"全球挂了"还是"某区域挂了"——那天只有美东地点报警，问题出在区域链路上，而不是服务器本身。
与真实用户监控互补
合成监控是"预先演练"，真实用户监控（RUM）是"事后复盘"，两者互补。合成测试数据稳定、可比、无隐私负担，适合作为 SLO 的观测口径；RUM 反映真实设备、网络与用户行为的分布。在 SLO/SLI 模板中，可用性 SLO 通常用合成监控口径计算，而性能类 SLI 更适合用 RUM 数据。
16IDC 观察
对独立站和小团队而言，合成监控的投入产出比很高：一个免费层级的 UptimeRobot 加几条浏览器事务脚本，就能覆盖"网站挂了没人知道"这个最常见事故。选型时可以参考 网站监控工具选型指南，自建方案见 Uptime Kuma 部署；如果已经用 Grafana 全家桶，可结合 Grafana Cloud 成本归因了解合成检查的计费拆分，前端体验可参考 RUM 与 Core Web Vitals 监控。更多内容请查看 监控报警分类。
原文来源：https://docs.datadoghq.com/synthetics/
参考：Checkly 文档 https://checklyhq.com/docs/；Playwright 定位器指南 https://playwright.dev/docs/locators；Grafana Synthetic Monitoring https://grafana.com/docs/grafana-cloud/monitor-synthetic-monitoring/