真实用户监控(RUM)能告诉你"用户实际经历了什么",但没有用户流量的时候,服务挂了你可能到最后才知道。合成监控(Synthetic Monitoring)用"脚本化的虚拟用户"主动、定时、多地域地去探测系统,把可用性判断从"被动等反馈"变成"主动抓证据"。本指南从探针类型、拨测网络、断言阈值讲到告警联动与 SLO 融入,帮你搭一套"看得见全局、抓得住故障"的主动拨测体系。
关键概念:合成监控=用探针模拟用户请求主动拨测系统,按预设断言判断健康。RUM 看"真实用户碰到的",合成监控看"系统本应有的"——一个被动一个主动,互为补充。
- 1. 合成监控 vs 真实用户监控(RUM)
- 2. 探针类型:HTTP、浏览器与 API
- 3. 拨测网络:多地域与运营商覆盖
- 4. 断言与阈值:从状态码到体验指标
- 5. 与告警联动:主备、分组与降噪
- 6. SLO 融入与全局视图
- 7. 常见避坑
- 8. 最佳实践清单
1. 合成监控 vs 真实用户监控(RUM)
1.1 两者定位对比
合成监控:探针模拟,主动发起(无流量也能测、可多地域、基线稳定)
RUM:真实用户上报(真实体验、覆盖全、分设备/地域)
结论:合成回答"系统可用吗",RUM 回答"用户爽不爽"
1.2 合成监控最适合的场景
典型适用:
- 无人值守服务(批处理、定时任务)
- 健康检查外的"业务流程级"验证(登录/下单/支付)
- 发布后立即回放关键路径(金丝雀验证)
- 第三方依赖与 CDN 可用性(能测到 DNS/TLS/证书)
- 各地域网络质量横向对比
不适用:需要精确用户画像/转化漏斗(那是 RUM 的事)
ℹ️ 核心:合成监控是"体验的底线保证",RUM 是"体验的上限洞察"。先保底线,再追洞察。
2. 探针类型:HTTP、浏览器与 API
2.1 HTTP 探针
HTTP(S) Probe:最基础,检查状态码、响应时间、响应体关键字、TLS 证书
多步骤示例:GET /healthz → 200;POST /api/v1/login → 拿 token;
GET /api/v1/orders(带 token)→ 断言返回订单列表
注意:探针请求带可识别 UA/Header,便于后端区分
2.2 浏览器探针
Browser Probe:真实浏览器内核执行脚本(渲染/JS 错误/关键元素/交互)
成本:比 HTTP 探针贵 10~100 倍,频率要低
脚本要点:等待关键元素而非固定 sleep;断言无 console error;
记录 LCP/CLS 当基线;失败截图 + 视频回放
2.3 API、TCP、DNS 与证书探针
API Probe:校验"业务接口契约"(状态码、响应 schema、业务字段)
TCP Probe:端口连通性与握手耗时(适合数据库/中间件探活)
DNS Probe:A/AAAA 记录、解析耗时、按解析服务器对比
证书 Probe:TLS 证书有效期与链,提前 30 天预警过期
3. 拨测网络:多地域与运营商覆盖
3.1 地域与运营商矩阵
拨测要回答:北京/乌鲁木齐/海外可用吗?电信/联通/移动体验如何?
设计:地域按用户分布(华东/华北/华南 + 海外节点);
运营商每地域至少电信/联通/移动;
频率:关键路径 1m、业务流程 5m、浏览器 10m
矩阵示例:
上海电信 HTTP 1m 200ms / 广州移动 HTTP 1m 250ms /
新加坡 AWS Browser 10m 2.5s LCP
3.2 探针调度与分布
探针主机选择:
- 第三方拨测平台(节点分布广)
- 自建探针(自身机房/边缘节点,覆盖内部网络)
- 混合:公网用厂商,内网/云内用自建
关键设计:
- 探针与目标网络路径多样化(避免同路径集体假死)
- 探针本身要有监控(探针挂了不是服务挂了)
- 结果按"地域×运营商"分维度展示,别只留均值
4. 断言与阈值:从状态码到体验指标
4.1 断言的类型
状态断言:status == 200(或 2xx/3xx 白名单);证书剩余天数 > 30
内容断言:响应体包含 "orderId";不包含 "internal error"
性能断言:TTFB < 300ms、总响应 < 1s、LCP < 2.5s
流程断言(多步):每步状态码 + 上一步产物传给下一步
4.2 阈值设计:别用单点判断
好阈值 = 多条件 + 短窗口 + 与基线对比
反例:仅"某一次失败即告警"→ 抖动频报
正例:连续 2 个周期失败 或 5 分钟失败率 > 50% 才告警
经验:可用性连续失败 2~3 次判故障;延迟 P95 超基线 2 倍持续
5 分钟告警;内容断言 3 次以上才告警
4.3 断言失败的分级
P0:核心流程不可用(登录/下单 连续失败)→ 立即告警
P1:性能劣化(LCP > 3s 持续)→ 页面级告警
P2:非关键页面/功能 → 汇总日报,不逐条告警
好处:减少噪音,值班只看 P0/P1
5. 与告警联动:主备、分组与降噪
5.1 与已有告警体系的联动
合成监控的告警要"进"统一体系,不要孤立:
- 触发事件写进事件总线/告警平台
- 告警带失败详情(截图、响应体、trace_id)
- 复用既有通知策略(路由、升级、静默)
典型联动:
拨测失败 → 生成事件 → 关联最近发布/变更
→ 推送值班 → 附带一键跳转排障面板
5.2 主备判定与降噪
主备(Primary/Backup)策略:
同一目标用多个地域探针,结论以"多数派"为准
单一地域失败 → 可能地域网络问题,不算服务故障
多数地域失败 → 判定服务真实故障,告警升级
降噪手段:
- 拨测失败但 5xx 率/RUM 正常 → 可能是探针问题,先自检
- 维护窗口自动静默(发布窗口)
- 探针自身告警与目标告警分开
ℹ️ 核心:合成监控的告警必须"会说话"——带证据、分主备、可静默。否则只会制造"狼来了"噪音。
6. SLO 融入与全局视图
6.1 用合成监控喂 SLO
SLO 数据来源:服务器端指标(内部视角)或合成拨测(外部视角)
合成口径优势:覆盖无流量时段、多地域一致、走真实协议栈
示例 SLI:可用性 = 成功拨测 / 总拨测(30 天滑动)
Error Budget = 1 - SLO(如 99.9%,预算 43.8 分钟/月)
6.2 全局视图与钻取
全局仪表盘层次:
1. 总览:全局可用性/延迟趋势 + 地域热力图
2. 服务视图:按服务聚合的探针成功率/时延
3. 单次详情:失败快照(响应体、截图、trace)
钻取路径:
热力图发现"华南移动变慢" → 点进地域×运营商维度
→ 看延迟分布 → 定位到具体探针与目标
6.3 与 RUM 的对账
对账方法:同一时段 合成延迟 vs RUM 延迟对比,偏差大就查
价值判断:
合成稳定 + RUM 劣化 → 真实用户侧问题(新版本回归)
合成劣化 + RUM 正常 → 探针/网络问题
两者都劣化 → 服务真实故障,可信度高
7. 常见避坑
| 坑 | 现象 | 对策 |
|---|---|---|
| 只留均值 | 局部地域故障被掩盖 | 按地域×运营商分维度展示 |
| 单探针判故障 | 地域网络抖动误报 | 多数派主备判定 |
| 固定 sleep 等待 | 慢环境误判超时 | 等待关键元素而非 sleep |
| 探针带默认 UA | 被 WAF/CDN 特殊对待失真 | 用明确探针 UA 头 |
| 证书过期才发现 | 大面积服务不可用 | 证书探针提前 30 天预警 |
| 与 RUM 不对账 | 合成与真实体验背离 | 定期对比偏差并排查 |
| 告警不带证据 | 值班要手动翻日志 | 附带截图/响应体/trace |
| 探针频率过高 | 成本暴涨且污染后端 | 分层频率,浏览器最贵最低频 |
8. 最佳实践清单
□ 合成保底线可用性,RUM 看真实体验;探针成本分层
□ 关键路径 1m、业务流程 5m、浏览器 10m
□ 多地域×多运营商覆盖,结论用多数派判定
□ 断言用"状态+内容+性能+流程"组合
□ 阈值用连续失败/窗口失败率,不用单点
□ 告警进统一体系,带证据、可静默、按 P0/P1 分级
□ 用合成数据计算可用性 SLO,与内部口径互补
□ 定期合成 vs RUM 对账,偏差要排查
□ 探针自身也要监控,别把探针故障当服务故障
一句话原则
合成监控 = 主动拨测保底线 + 多地域多数派判故障 +
告警带证据 + 喂 SLO 与 RUM 对账,让可用性看得见全局。
小结
合成监控与主动拨测的核心是"主动、多视角、带证据":用 HTTP/浏览器/API 探针在无人访问时也持续验证系统可用性,通过多地域×运营商拨测网络定位"在哪不可用",用多条件断言与窗口化阈值减少抖动误报,让告警进统一体系并携带截图与 trace,再以合成口径计算可用性 SLO 并与 RUM 对账校准。落地记住五件事:分层探针频率、多数派判定故障、断言组合判断、告警带证据、与 RUM 定期对账。当系统"是否可用、在哪不可用、体验如何"都能被主动回答时,故障就从"等用户投诉"变成"先于用户发现"。
继续阅读
探索更多技术文章
浏览归档,发现更多关于系统设计、工具链和工程实践的内容。