从 0 到 1 落地可观测性体系：日志、指标、链路与 SLO 实战
很多团队“有监控但看不懂、告警多但定位慢”。这篇文章给出一套可以真正跑起来的可观测性实施路径， 目标是把故障定位时间和恢复时间稳定压缩到可控范围。
1. 业务背景
我们维护一个多租户业务平台，调用链跨越网关、业务服务、异步队列和第三方接口。过去遇到问题时， 常常依赖人工在不同系统来回查日志，定位一次核心故障平均需要 40 分钟以上，且复盘证据不完整。
2. 目标定义
- 故障定位时间（MTTD）从 25 分钟降至 8 分钟以内。
- 故障恢复时间（MTTR）从 60 分钟降至 20 分钟以内。
- 关键交易链路建立可度量 SLO，按周输出误差预算。
- 告警降噪，避免“值班疲劳”。
3. 落地原则
先统一观测数据模型，再逐步补齐采集能力，最后做告警与值班流程收敛。顺序不能反，否则会快速堆出噪音系统。
- 所有请求必须有全局 Trace ID，贯穿日志与链路。
- 日志字段结构化，避免自由文本污染检索。
- 指标必须与业务语义绑定，禁止只采机器层数据。
- 告警遵循“可行动”原则，无行动项的告警直接删。
4. 实施步骤
4.1 日志治理
先统一日志模板：时间、租户、用户、接口、状态码、耗时、Trace ID、错误码。并拆分业务错误与系统错误， 保证搜索语句可复用。上线后第一周，日志检索效率就有明显提升。
4.2 指标体系
指标拆成三层：业务层（成功率、转化率）、应用层（接口耗时、错误率）、资源层（CPU、内存、连接池）。 仪表盘按“租户视角 + 服务视角 + 变更视角”组织，不再只看单服务曲线。
4.3 链路追踪
在网关入口注入 Trace，上下游传递 Span Context。对消息队列场景补齐异步链路，解决过去“请求断层”问题。 同时为慢链路建立 TopN 报表，按周追踪热点变化。
4.4 SLO 与误差预算
选择两个核心用户旅程：登录和订单提交。定义 99.9% 成功率、P95 延迟阈值，并以月为周期计算误差预算。 当预算连续超支时，自动触发“功能冻结 + 性能修复”机制。
5. 告警策略优化
- 合并重复告警，按服务和错误码聚类。
- 引入多窗口判定，降低瞬时抖动误报。
- 告警消息包含排查入口链接与最近变更记录。
- 对夜间非关键告警采用延迟通知与次日复核。
6. 实际效果
- MTTD：26 分钟 → 7 分钟
- MTTR：63 分钟 → 18 分钟
- 值班日均告警量下降 52%
- 核心链路周报可自动生成，复盘效率显著提升
7. 踩坑与复盘
最大坑是“先接工具后改流程”。工具只是放大器，流程没定义好会放大混乱。建议先明确值班分工、 排查路径和升级机制，再决定用什么平台承载。
8. 可复用模板
- 关键接口日志字段模板
- SLO 指标定义表
- 告警可行动检查清单
- 故障复盘结构化模板