分布式可观测性
用途：拆完之后定位“请求慢在哪、错在哪台服务”时查阅
三条支柱
「三条支柱」小节链接| 支柱 | 回答什么 | 典型形态 |
|---|---|---|
| Metrics（指标） | 系统整体是否健康、趋势如何 | 计数器、直方图、分位数；Prometheus + Grafana |
| Tracing（链路） | 单个请求经过了哪些服务、耗时分布 | TraceId/SpanId 贯穿；OpenTelemetry + Jaeger/Tempo |
| Logging（日志） | 具体发生了什么、上下文是什么 | 结构化 JSON 日志 + 集中检索（Loki/ES） |
三者必须能互相跳转：从告警下钻到链路，从链路定位到日志。做不到时排障时间会成倍增加。
必备的最小工程约定
「必备的最小工程约定」小节链接- TraceId 贯穿：HTTP 头、消息属性、线程池与异步任务、定时任务都要传递；日志必须打印 TraceId。
- 统一标签：服务名、环境、版本、实例、接口名、错误码作为标准维度，避免每个团队自造。
- 业务标识可检索：订单号、流水号等进入日志与 span 属性，支持“按业务号看全链路”。
- RED 指标：每个入口统计 Rate（请求量）、Errors（错误）、Duration（延迟分布，用 P95/P99 不用均值）。
- 资源指标：CPU、内存、GC 停顿、线程池队列、连接池、下游调用耗时。
- 采样策略：高流量场景用尾部采样或错误优先采样，保证异常链路一定被记录。
告警设计
「告警设计」小节链接- 基于症状（用户可感知的错误率与延迟）而非原因（CPU 高）告警。
- 分级：紧急（用户受影响）需立即响应；警告（趋势异常）允许工作时间处理。
- 每条告警必须可执行：附排查链接（看板/日志查询/最近变更）。
- 抑制与聚合：同一故障引发的连锁告警要收敛，避免噪声导致麻木。
变更可追溯
「变更可追溯」小节链接多数故障来自变更。要求：发布事件写入统一时间线（在图上标注 deploy）、配置变更留痕、特性开关状态可查。排障第一问应是“最近改了什么”。
开源参考
「开源参考」小节链接OpenTelemetry（采集标准与 SDK）、Prometheus + Grafana（指标）、Jaeger / Tempo（链路）、Loki / Elasticsearch（日志）、Alertmanager（告警路由）、Kiali（服务网格可视化）。
常见误区
「常见误区」小节链接| 误区 | 修正 |
|---|---|
| 只有服务器指标没有业务指标 | 补 RED 与关键业务量（成功率、积压、对账差异） |
| 用平均值看延迟 | 用 P95/P99，长尾才是问题 |
| 日志无结构、无 TraceId | 统一结构化字段与链路上下文注入 |
| 采样丢弃错误链路 | 错误与慢请求强制保留 |
| 看板很多但无告警闭环 | 每条告警对应一个可执行动作 |
| 异步任务链路断链 | 消息属性传递 TraceId，任务侧续接 |
延伸阅读
「延伸阅读」小节链接- Cindy Sridharan《NetOps: Making the Unknowable Knowable》与其分布式系统文章合集
- OpenTelemetry 官方规范（语义约定部分）
- Google SRE Book 第 6 章（监控与告警）