可观测性不是装一个面板

很多团队第一次做可观测性，会先装监控面板、接日志系统、加一堆指标。结果页面很多，真正排障时还是不知道一次请求经过了哪些服务、卡在哪个数据库查询、外部接口耗时多少。

OpenTelemetry 的价值在于统一采集和关联遥测数据。它支持 Trace、Metrics、Logs 等信号，但小团队没必要第一天全部做完。更务实的顺序是先打通 Trace。

为什么先做 Trace

Trace 能回答一次请求的路径问题。用户访问接口后，经过网关、应用、数据库、缓存和外部接口，每一步耗时多少、是否报错，都可以通过链路看到。对于排查慢请求和偶发 500，Trace 的收益通常最快。

Metrics 更适合看趋势，例如 QPS、错误率、延迟分位数、CPU、内存。Logs 适合记录细节，例如错误栈和业务上下文。三者都重要，但 Trace 最容易把一次具体问题串起来。

接入时先定义边界

先选核心入口服务，不要全系统一起改。比如一个 API 服务、一个后台任务、一个数据库访问层。确保每个请求都有 trace id，并且错误日志能带上这个 trace id。这样日志和链路才能互相跳转。

如果项目已有日志系统，第一阶段不要替换它，只要让日志和 Trace 能关联。替换日志平台是另一件事，和链路追踪解耦更稳。

采样策略要保守

小流量系统可以先全量采样，方便观察。流量变大后要调整采样策略，避免观测数据本身拖垮系统。对错误请求、慢请求和关键接口可以提高采样比例，对普通健康检查降低采样。

采样策略要写清楚，否则排查问题时会困惑：为什么某次请求没有链路，为什么某些接口数据很少。

指标和日志怎么补

Trace 稳定后，再补 Metrics。优先做 RED 指标：请求量、错误率、耗时。后台任务可以补执行次数、失败次数、队列积压。数据库可以看连接数、慢查询、锁等待。

Logs 重点是结构化。至少包含时间、级别、服务名、请求路径、trace id、错误类型和业务关键字段。不要只输出一大段无法检索的字符串。

总结

小团队接入 OpenTelemetry，要避免一上来追求大而全。先让 Trace 串起核心请求，再补指标趋势和结构化日志。能在真实故障里帮助定位问题，才算可观测性真正落地。