大的互联网公司都有自己的分布式跟踪系统，比如Google的Dapper，Twitter的zipkin，淘宝的鹰眼，新浪的Watchman，京东的Hydra等，下面来简单分析。
Google的DrapperDapper是Google生产环境下的分布式跟踪系统，Dapper有三个设计目标：
低消耗：跟踪系统对在线服务的影响应该做到足够小。
应用级的透明：对于应用的程序员来说，是不需要知道有跟踪系统这回事的。如果一个跟踪系统想生效，就必须需要依赖应用的开发者主动配合，那么这个跟踪系统显然是侵入性太强的。
延展性：Google至少在未来几年的服务和集群的规模，监控系统都应该能完全把控住。
处理分为3个阶段：
①各个服务将span数据写到本机日志上；
②dapper守护进程进行拉取，将数据读到dapper收集器里；
③dapper收集器将结果写到bigtable中，一次跟踪被记录为一行。
阿里-鹰眼关于淘宝的鹰眼系统，主要资料来自于内部分享：
鹰眼埋点和生成日志：
如何抓取和存储日志，记录本地文件，使用额外的后台进程定期（时间间隔小）收集日志。这种方式的优势在于对应用的性能影响小，方便做消息堆积；但是需要在每台业务server上都部署并管理日志收集agent，运维量比较大。
鹰眼的实现小结：
注意Dapper与Eagle eye都不开源。
阿里EDAS+ARMS的立体化监控体系通过阿里云提供的EDAS结合ARMS可以打造立体化监控体系，其中EDAS用于应用管控层面，用于控制链路和应用；而ARMS更关注业务运营层面，如电商交易、车联网、零售；实际上，监控需要全方位关注业务、链路、应用、系统，通过ARMS与EDAS相互补全，形成了立体化监控体系。
架构简单。可以实现一个Trace系统的所有功能。架构如下图所示：
Transaction是最重要的事件消息类型，适合记录跨越系统边界的程序访问行为,比如远程调用，数据库调用，也适合执行时间较长的业务逻辑监控，记录次数与时间开销。Transaction可嵌套。
跨服务的跟踪功能与点评内部的RPC框架集成，这部分未开源。
客户端接入方式对于方法调用、sql、url请求等粒度较小的兴趣点，需要业务人员手写代码实现。
日志收集方式直接向日志收集器发异步请求（有本地内存缓存），一台客户端会连向几个服务端，当一个服务端出问题，数据不会丢失。
当所有服务端都挂掉，消息会存入queue，当queue满了，就丢弃了，没有做数据存储本地等工作。
全量采样，系统繁忙的时候对性能影响较大（可能达到10%的影响）
最后一个稳定版本是2014年1月，之后已经失去维护。
京东-hydra与dubbo框架集成。对于服务级别的跟踪统计，现有业务可以无缝接入。对于细粒度的兴趣点，需要业务人员手动添加。架构如下：