调用链监控：Dapper、Istio... etc.

目录

Dapper，大规模分布式系统的跟踪系统by bigbully

2.5.1 带外数据跟踪收集

6.2 解决延迟的长尾效应

7. 其他收获

 

RPC服务追踪的原理与实践- SegmentFault 思否

1. TraceID如何生成？

2. 数据埋点如何做到对业务开发透明？如何在当前上下文中记录信息

3. 怎么实现Trace信息在调用链上的传递？

总结：

 

业务链路监控(Google Dapper)和ThreadLocal - 简书

 

 

 

 

Istio调用链埋点原理剖析—是否真的“零修改”？ - InfoQ

Dapper-Google大规模分布式跟踪系统 笔记

要解决的问题

设计目标

Dapper应用场景

 

APM（应用性能管理）与Dapper原理介绍- 谙忆-陈浩翔- CSDN博客

---

---

Dapper，大规模分布式系统的跟踪系统by bigbully

https://bigbully.github.io/Dapper-translation/

翻译得不错，应该是对原文的翻译~~

 

2.5.1 带外数据跟踪收集

tip1:带外数据:传输层协议使用带外数据(out-of-band，OOB)来发送一些重要的数据,如果通信一方有重要的数据需要通知对方时,协议能够将这些数据快速地发送到对方。为了发送这些数据，协议一般不使用与普通数据相同的通道,而是使用另外的通道。

tip2:这里指的in-band策略是把跟踪数据随着调用链进行传送，out-of-band是通过其他的链路进行跟踪数据的收集，Dapper的写日志然后进行日志采集的方式就属于out-of-band策略

Dapper系统请求树树自身进行跟踪记录和收集带外数据。这样做是为两个不相关的原因。首先，带内收集方案--这里跟踪数据会以RPC响应头的形式被返回--会影响应用程序网络动态。在Google里的许多规模较大的系统中，一次跟踪成千上万的span并不少见。然而，RPC回应大小--甚至是接近大型分布式的跟踪的根节点的这种情况下-- 仍然是比较小的：通常小于10K。在这种情况下，带内Dapper的跟踪数据会让应用程序数据和倾向于使用后续分析结果的数据量相形见绌。其次，带内收集方案假定所有的RPC是完美嵌套的。我们发现，在所有的后端的系统返回的最终结果之前，有许多中间件会把结果返回给他们的调用者。带内收集系统是无法解释这种非嵌套的分布式执行模式的。

>>> 上面一段有点没太来及看懂

 

6.2 解决延迟的长尾效应

考虑到移动部件的数量、代码库的规模、部署的范围，调试一个像全文搜索那样服务（第1节里提到过）是非常具有挑战性的。在这节，我们描述了我们在减轻全文搜索的延迟分布的长尾效应上做的各种努力。Dapper能够验证端到端的延迟的假设，更具体地说，Dapper能够验证对于搜索请求的关键路径。当一个系统不仅涉及数个子系统，而是几十个开发团队的涉及到的系统的情况下，端到端性能较差的根本原因到底在哪，这个问题即使是我们最好的和最有经验的工程师也无法正确回答。在这种情况下，Dapper可以提供急需的数据，而且可以对许多重要的性能问题得出结论。

 

图7：全局搜索的跟踪片段，在不常遇到高网络延迟的情况下，在沿着关键路径的端到端的请求延迟，如图所示。

在调试延迟长尾效应的过程中，工程师可以建立一个小型库，这个小型库可以根据DAPI跟踪对象来推断关键路径的层级结构。这些关键路径的结构可以被用来诊断问题，并且为全文搜索提供可优先处理的预期的性能改进。Dapper的这项工作导致了下列发现：

• 在关键路径上的短暂的网络性能退化不影响系统的吞吐量，但它可能会对延迟异常值产生极大的影响。在图7中可以看出，大部分的全局搜索的缓慢的跟踪都来源于关键路径的网络性能退化。>>>？？这句是啥意思？？
• 许多问题和代价很高的查询模式来源于一些意想不到的服务之间的交互。一旦发现，往往容易纠正它们，但是Dapper出现之前想找出这些问题是相当困难的。
• 通用的查询从Dapper之外的安全日志仓库中收取，并使用Dapper唯一的跟踪ID，与Dapper的仓库做关联。然后，该映射用来建立关于在全局搜索中的每一个独立子系统都很慢的实例查询的列表。

 

7. 其他收获

虽然迄今为止，我们在Dapper上的经验已经大致符合我们的预期，但是也出现了一些积极的方面是我们没有充分预料到的。首先，我们获得了超出预期的Dapper使用用例的数量，对此我们可谓欢心鼓舞。另外，在除了几个的在第6节使用经验中提到过的一些用例之外，还包括资源核算系统，对指定的通讯模式敏感的服务的检查工具，以及一种对RPC压缩策略的分析器，等等。我们认为这些意想不到的用例一定程度上是由于我们向开发者以一种简单的编程接口的方式开放了跟踪数据存储的缘故，这使得我们能够充分利用这个大的多的社区的创造力。除此之外，Dapper对旧的负载的支持也比预期的要简单，只需要在程序中引入一个用新版本的重新编译过的公共组件库(包含常规的线程使用，控制流和RPC框架)即可。

Dapper在Google内部的广泛使用还为我们在Dapper的局限性上提供了宝贵的反馈意见。下面我们将介绍一些我们已知的最重要的Dapper的不足：

• 合并的影响：我们的模型隐含的前提是不同的子系统在处理的都是来自同一个被跟踪的请求。在某些情况下，缓冲一部分请求，然后一次性操作一个请求集会更加有效。（比如，磁盘上的一次合并写入操作）。在这种情况下，一个被跟踪的请求可以看似是一个大型工作单元。此外，当有多个追踪请求被收集在一起，他们当中只有一个会用来生成那个唯一的跟踪ID，用来给其他span使用，所以就无法跟踪下去了。我们正在考虑的解决方案，希望在可以识别这种情况的前提下，用尽可能少的记录来解决这个问题。
• 跟踪批处理负载：Dapper的设计，主要是针对在线服务系统，最初的目标是了解一个用户请求产生的系统行为。然而，离线的密集型负载，例如符合MapReduce[10]模型的情况，也可以受益于性能挖潜。在这种情况下，我们需要把跟踪ID与一些其他的有意义的工作单元做关联，诸如输入数据中的键值（或键值的范围），或是一个MapReduce shard。
• 寻找根源：Dapper可以有效地确定系统中的哪一部分致使系统整个速度变慢，但并不总是能够找出问题的根源。例如，一个请求很慢有可能不是因为它自己的行为，而是由于队列中其他排在它前面的(queued ahead of)请求还没处理完。程序可以使用应用级的annotation把队列的大小或过载情况写入跟踪系统。此外，如果这种情况屡见不鲜，那么在ProfileMe[11]中提到的成对的采样技术可以解决这个问题。它由两个时间重叠的采样率组成，并观察它们在整个系统中的相对延迟。>>> 可以搞可以搞 >>> 
• 记录内核级的信息：一些内核可见的事件的详细信息有时对确定问题根源是很有用的。我们有一些工具，能够跟踪或以其他方式描述内核的执行，但是，想用通用的或是不那么突兀的方式，是很难把这些信息到捆绑到用户级别的跟踪上下文中。我们正在研究一种妥协的解决方案，我们在用户层面上把一些内核级的活动参数做快照，然后绑定他们到一个活动的span上。

---

 

RPC服务追踪的原理与实践- SegmentFault 思否

 

https://segmentfault.com/p/1210000008713567/read

讲的细节，不错

 

1. TraceID如何生成？

由于要唯一标示每一次调用，所以TraceID需要保证全局唯一。唯一的ID，第一个想到的当然是使用UUID，UUID是一个较为高效又使用方便的唯一ID生成方式，但问题是，zipkin要求TraceID是int64类型，不能是字符串，同时，UUID还有一个问题是不能保证单调有序。对此，有两个架构方案可选：
- 使用数据库自增长ID来生成，同时需要解决以下问题：

• 性能上，如果每次请求都访问数据库一次，会带来较大的性能损失，所以需要在客户端缓存一个区间的数字，当这个区间的数字不够时再从数据库获取。
• 出于安全要求不能跟数据库直连的客户端不适合，如Web服务器。可以考虑使用一个中间服务作为ID分发。

- 采用分机器(进程)的方式，保证机器间(进程间)ID不冲突，同时保证单机器(进程)内ID是递增不重复的。这种方式的最大好处时不需要中心化的节点进行ID分发，省掉了系统间的依赖。对于此种方案，最常用的算法是Twitter-Snowflake算法，也是我们最终选择的算法。Snowflake核心思想是将int64的除第一位外的其他63位分成三段，前面41位为时间戳、后面10位为工作机器(进程)ID，也称为WorkerID ，最后12位为递增序列号。
(img)

2. 数据埋点如何做到对业务开发透明？如何在当前上下文中记录信息

所谓数据埋点