如果线上系统出故障，只能保留一种排查手段，你会选日志、指标，还是链路追踪？
这个问题在技术团队里常被讨论。开发同学通常更相信日志，因为日志能看到异常堆栈和业务细节；运维同学更习惯先看指标，因为指标能最快发现异常；做微服务比较多的团队，又会觉得链路追踪离不开，因为服务一多，请求到底卡在哪里很难靠猜。
其实这三个东西更像三个不同角度：指标告诉你“系统哪里不正常”，链路追踪告诉你“请求卡在哪一段”，日志告诉你“当时到底发生了什么”。
真正的故障定位，往往不是靠某一个工具，而是看团队能不能把三类信息串起来。
指标：最适合发现问题，但解释不了全部原因
大多数线上故障，最先暴露在指标上。
比如接口成功率下降、P99 延迟升高、CPU 飙高、磁盘 IO 等待变长、数据库连接数打满、消息队列堆积。这些现象如果能被监控及时捕捉，团队至少可以在用户大规模反馈之前发现异常。
举个常见场景。
某电商系统在活动开始后，订单接口响应时间突然从 200ms 涨到 3 秒。用户开始反馈下单慢。如果没有指标，团队可能只能等客服反馈，再去逐个系统排查，整个过程会很被动。
但如果基础指标比较完整，排障入口会清楚很多。你可以先看到订单接口延迟上升，再看数据库慢查询是否增加，Redis 命中率有没有下降，消息队列是否堆积，应用实例的 CPU 和内存有没有异常。几分钟内，基本能判断问题是在应用层、数据层，还是某个外部依赖上。
指标的价值在于，它能快速回答两个问题：系统是不是出问题了？问题大概出在哪一层？
但指标也有明显短板。它通常只能告诉你“异常存在”，很难告诉你“异常为什么发生”。
比如 CPU 高，可能是代码死循环，也可能是流量突增、GC 频繁，或者某个依赖超时导致线程堆积。接口慢，也可能是数据库慢、网络慢、缓存失效，或者下游服务变慢。光看指标，很容易停留在猜测阶段。
所以指标很适合作为故障定位的第一入口，但不能只靠指标完成全部分析。
链路追踪：适合缩小范围，尤其是微服务场景
在单体应用时代，一个请求从入口到数据库，路径相对清楚。到了微服务架构，一个用户请求可能要经过网关、用户服务、订单服务、库存服务、支付服务、风控服务，还会调用缓存、数据库和第三方接口。
这时候链路追踪的价值就很明显。
它能把一次请求经过的服务、接口耗时、调用关系展示出来。比如一次下单请求总耗时 5 秒，通过链路追踪可以看到，网关只用了几十毫秒，订单服务和库存服务也正常，真正耗时的是风控接口，单次调用用了 4 秒多。
这样一看，问题就不是订单服务本身，而是风控依赖变慢。排查方向会清楚很多，团队之间也少一些互相猜测
链路追踪特别适合处理请求路径长、服务调用复杂、偶发慢请求、下游依赖不稳定这类问题。尤其在多个团队共同维护一个业务链路时，它能帮助大家先把责任边界理清楚。
不过链路追踪也不是万能的。
不少团队接入链路追踪后，用得并不好。常见情况是服务没有全部接入，Trace ID 没有贯穿，异步任务断链，采样率设置不合理，关键业务字段没有记录。结果排障时链路图看起来挺完整，但真正关键的一段缺失了。
还有一种情况是，链路追踪只能告诉你“慢在这里”，但不能直接告诉你“为什么慢”。比如它显示某个接口耗时 3 秒，原因可能是 SQL 没走索引，也可能是线程池满了，还可能是远程调用重试导致耗时增加。这时候仍然要回到日志和更细的指标。
所以链路追踪的作用，是帮助团队快速缩小范围，而不是替代日志和指标。
日志：最接近真相，但也最容易变成噪音
日志是很多开发最熟悉的排障手段。因为日志里通常有错误堆栈、请求参数、业务状态、异常分支、接口返回值。真正要解释故障原因，很多时候还是要看日志。
比如用户反馈“支付成功但订单状态没更新”。指标可能显示支付回调接口成功率正常，链路追踪也显示请求没有明显超时。但打开日志后发现，某一批回调请求因为订单状态已经变更，被业务逻辑判断为重复消息，直接跳过了后续处理。
这种问题不一定能靠指标看出来，链路追踪也只能看到调用成功，只有日志能解释业务逻辑当时做了什么判断。
日志适合回答更细的问题：某个请求具体报了什么错，当时传入参数是什么，代码走到了哪个分支，下游接口返回了什么，业务状态为什么没有变化，异常到底是系统问题还是数据问题。
但日志最大的问题是，信息太多，质量参差不齐。
有的系统日志打得太少，出问题时只有一句“处理失败”；有的系统日志打得太多，一次请求刷几百行，真正排查时反而找不到重点。还有一些系统没有统一 Trace ID，日志散落在不同服务里，只能靠时间戳人工拼接。
日志还有一个容易被忽视的问题：安全。为了排障方便，有些系统会把手机号、身份证号、Token 、完整请求体都打出来。短期看确实方便，但长期看会带来数据泄露风险。比较稳妥的做法是保留关键上下文，同时对敏感字段做脱敏处理。
所以日志不是越多越好，而是要能在关键节点留下可读、可查、可关联的信息。
真实故障里，三者通常是接力关系
如果只讨论“哪个最有用”，容易陷入口水战。放到真实故障里，它们通常是接力关系。
第一步一般是看指标，确认影响范围。比如是全站变慢，还是某个接口变慢；是所有实例都有问题，还是只有某台机器异常；是应用层问题，还是数据库、缓存、网络等基础资源异常。
第二步看链路追踪，缩小问题路径。确认请求卡在哪个服务、哪个依赖、哪个接口。尤其是微服务、分布式系统、多云或混合架构下，链路追踪能减少很多无效沟通。
第三步看日志，解释具体原因。找到对应 Trace ID 或请求标识，查看当时的异常堆栈、业务参数、返回码、重试记录和状态变化，最后结合代码和变更记录判断根因。
举个例子。
某企业内部审批系统突然大量超时。指标显示审批接口 P99 延迟升高，但数据库 CPU 正常，应用实例 CPU 也不高。链路追踪显示慢请求集中卡在“组织架构查询服务”。继续看日志发现，组织服务最近加了一个权限判断逻辑，某些部门层级较深的用户会触发递归查询，接口从几十毫秒变成几秒。
这个故障如果只看指标，会觉得“审批接口慢”；只看链路追踪，会知道“组织服务慢”；但只有日志和代码上下文结合起来，才能确认是新逻辑导致的递归查询问题。
成熟一点的团队不会问“只要哪一个”，而是会问“怎么把三者关联起来”。
排障效率差距，常常来自基础规范
很多团队工具买了不少，故障定位还是慢，问题不一定出在工具，而是出在基础规范。
比如指标命名不统一，告警没人认领；日志没有 Trace ID，跨服务查不动；链路追踪只接了一半，关键服务缺失；告警阈值长期不调，误报太多；业务指标没有沉淀，只能看 CPU、内存；故障复盘没有形成改进项，下次继续踩坑。
可观测性不是装几个组件就结束了。它更像一套长期运行的工程习惯，包括埋点规范、日志规范、告警分级、值班流程、故障复盘、容量评估和变更管理。
尤其是业务系统越来越复杂后，很多问题都不是单点故障，而是“多个小问题叠加”。比如一次发布改变了调用逻辑，缓存命中率下降，数据库慢查询增加，接口超时重试又放大了流量。如果没有指标、链路和日志的关联，排查会非常耗时间。
不同阶段，建设重点也不一样
如果团队刚开始建设可观测性，不建议一上来追求大而全。传统单体应用可以先把基础指标和关键日志做好，比如接口耗时、错误率、数据库连接、慢查询、异常堆栈和关键业务状态。
如果已经进入微服务阶段，就要尽早补链路追踪，尤其是网关、核心服务、异步消息、外部依赖这些位置。服务一多，故障责任边界会越来越模糊，没有链路追踪会很难排。
如果企业系统已经有一定规模，还要开始关注业务指标。比如订单成功率、支付回调延迟、审批积压量、库存同步失败数、工单处理时长。这些指标比单纯的 CPU、内存更接近用户体验。
对于跨团队协作的系统，还要建立故障处理流程。谁先响应，谁判断影响面，谁通知业务，谁回滚变更，谁写复盘，都需要提前说清楚。否则工具再多，故障现场还是会乱。
企业落地时，别忽视持续运维能力
从一些企业项目 的实际情况看，日志、指标、链路追踪真正用起来，难点往往不只是技术接入，而是后续维护。
很多系统一开始也做了监控和日志，但过一段时间后，告警没人调、链路没人补、日志格式越来越乱，最后就变成“平时有数据，故障时不好用”。这类问题在系统多、历史包袱重、人员变动频繁的企业里比较常见。
在这类场景里，外部 IT 服务团队有时会参与基础支撑工作。我了解到，江苏立维这类长期服务企业 IT 环境的团队，在一些项目中更多承担的是运行维护和现场协同角色。比如配合梳理系统环境，整理告警规则，跟进日常故障，协助数据库和云资源排查，帮助企业把监控、日志、链路这些能力放到真实运维流程里。
这类工作不太像研发新功能那样显眼，但对企业来说很实际。很多故障定位慢，并不是缺一个新工具，而是缺少持续维护的人、清晰的流程，以及对现有系统足够熟悉的团队。
当然，企业也不一定非要引入外部团队。关键是要有人长期负责这件事：指标有没有失效，日志还能不能查，链路是否断了，告警是否准确，故障复盘有没有改进。可观测性如果没人运营，时间久了就会变成摆设。
结语
日志、指标、链路追踪，哪个对故障定位最有用？
如果非要排序，我会这样看：指标适合发现问题，链路追踪适合缩小范围，日志适合确认原因。三者不是替代关系，而是接力关系。
真正高效的故障定位，不是靠某一个工具解决全部问题，而是让指标、链路和日志能互相关联，让技术团队在故障发生时少猜一点、少绕一点、少争一点。
系统越复杂，越不能只靠经验排障。把可观测性建设成日常工程习惯，比临时补工具更重要。
