一句话回答
合成监控是按计划从受控地点运行脚本化的请求或浏览器流程,来测试网站、App 和 API,在没有真实用户流量时也能发现宕机和性能回退。
什么是合成监控?
合成监控(Synthetic Monitoring)不是等真实用户来访,而是按计划从受控的地点运行脚本化的访问,来测试网站、App 或 API。比如机器人每五分钟从三个地区加载一次首页,每小时登录并完成一次结账,或者每分钟调用一次 API 接口,发现慢或出错就告警。
它也叫主动监控或合成测试。与之相对的是真实用户监控(RUM),测量的是真实访客的体验。
合成检查的类型
| 类型 | 做什么 | 能发现 |
|---|---|---|
| 可用性(ping / HTTP) | 请求一个 URL,检查状态码和响应时间 | 宕机、证书过期、DNS 故障 |
| API 检查 | 调用接口并校验返回 | API 坏了或变慢、返回内容不对 |
| 浏览器检查 | 用真实浏览器内核加载页面并记录耗时 | 页面慢、脚本报错、布局问题 |
| 事务(多步骤) | 用脚本走完一段用户流程:登录、搜索、加购、付款 | 单页检查发现不了的流程故障 |
浏览器检查通常报告实验室指标,比如最大内容绘制、总阻塞时间和速度指数,都是在固定的设备和网络配置下测的。
合成监控和真实用户监控
| 合成监控 | 真实用户监控 | |
|---|---|---|
| 数据由谁产生 | 脚本机器人 | 真实访客 |
| 什么时候发现问题 | 用户碰到之前,没流量时也能 | 用户经历之后才知道 |
| 条件 | 固定设备、网络、地点,空缓存 | 各种真实的设备、网络和缓存状态 |
| 覆盖范围 | 写了脚本的页面和流程 | 人们实际访问的每个页面 |
| 适合 | 可用性、发版检查、性能回退、和竞品对比 | 真实体验、核心网页指标的现场数据、决定先修什么 |
| 主要盲区 | 反映不了你的真实受众 | 测不了没人访问的页面或流程 |
大多数团队两样都需要:合成检查让你一出问题就知道,RUM 让你知道真正在用的人觉得网站有多慢。
两者为什么对不上:一个示例
同一周测的某个商品页(示例数据):
| 来源 | 配置 | 最大内容绘制 |
|---|---|---|
| 合成浏览器检查 | 电脑、快速网络、一个数据中心,每 15 分钟一次 | 1.8 秒(多次运行的中位数) |
| RUM,全部访客 | 真实设备和网络 | P75 为 2.6 秒 |
| RUM,只看手机 | 真实手机、移动网络 | P75 为 3.4 秒 |
合成检查说页面很快,手机访客不这么觉得。两边都没错:合成测试测的是一种受控配置,RUM 测的是真实条件的分布,而 Google 按真实访问的第 75 百分位评估核心网页指标。发版后用合成数字抓性能回退,用 RUM 的 P75 判断页面对你的受众够不够快。见百分位数和核心网页指标。
什么时候用合成监控
- 可用性和服务等级。 网站挂了要在几分钟内知道,凌晨三点没流量时也一样。
- 关键流程。 注册、登录、结账要端到端地持续演练。
- 上线前和预发环境。 在还没有生产流量时跑同样的脚本。
- 第三方依赖。 发现你依赖的支付、CDN 或 API 变慢。
- 对比基准。 在相同条件下和竞品页面比较。
局限
- 界面一改,脚本就可能失效,需要维护。
- 少数几个地点和设备代表不了全部受众。
- 从数据中心测往往比真实情况快,因为离服务器近、网络好。
- 从很多地点高频跑完整的浏览器流程,成本不低。
在 TapCub 里
TapCub 是真实用户监控工具:性能报表用真实访问测量加载耗时和核心网页指标,可以看 P75、P95、中位数和平均值,并按页面、国家、设备、浏览器和操作系统拆分。它不跑定时的合成检查或可用性测试。宕机告警可以搭配专门的可用性或合成监控服务,用 TapCub 看页面对真实访客有多快。查看某个页面的现场数据,见检查核心网页指标。
参考资料
- Wikipedia. Synthetic monitoring.
- Elastic. What is synthetic monitoring?
- Google. Why lab and field data can be different.
这个解释清楚吗?
我们会根据反馈修改和补充这篇内容。
提交没有成功,请稍后再试。
谢谢你的反馈,我们会据此改进这篇内容。你已经反馈过这篇了,谢谢。
