合成监控应该如何设计？
简化版
合成监控从固定探测点主动模拟用户执行 DNS、登录、搜索、下单等旅程，即使没有真实流量也能发现可用性和性能问题。它验证的是预设路径，不能替代真实用户监控和服务内部遥测。
详细版
选择少量关键旅程，使用专用测试租户和可清理数据，分别从公网、多区域和内网运行。每一步设置独立超时与断言，记录 DNS、TLS、TTFB 和业务结果，并传播 traceId 供内部下钻。
探测频率兼顾发现时间、成本和副作用；写操作必须幂等且自动清理。凭证短期轮换，探测流量可识别但不绕过真实鉴权；告警要求多点或多次失败，避免单探针网络抖动误报。
完整版教学
一、主动监控的价值
凌晨没有真实用户时，真实流量指标无法证明登录可用；合成探测仍可每分钟验证。它也能从用户外部视角覆盖 DNS、证书和 CDN，而不仅是服务进程。
心法：合成监控证明“预定旅程现在能走通”，不是证明所有用户体验都正常。
二、探测层次
| 类型 | 验证内容 | 局限 |
|---|---|---|
| Ping/端口 | 网络可达 | 不懂业务 |
| HTTP API | 协议与断言 | 不含浏览器行为 |
| 浏览器 | 页面与 JS | 成本高、易波动 |
| 交易旅程 | 端到端业务 | 有副作用 |
按风险组合，而非所有页面都用昂贵浏览器探测。
三、步骤化诊断
DNS -> TCP -> TLS -> GET login -> POST auth -> search -> logout分别记录阶段耗时，才能区分证书握手慢与后端处理慢。每步断言状态码、关键字段和业务状态，不能只检查页面返回 200。
四、多地域与告警
北京探针失败、上海和广州正常，可能是局部网络；三个区域同时连续两次失败才更像服务故障。告警策略根据 SLO 和探测间隔定义发现上限。
1 分钟探测、要求连续 2 次失败，理论最快约 1 分钟、最慢接近 2 分钟才触发，还要计执行时间。
五、安全与测试数据
使用专用身份、最小权限和 Secret Manager，禁止把生产用户密码写脚本。写旅程使用带标记的测试订单，并在成功或失败后清理；清理任务也要告警。
探测不应走隐藏后门，否则测到的不是用户真实路径。可通过 header 标识以便分析，但鉴权、限流和依赖仍应真实。
六、与其他信号结合
探测请求带 trace context，失败后直接查看内部 Trace、日志和依赖指标。真实用户监控负责设备、网络和长尾分布，合成监控负责持续基线，两者互补。
脚本本身需要版本、owner 和运行 SLO；选择器或测试数据过期也会制造假故障。
浏览器探测应固定关键资源和等待条件，避免用任意 sleep 掩盖页面异步加载差异。
探针服务自身的 DNS、出口与时钟也要监控，否则多个脚本同时失败可能只是探针基础设施故障。
长期趋势应区分探测点网络耗时与应用耗时，防止把公网路径变化误判为后端回归。
七、常见误区与追问
- 误区：健康检查通过就不需要合成监控。 健康检查通常不覆盖外部旅程。
- 误区：HTTP 200 代表业务成功。 页面可能返回错误文案或空数据。
- 误区：单个探针失败应立即全网告警。 先区分探针和区域故障。
- 误区：测试账号可以拥有管理员权限。 应遵循最小权限。
- 追问：写操作怎样防污染？ 专用租户、幂等标记、自动清理和对账。
- 追问：频率如何确定？ 由发现目标、执行成本与副作用共同决定。
- 追问：脚本失败如何定位？ 分阶段计时、Trace 关联和探针自监控。
八、加强记忆
合成监控按“关键旅程—外部多点—分步断言—安全测试数据—多次确认—Trace 下钻”设计。它在无流量时持续证明基本路径，但覆盖有限；必须与真实用户指标和内部遥测结合，并把探针、凭证与清理流程本身当生产系统维护。