如果线上系统突发故障，而你只能保留一种排查手段，你会选择日志、指标，还是链路追踪？这个问题，几乎每次技术团队讨论运维排障时都会被重新提起。
在技术团队中，这个问题经常引发激烈争论。开发同学通常更信任日志——因为日志里能直接看到异常堆栈和业务细节；运维同学则习惯先扫一眼指标——指标能最快揪出异常信号；而做微服务较多的团队，总觉得链路追踪不可或缺——服务一多，请求卡在哪里根本没法靠猜。
其实这三个工具就像三种不同的取景框：指标告诉你“系统哪里不对劲”，链路追踪告诉你“请求卡在了哪一段”，日志则告诉你“当时到底发生了什么”。
实际的故障定位过程中，很少依赖单一工具解决问题，关键要看团队能否把这三类信息有效串联起来。
指标：最适合发现问题，但解释不了全部原因
绝大多数线上故障，最先暴露在指标上。
比如接口成功率突然下降、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服务团队有时会参与基础支撑工作，但企业不一定非要引入外部团队。关键是要有人长期负责这件事：指标有没有失效，日志还能不能查，链路是否断了，告警是否准确，故障复盘有没有改进。可观测性如果没人运营，时间久了就会变成摆设。
维护工作不像研发新功能那样显眼，但对企业来说非常实际。很多故障定位慢，并不是缺一个新工具，而是缺少持续维护的人、清晰的流程，以及对现有系统足够熟悉的团队。
结语
日志、指标、链路追踪，哪个对故障定位最有用？
如果非要排个顺序，我会这样看：指标适合发现问题，链路追踪适合缩小范围，日志适合确认原因。三者不是替代关系，而是接力关系。
真正高效的故障定位，不是靠某一个工具解决全部问题，而是让指标、链路和日志能互相关联，让技术团队在故障发生时少猜一点、少绕一点、少争一点。
系统越复杂，越不能只靠经验排障。把可观测性建设成日常工程习惯，比临时补工具更重要。
