12.3 主动观测与 Observability as Code
服务端指标告诉你系统内部发生了什么，却不一定等于用户实际经历。浏览器渲染、DNS、CDN、第三方脚本、运营商网络和区域性路由问题，都可能在服务端一片绿色时让用户无法完成任务。
RUM 观察真实用户分布
Real User Monitoring（RUM）从真实浏览器或客户端会话采集体验信号，例如导航耗时、关键交互、资源加载、前端错误和地理/设备维度。
RUM 的优势是覆盖真实环境和长尾组合，限制也很明确：
- 流量低或某区域没有用户时，没有足够样本；
- 广告拦截、隐私设置和网络失败可能让遥测本身送不回来；
- 用户、URL、设备和 session 维度容易造成高基数与隐私风险；
- 平均值会掩盖弱网、低端设备和少数区域。
设计时使用聚合 route、粗粒度地理和受控设备分类，对可能识别个人的数据做最小化、采样、保留期限和访问控制。不要把 query string、邮箱或完整用户 ID 当作方便的诊断标签。
Synthetic 主动验证关键旅程
合成监控由受控探针定期执行固定操作：
DNS 解析 → TLS 握手 → 首页加载 → 登录 → 搜索 → 提交订单 → 校验结果它可以在没有真实流量时持续验证，也适合从多个区域建立外部视角。探针应分层：高频、低成本的 HTTP/TCP 检查覆盖入口；较低频的浏览器旅程验证关键业务路径。
合成账号和数据必须隔离，操作要幂等或可清理，不能给生产订单和财务报表制造污染。探针依赖自己的 runner、DNS 和凭据，所以要区分“产品失败”与“探针基础设施失败”。
RUM、Synthetic 与服务端遥测互补
| 信号 | 擅长回答 | 主要盲点 |
|---|---|---|
| 服务端 telemetry | 服务内部为何慢或错 | 浏览器、客户端与最后一公里 |
| RUM | 真实用户在哪些组合下受影响 | 无流量时没有样本，受采样影响 |
| Synthetic | 固定旅程是否从指定地点可用 | 只覆盖预先编写的路径 |
一次区域故障可以先由 synthetic 报告，再用 RUM 判断真实影响范围，最后用 trace、log 和 metric 定位具体依赖。三者应共享 service、environment、release 等稳定语义，并通过 trace ID 或 exemplar 建立跳转，而不是强行把所有事件塞进同一存储模型。
Observability as Code 管理可执行知识
应版本化的不只是 dashboard JSON，还包括：
observability/
├── recording-rules/
├── alerts/
├── dashboards/
├── synthetics/
├── collectors/
├── slo/
└── tests/PR 中同时审查信号定义、告警行动和诊断入口，可以避免“服务已经发布，监控下周再补”。CI 至少检查语法、PromQL/规则测试、dashboard 数据源引用、重复 UID、runbook 链接和潜在高基数维度。
配置同步也有所有权问题：若 Grafana provisioning 或 Git Sync 管理 dashboard，UI 临时编辑可能被覆盖，或反向提交进 Git。团队要明确哪一方是权威来源、紧急修改怎样回写，以及谁能变更共享 folder 和 datasource。
遥测保留由调查问题推导
所有信号永久全量保留既昂贵也增加数据风险。可以按用途分层：
- 近实时原始指标：支持告警和近期排障；
- 长期降采样指标：支持容量和趋势分析；
- 错误与高延迟 trace：较高保留价值；
- 正常 trace：按 head/tail policy 采样；
- 调试日志：短保留并受严格访问控制；
- 审计日志：按合规要求独立保存和防篡改。
先列出调查问题和法规要求，再决定分辨率、采样与期限。不能只按存储便宜与否决定，因为查询扫描、索引、remote write 网络和工程维护同样是成本。
让平台暴露成本与质量反馈
团队应能看到自己产生的：
- active series 与新增 label value；
- logs/traces ingest bytes；
- 被拒绝、丢弃和采样的遥测；
- 最昂贵且无人使用的 dashboard 查询；
- 没有 owner、runbook 或近期触发记录的告警；
- collector queue、export failure 和数据到达延迟。
预算不应变成简单的“超额就关监控”。更好的顺序是删无消费者信号、修正基数、预聚合、调整采样和保留，再评估扩容。
完整的可观测性交付条件
一个新服务进入生产前，至少应交付：
- 用户旅程对应的 SLI/SLO 和预算告警；
- 有界、命名一致且带 owner 的埋点；
- 从 overview 到依赖和资源的诊断路径；
- 关键旅程的外部 synthetic，必要时加 RUM；
- 从 alert 到 runbook、dashboard、trace、log 和 revision 的链接；
- 规则、dashboard、collector 与 synthetic 的版本化配置和测试；
- 信号缺失、遥测管线故障和成本异常的监控。
可观测性工程的终点不是收集更多数据，而是在故障发生时，用足够少、足够可信的证据缩短正确决策路径。
参考资料
- OpenTelemetry, Observability Primer
- Grafana, Observability as Code
- Grafana, Provisioning
- Prometheus, The Zen of Prometheus