一切的开始
古早的时候，没人需要分布式追踪系统。大家系统架构简单，功能直来直去，有问题就看日志、查问题。
后来，微服务流行起来。之前的模式，被称作“单体架构”。微服务粒度更小了，以前一个接口做的事，现在要拆散成很多部分，再通过相互调用组合到一起。系统更瘦了，但是管理起来更难了。
当我有 10 个微服务时，出了故障还可以排查。如果有成千上万个微服务呢？随着时间发展，微服务之间的依赖会越来越复杂，一个接口背后可能是几十上百个微服务调用，没人能搞懂了。
大家意识到，需要一个能展示整条调用链路情况的辅助系统。
Google Dapper
这时候，Google 公开了一篇论文 Dapper - a Large-Scale Distributed Systems Tracing Infrastructure，介绍他们的分布式追踪技术。这篇文章提出了科学的分布式追踪模型，仿佛一盏指路明灯，此后几乎所有实现，都遵循这个模型。
基于这篇论文，有了 Zipkin(Twitter 开源), 有了 OpenTracing。国内阿里鹰眼，也在概念上有借鉴。
分布式追踪系统
一般而言，分布式追踪系统分为三部分，采集、上报、落盘与分析。
采集: 对于已经存在大量系统，在代码中进行改造，工作量将相当可观，不现实。明智做法，是从中间件着手，力求侵入更小、开发者无感知。如果是 dubbo 调用，最合适是统一升级 dubbo jar 包。
上报：先把日志打印到本地，然后公共 agent 采集上报。
落盘与存储：数据采集上来后，可以做很多事情。最简单的，放到 HBase + ElasticSearch，支持按 traceId 搜索。复杂点，接入流计算引擎，实时计算相关指标。
我真的需要它吗
直说我的看法：
如果你的系统调用链深度顶多三层，依赖外部系统才一两个，常规日志监控手段足矣，分布式追踪系统并不是必须品。
如果当前你的系统已经按微服务组织起来，但没有使用统一维护的中间件，那应该先改造现有系统，把中间件收敛起来，再统一升级。
不错的参考资料
分布式跟踪系统（一）：Zipkin的背景和设计 https://blog.csdn.net/manzhizhen/article/details/52811600