很多团队的可观测性建设是“出了问题才补”的：先上了监控告警，性能问题出现了加链路追踪，合规要求来了再补日志。结果是三套系统各管一段，排障时仍需人工把三份数据对起来。可观测性的难点不在采集，而在三者在同一套标签体系下能被关联。
一、三类信号各自解决什么问题
| 信号 | 回答的问题 | 成本特征 |
|---|---|---|
| 指标 Metrics | 系统现在正常吗？趋势如何？ | 存储便宜、采集开销低，适合长期保留 |
| 日志 Logs | 那一刻到底发生了什么？ | 体量大、存储贵，需分级与采样 |
| 链路 Traces | 慢在哪一段？调用了哪些下游？ | 采集有开销、需要采样策略 |
典型的排障路径应该是：告警由指标触发 → 用链路追踪把问题收敛到某个服务与某个接口 → 在日志里定位到具体异常。如果这三步之间需要人工拼时间戳，说明体系还没有真正建成。
二、统一标签体系是地基
关联的前提是三个系统使用同一套语义标签。建议至少统一下面几类：
- 服务标识：服务名、实例 ID、版本号。版本号尤其重要，灰度发布时的异常定位全靠它。
- 环境与地域：环境（prod/staging）、可用区、集群。
- 请求标识：TraceId 与 SpanId，以及来自网关的 RequestId。
- 业务维度：租户 ID、关键的资源类型。注意不要把高基数维度（如用户 ID、订单号）写进指标标签，会直接导致时序库膨胀。
高基数是可观测性成本失控的头号原因。经验规则：指标标签的组合数应控制在几万量级以内，超出部分应放进日志或链路属性里。
三、采样：控制成本的关键决策
链路追踪全量采集在生产环境几乎不可行。可选的几种策略：
- 头部采样：在入口处按比例决定是否采样，实现简单，但会丢掉低概率的慢请求。
- 尾部采样：先收集完整链路，再按规则决定是否保留。可以保证错误与慢请求被保留，是生产环境的推荐做法，代价是需要缓冲与集中决策组件。
- 混合：入口按较低比例头部采样，同时开启“错误全留、超阈值全留”的尾部规则。
日志方面，建议按级别分级：ERROR 与关键业务日志全量保留并延长保留期，DEBUG 仅在按需开启时采集。结构化 JSON 日志应作为默认要求，否则后续检索只能靠正则，成本极高。
四、告警设计：从“有告警”到“有用告警”
告警做不好会反过来伤害可观测性：告警太多，团队就会集体忽略。三条原则：
- 基于症状而非原因。告警“下单接口错误率超过 1%”，而不是“CPU 超过 80%”。后者只是可能的原因。
- 区分级别与责任。P0 必须有人立即响应并明确值班，P2 可以只进日报。没有责任人的告警等于日志。
- 用燃烧率而非瞬时值。基于错误预算的燃烧率告警能有效减少毛刺导致的误报，比单点阈值稳定得多。
五、落地节奏建议
不建议一开始就追求全覆盖。可行的路径是：
第一步，把核心链路的指标与告警补齐，确保“出事能知道”；第二步，接入链路追踪并开启尾部采样，把“知道出事了”推进到“知道慢在哪”；第三步，统一日志格式与保留策略，完成三者关联；第四步，才开始做容量预测、成本归因这类进阶分析。
衡量可观测性是否有效，可以用一个很实际的指标：从告警响起到定位到根因的平均耗时（MTTI）。这个数字下降，说明体系真的在起作用。
