原创文章，转载请注明出处。由于本人水平有限，文中错漏之处在所难免，希望大家多多批评指正。本文的内容过多，我们分成四篇聊，此为第一篇。
最近一段时间一直在忙着接分布式追踪系统，每天噼里啪啦敲着代码玩得还是很开心的。这里要感谢敏哥、宇飞、祥哥、金俊、媛媛姐对我的支持和帮助，尤其要感谢金俊同学对系统运维问题的专业解答，感谢媛媛姐超级有耐心的帮助调试接入过程中遇到的各种问题。目前系统已经上线，通过一段时间的观察，没有出现丢失数据、崩溃等异常情况，运行稳定。趁着告一段落，记录下自己学到的知识点，聊一聊这期间遇到的一些问题、思考和自己的一些感受，也为其他考虑使用追踪系统的团队提供一些参考。
先说说背景业务：我们是做旅游出行产品的，主要涉及的业务有机票、火车票、汽车票、用车。
架构：前后端分离，我们的后端整体采用服务分层架构，服务间使用自研的RPC和HTTP框架通信。
技术栈：后端主要是Java和PHP。
部署：分布式部署，使用Docker部署在私有云上。
运维：运维同学自研了一些工具，有CI/CD工具，Docker日志的界面化查询工具，线程堆栈dump工具等等。
每一个团队都会希望研发的产品能够带给用户更多的便利，被更多的用户所喜爱，我们也是一样，用户的肯定会带给我们极大的动力。而用户的增长，使用率的上升自然也会导致访问量越来越大，带来的问题自然也就多了起来。很多的用户又会希望产品的功能更加的丰富，能够不断的满足他们新的需求，这样涉及到的服务也就会越来越多，问题的复杂度自然也就高了。数量和复杂度两个维度的增长给排查定位工作带来了很大的难度。在预防和解决线上问题，保障用户使用体验的的过程中，我们的团队也不可避免的遇到了很多麻烦，先来看看有哪些问题，带着问题再去寻找答案。
技术支持的痛点我们处于整个架构的中间层级，如图1所示，上接前端请求，下连各个业务方的服务，自身需要整合不同业务方的接口，为前端提供一个完整的功能入口。处于这个层级，基本就是排查所有用户问题的最前线了，实际上大部分的线上问题都会先分配给我们。而我们就很尴尬，尴尬的点在于这个接口既有我们自己的业务代码，也有处理依赖服务方接口的代码，虽然从以往的排查经历中看，大部分的问题都是出在服务方的，但是还是没啥底气支撑我们直接把问题分配给服务方。导致每一个问题都需要我们先排查，定位它是是哪一方的问题。排查问题又是一个很耗时的事情，尤其在业务复杂、涉及到多个部门的时候，很有可能需要两三天的时间才能定位到问题的原因，我们的人力又很有限，这就让我们有点头疼。那有没有什么方法可以缩短定位问题的时间？至少能快速的判断出问题出现在哪一个部门、哪一个服务方，这样可以直接将问题精准的分配到对应的责任方，既能加快处理线上问题的速度，也能大大减少我们的工作量。