上周三晚上十点，我在公司楼下的便利店啃关东煮，接到以前同事的电话，声音都带哭腔了。
他们做的电商大促活动刚开卖，支付接口成功率掉了40%，运维翻了三个小时日志，连问题出在哪个环节都摸不清。
我当时叼着鱼籽烧就说了一句，你们是不是根本没上链路追踪？
对面沉默了两秒，说之前听人提过，觉得太重，一直没搭。
哦，这事儿太常见了。
别把链路追踪当运维的专属工具
很多团队对链路追踪的认知还停留在“运维要做监控才用的东西”，跟日常开发排错、业务流程梳理半毛钱关系没有。
真不是。
你想想，一笔订单从用户点下“支付”按钮开始，要经过网关、订单服务、库存服务、支付渠道、消息队列、短信服务，中间任何一个环节超时、报错，你如果没有全链路的调用记录，就只能挨个翻每个服务的日志，靠时间戳去对，运气好俩小时能找到问题，运气不好熬到天亮都摸不着北。
我上次帮那个电商团队搭第一版链路追踪的时候，根本没上来就搞复杂的拓扑分析，就先把核心交易链路的traceId透传串起来——从网关入口生成唯一的traceId，每一次服务调用都把这个id透传下去，不管是同步的HTTP调用，还是异步的消息队列投递，都带着这个id。
就这么个简单的功能，当时他们查一个“支付成功但没收到短信”的问题，之前要翻三个服务的日志凑线索，现在直接输入traceId，三秒就能看到是短信服务挂了，根本不用折腾。
说实话，很多人对链路追踪的期待值太高，觉得要做的像大厂那样，能看到全公司所有服务的调用拓扑，能自动发现服务依赖的异常，要我说，能把你最痛的那几个核心链路的日志串起来，就已经解决80%的排错问题了。
别踩那些看起来很专业的坑
坑真的太多了。
第一个最常见的，就是硬套开源组件的默认配置。不管是Jaeger还是Zipkin，默认配置都是全量采集所有调用的链路数据，你要是个几十台服务器的小团队，这么跑不出三天，存储磁盘就能给你跑满，查询页面卡的像加载慢的老网站，最后没人用，直接把系统关了，还反过来吐槽链路追踪没用。
第二个坑更蠢——traceId透传断了。
我自己团队去年就踩过这个坑。当时查优惠券发放延迟的问题，卡了快俩小时，才发现是Kafka的消费端没把消息头里的traceId捞出来，传给下游的优惠券计算服务，链路直接断在消息队列那一段，查的时候前面的链路都有记录，后面的全没了，跟断了线的风筝似的。
还有个误区，觉得只有微服务架构才需要链路追踪。真不是。哪怕你现在还是单体应用，只要你接了第三方支付、短信服务、对象存储这些外部依赖，只要一笔业务流程跨了好几个系统，就值得上链路追踪——不然你哪天发现支付回调没收到，都不知道是第三方没推，还是你自己的接口挂了。
哦对，还有采样率的事儿。别全量采。核心链路设个10%的采样率就够，非核心的调用比如后台管理系统的查询接口，设成0.1%甚至直接关了都行。真出线上问题的时候，你临时把采样率拉到100%，等问题过了再调回来，平时没必要烧存储和计算的钱。
真要落地别贪大求全
我见过太多团队，搭链路追踪的时候一上来就列了几十项需求：要前端页面加载的链路，要数据库慢查询的链路，要消息队列的全量链路，要服务依赖的自动告警，折腾了俩月，系统是搭起来了，但是没人用——因为查一次链路要等半分钟，大家排错还是习惯翻日志。
真没必要。
你就从最痛的那三个链路开始：支付链路、下单链路、用户登录链路。先把这三个链路的traceId从入口到出口透传通，哪怕一开始连可视化UI都不用做，就把日志里的traceId字段统一格式，能通过grep命令把同一个traceId的所有日志都捞出来，就已经解决80%的排错问题了。
不过话说回来，等大家真的用起来了，你再慢慢加功能：比如把慢调用的链路标红，比如把错误的调用打个标签，比如自动生成核心链路的调用耗时统计，这些都是水到渠成的事儿。
还有个容易被忽略的细节，搭完系统别往群里一丢就不管了。你得逼着大家改习惯，以后出线上问题，第一反应是查链路追踪，不许上来就挨个翻服务日志。用个两三周，大家尝到甜头了，根本不用你催——毕竟谁愿意熬到半夜翻日志啊。
上次那个请我吃小龙虾的朋友，后来跟我说，第二次大促的时候，同样的支付接口成功率波动，五分钟就定位到是库存服务调Redis超时，根本不用像上次那样熬到三点。他说之前总觉得链路追踪是个花架子，现在才知道，这玩意儿是真能帮大家少加班的东西。
哦对，最后补一句，别总想着抄大厂的作业。人家日活几个亿，有专门的团队维护可观测系统，你一个小团队，能把核心链路的问题快速定位到，就够了。