分布式链路追踪系统深入理解

背景

对于普通系统或者服务来说，一般通过打日志来进行埋点，然后再通过elk进行定位及分析问题，更有甚者直接远程服务器，使用各种linux命令单手操作查看日志，说到这，我也没摆脱这种困境。那么随着业务越来越复杂，企业应用也进入了分布式服务化的阶段，传统的日志监控等方式无法很好达到跟踪调用，排查问题等需求。

总之，在各种服务之间调用：

1. 如何快速发现问题？
2. 如何判断故障影响范围？
3. 如何梳理服务依赖以及依赖的合理性？
4. 如何分析链路性能问题以及实时容量规划？

如何在分布式服务进行日志监控呢？首先大家会想到分布式链路追踪系统，说到这，就得讲 OpenTracing 规范，OpenTracing 是一个轻量级的标准化层，它位于应用程序/类库和追踪或日志分析程序之间。详细介绍见 opentracing文档中文版。

在谷歌论文《 Dapper，大规模分布式系统的跟踪系统》的指导下，许多优秀的APM应运而生。分布式追踪系统发展很快，种类繁多，给我们带来很大的方便。但在数据采集过程中，有时需要侵入用户代码，并且不同系统的 API 并不兼容，这就导致了如果您希望切换追踪系统，往往会带来较大改动。OpenTracing为了解决不同的分布式追踪系统 API 不兼容的问题。

##技术调研指标

面对各种链式追踪系统开源，我们要如何选择：

我们主要关注在请求处理期间各个调用的各项性能指标，比如：吞吐量（TPS）、响应时间及错误记录等。

1. 吞吐量，根据拓扑可计算相应组件、平台、物理设备的实时吞吐量。
2. 响应时间，包括整体调用的响应时间和各个服务的响应时间等。
3. 错误记录，根据服务返回统计单位时间异常次数。

全链路性能监控 从整体维度到局部维度展示各项指标，将跨应用的所有调用链性能信息集中展现，可方便度量整体和局部性能，并且方便找到故障产生的源头，生产上可极大缩短故障排除时间。

我们除了性能指标之外，我们也需要链式追踪系统拥有以下功能：

1. 请求链路追踪，故障快速定位：可以通过调用链结合业务日志快速定位错误信息。
2. 可视化： 各个阶段耗时，进行性能分析。
3. 依赖优化：各个调用环节的可用性、梳理服务依赖关系以及优化。
4. 数据分析，优化链路：可以得到用户的行为路径，汇总分析应用在很多业务场景。

当然这些要求可能有些过分了，但我们换着自己的目标进行技术选型。

接下来我们主要来介绍四种常见的开源链式追踪系统，除了一些背景、所使用技术栈、支持的技术栈&#