导读：有一天我们接到这样一条客户投诉“你们的收银软件最近特别慢，严重影响我们的收银效率，再不解决我们就不用了”，我相信大家应该都遇到过这种问题，即使现在没遇到，将来一定会遇到的，那遇到了怎么办呢？就这个话题我们今天一起来聊一聊。
关键词：分布式，链路追踪
靠人终究靠不住
不知道大家是怎么处理开头提到的那种问题的呢？最简单粗暴的办法就是把相关人员集中到一个会议室里面对数据，怎么对呢？
客户端开发人员：我查了日志，客户端的请求过程一共用了5s，请求是从几点几分几秒发起的，你们查下服务端的日志；
交易系统开发人员：我这边是几点几分几秒收到的请求，交易系统一共花了4s多一些，其中调用支付网关花了将近4s，网关那边看下日志吧；
网关开发人员：我这边是几点几分几秒收到的请求，网关一共花了3s多一点，大部分时间都花在了调用第三方上；
估计大多数人最开始都是这么处理此类问题的，简单粗暴。但如果三天两头给你来这么一下子你还受得了吗？每天给你几百个上千个订单号让你对数据，你还能抽时间写代码吗?估计连带薪上厕所的时间都没了吧。最后这个问题可能传到了领导那里，领导一般喜欢要全局报表数据，你怎么给他出这个报表？是不是束手无策，突然有点想换工作了，哈哈。我们还真是接到过这种需求，一堆人在那里awk然后就没有然后了。
“当一件事情成为一件常态，那意味着我们可能需要一件工具来解放自己了，靠人终究是靠不住的”，就在这种背景之下我们决定引入一个调用链追踪的工具来解放我们，也就是今天的主角jaeger。关于jaeger，推荐去
RPC框架如何集成：一般RPC框架都会提供一些扩展点让使用者来做一些框架集成的事情，拿dubbo来说可以采用Filter和隐示传参数的方式来实现请求上下文的传递；
外部调用如何集成：有一些调用是基于sdk或者
2.如果有满足条件的数据右边会展示出结果
上面图中分别展示了两条支付的调用链路，一条成功了，一条失败了，你可能会问：jaeger是怎么判断成功失败的呢？简单来说就是通过特殊的标签，推荐阅读这篇文章，加深对标签的理解