可观测性入门：Metrics、Logs、Tracing 为什么必须一起看

系统上线之后，真正困难的部分往往不是“让它跑起来”，而是“当它出问题时，怎样知道到底哪里出了问题”。很多人最开始排障，靠的是日志；再往后会接触监控；再后来又发现仅靠图表和日志都还原不了跨服务链路。这时候你会逐渐意识到，单一视角很难支撑复杂系统排查。

可观测性的价值，不在于把系统数据收集得更多，而在于让我们能够从不同角度还原运行状态，理解异常是如何发生、传播和放大的。Metrics、Logs、Tracing 正是这三种最核心的视角。

为什么“有日志”不等于“可观测”

很多系统上线后都会打日志，所以容易让人误以为日志已经足够支撑排障。但真实情况是，日志更擅长记录离散事件，而不擅长快速回答整体趋势问题。

例如你想知道最近五分钟错误率是否升高、某个接口 P99 延迟是否突然变差、某次慢请求跨了哪些服务，仅靠日志通常很难高效得到答案。

所以日志很重要，但它只是可观测性的一个维度，不是全部。

Metrics 更适合看整体状态和趋势。

它回答的是“系统现在整体怎么样”：QPS 如何、错误率如何、延迟分布如何、资源使用如何、某个依赖是否在持续变差。这类信息适合被聚合、统计和画成时间序列图，所以它非常适合做监控与告警。

Metrics 擅长的是俯视图。

日志更擅长记录具体事件和上下文细节。

它能告诉你某次请求里参数是什么、某个错误具体发生在哪一段逻辑、当时附带了什么上下文、某个异常返回到底长什么样。日志的价值在于细节丰富，特别适合深入分析具体案例。

Logs 擅长的是剖面图。

链路追踪最擅长解决跨服务调用路径问题。

当一个请求会经过网关、用户服务、订单服务、库存服务、支付服务时，如果没有 tracing，你很难快速知道总耗时到底花在哪一段。Tracing 把一次请求拆成多个 span，让你能看到调用顺序、每一跳耗时和异常位置。

Tracing 擅长的是路径图。

因为复杂问题通常不会只停留在一个维度。

你可能先从 metrics 发现错误率升高，再从 tracing 找到是某个下游调用变慢，最后再去日志里看具体是哪类请求、什么参数、什么错误。也可能是反过来：先从日志看到异常，再去指标图验证范围和趋势，再借 tracing 还原调用链。

也就是说，它们不是彼此替代，而是互相补足。

一个常见误区是只把监控当成“看图”，把日志当成“出事再查”，把 tracing 当成“高级组件”。这种割裂理解会让观测体系很难真正发挥作用。

更合理的方式，是从一开始就把三者当成同一件事情的不同视角：系统运行状态需要被聚合观察，也需要被事件记录，还需要被链路还原。

回头想想你最近排过的一次问题，试着回答。

这个练习能帮助你真正体会为什么复杂系统必须建立多视角观测能力。

Metrics、Logs、Tracing 是可观测性的三大核心视角。Metrics 适合看趋势和整体状态，Logs 适合看单点事件和上下文细节，Tracing 适合还原跨服务调用路径。单独使用任何一个都能解决部分问题，但只有把三者联动起来，系统排障和稳定性治理才真正具备足够清晰的视野。