系统出了问题，最怕两件事：
- 看不到问题发生在哪
- 看到了告警但无法定位根因
可观测性的目标不是“采集更多数据”，而是“更快回答问题”。
【场景：接口超时，但每个服务都说自己正常】
常见排障困境：
- 网关提示超时。
- A 服务日志正常。
- B 服务偶发慢调用。
- 数据库监控无明显异常。
如果没有统一的 traceId，很难还原一次请求在多服务间的真实路径。
【三件套角色分工】
1）日志（Logs）
回答“发生了什么”。
2）指标（Metrics）
回答“系统状态如何变化”。
3）链路（Traces）
回答“请求在哪一步变慢或失败”。
三者合在一起，才能完成闭环定位。
【日志：先统一字段，再谈平台】
建议统一日志字段：
- timestamp
- level
- service
- traceId
- spanId
- requestId
- businessKey
{
"service": "order-service",
"traceId": "6fc3...",
"requestId": "req-20260227-001",
"message": "create order success"
}
【指标：先定义 SLI/SLO】
核心指标建议：
- 延迟：P50/P95/P99
- 错误率：5xx 比例
- 吞吐：QPS/TPS
- 资源：CPU、内存、连接池、线程池
建议先给核心接口定义 SLO：
- 比如“P95 < 300ms，错误率 < 0.5%”。
【链路追踪：每个入口都要打通 traceId】
关键点：
- 网关生成或透传 traceId
- 跨线程、跨服务、跨消息队列都要传递
- 日志和 metrics 必须可按 traceId 关联
String traceId = Trace.currentTraceId();
log.info("traceId={}, create order start", traceId);
【告警设计：减少噪音，提升有效性】
反模式：
- 单指标阈值告警太多
- 告警没有上下文
建议：
- 组合告警（错误率 + 延迟）
- 告警附带最近异常日志、影响接口、责任服务
- 明确告警分级（P1/P2/P3）
【一条可复用的排障路径】
- 先看告警面板确认影响范围。
- 用 traceId 找到慢节点。
- 结合该节点指标判断是资源瓶颈还是依赖抖动。
- 回到结构化日志看具体错误上下文。
- 定位后形成复盘与规则沉淀。
【可观测性检查清单】
- 是否统一了日志结构和关键字段？
- 是否定义了核心接口的 SLI/SLO？
- 是否全链路打通 traceId？
- 告警是否有降噪与分级策略？
- 是否能在 10 分钟内定位主要故障点？
- 是否有复盘闭环（问题→规则→防复发）？
下期预告：
《线上事故复盘模板：5步定位与防复发机制》
