合成监控是什么
合成监控用脚本或探测服务模拟用户的关键操作：登录、查询、下单、调用接口，按周期从多个位置发起，并校验响应内容而不只是状态码。它回答的是「用户现在能不能完成这件事」，与只看内部指标的白盒视角互补。相比单点可用性探测，合成监控承载完整业务事务，因此更能发现「接口通但业务不通」的问题。
基本信息
| 实现手段 | 探测器的多模块配置、浏览器自动化、脚本定时任务 |
|---|---|
| 校验内容 | 状态码、关键字段、响应时间阈值 |
| 部署建议 | 多地探测点，结果统一写入指标或日志 |
| 数据用途 | 可用性告警、体验基线、发布验证 |
典型使用场景
- 登录链路：周期性执行登录并校验返回令牌是否可用
- 下单主流程：模拟完整下单并校验订单标识
- 多地域体验：不同探测点分别发起，比较响应时间
- 发布验证：上线后自动跑一轮关键事务
- 第三方依赖：校验外部接口返回内容是否仍然符合预期
接入探测器
接入探测器
- job_name: blackbox-http
metrics_path: /probe
params:
module: [http_2xx] # 选择一个已定义的探测模块
static_configs:
- targets:
- https://www.example.com/healthz
- https://api.example.com/ping
relabel_configs: # 把目标地址传给探测器
- source_labels: [__address__]
target_label: __param_target
- source_labels: [__param_target]
target_label: instance
- target_label: __address__
replacement: 127.0.0.1:9115 # 探测器实际地址
# 校验内容断言写在探测模块里，例如要求响应体包含关键字段
# 探测目标清单纳入变更流程：入口调整后同步更新，避免仍在测旧地址探测设计与取舍
| 设计点 | 做法 | 原因 |
|---|---|---|
| 探测路径 | 覆盖登录、下单等关键事务 | 健康检查路径无法反映业务是否可用 |
| 探测地点 | 多地部署探测点 | 单点网络抖动会被误判为业务故障 |
| 断言内容 | 状态码加关键字段 | 只看状态码会漏掉内容级错误 |
| 探测频率 | 按业务重要性与成本平衡 | 过于频繁会干扰容量统计 |
| 结果落库 | 统一写成指标或日志 | 便于告警、趋势与复盘 |
探测目标清单要纳入变更流程：域名或入口调整后同步更新，否则会出现探测仍在测已下线的地址、显示全绿而真实入口故障的情况。
合成监控会产生真实业务数据：下单类探测应使用专门的测试账号与可识别的测试商品，避免污染业务统计与库存。