要解决的问题

1. 如何记录请求经过多个分布式服务的信息，以便分析问题所在？
2. 如何保证这些信息得到完整的追踪？
3. 如何尽可能不影响服务性能？

追踪

当用户请求到达前端A，将会发送rpc请求给中间层B、C；B可以立刻作出反应，但是C需要后端服务D、E的配合才能应答

一个简单有用的请求追踪应该包含发送、接收消息的消息标识符、时间戳。为了关联给定发起者的这些记录，在此有黑盒和基于标注的监控模式

• 黑盒：假定并没有除了以上记录之外的额外信息，使用统计回归进行推断关联性。

  更加轻量化，但是需要更多数据以保证准确性

• 基于标注：基于应用或者中间件去显式采用全局标识符标注这些记录，从而关联。

  需要代码侵入，但可以将之植入到通用组件中

追踪信息

• span: 链路追踪的基本单元，以追踪树结构串联起来。
• trace id: 对于每一个请求链路上的span都有唯一的trace id

度量点

• 当一个线程处理追踪控制路径时，dapper附加追踪上下文到本地线程储存中
• 当异步处理时，dapper保证异步回调将会储存追踪上下文到创建者，并且当回调调用时将会关联到适当的线程
• 植入到rpc通信中

采样收集

1. 写入span数据到本地log文件
2. dapper拉取各主机数据
3. 最终写入到dapper bigtable

bigtable中每个trace置于表行，每个span置于表列

收集模式

Dapper采用out-of-band进行追踪收集，主要因为

• in-band收集模式追踪数据在rpc响应头中，会动态影响应用网络
• in-band收集模式假定rpc调用完美嵌套的，

in-band: 将追踪数据随着调用链进行传送

out-of-band: 通过其他链路进行追踪

收集方式

• 基于日志：也即将trace、span等信息直接输出到应用日志中，而后汇集所有节点日志，最后推断出完整调用关系

  对网络消息没有侵入，对应用也只有少量侵入，但日志本身并不追求绝对连续与一致性，这意味着追踪结果可能并不准确

• 基于服务：通过某些手段给目标应用注入追踪探针。探针在结构上可视为一个寄生在目标服务身上的小型微服务系统，它一般会有自己专用的服务注册、心跳检测等功能，有专门的数据收集协议，把从目标系统中监控得到的服务调用信息，通过另一次独立的 HTTP 或者 RPC 请求发送给追踪系统。

  因此，基于服务的追踪会比基于日志的追踪消耗更多的资源，也有更强的侵入性，换来的收益是追踪的精确性与稳定性都有所保证，不必再依靠日志归集来传输追踪数据。

• 基于边车代理：用于服务网格，应用透明、语言无关、独立通道

性能损耗如何降低？

追踪系统的成本可分为追踪数据生成，追踪数据收集以及追踪数据分析组成。而收集和分析在紧急的时候是可以关闭的，因此追踪生成就成了最关键的损耗

而追踪生成的损耗最关键的则是运行时库创建和销毁span以及annotation，和写入log到硬盘中

写入硬盘合并了多个日志文件写入操作，并异步进行，有效地减少了由于写入log到硬盘造成的性能损耗

此外，dapper还发现

从图中可以看到随着采样频率的降低，延时和吞吐量都有性能上的提升。尤其是1/1024的频率下，对吞吐量的影响只有万分之六，而对延时的影响也只有千分之二。

这意味着是不是可以降低采样频率来降低对性能的影响呢？事实上是可以的，即使是降低到1/1024对于大型系统而言仍然有足够的数据进行追踪。

除了对于延时、吞吐量的影响，对于数据储存规模的影响，dapper也做了相应控制。

其使用二阶采样控制数据量大小。通过将traceID hash为0到1之间的度量z，若z小于采用参数，则将采样该数据，写入到bigtable中

总结

1. 如何记录请求经过多个分布式服务的信息，以便分析问题所在？

   从上文可知通过引入span和trace分别从被追踪者和请求链路两个维度，推断追踪树，从而用于分析问题

2. 如何保证这些信息得到完整的追踪？

   只要采样的绝对数量够大，那么就比较好追踪。对于分布式的情况，通过span组织的逻辑链路来达成；对于异步，关联到相关的线程；

3. 如何尽可能不影响服务性能？

   分析收集可以通过动态的开关来保证紧急情况下的性能稳定，而追踪主要是通过尽量减少采样保证的

Ref

1. https://storage.googleapis.com/pub-tools-public-publication-data/pdf/36356.pdf
2. http://icyfenix.cn/distribution/observability/tracing.html