Why do distributed systems need tracing?
First introduce a concept:
distributed tracing
, or
distributed
tracing .
The e-commerce platform is composed of hundreds of distributed services. After each request is routed, it will pass through multiple business systems and leave footprints, and generate access to various caches or DBs, but these scattered data are very important to the problem. Troubleshooting, or process optimization are of limited help. For such a cross-process/cross-thread scenario, it is particularly important to collect and analyze massive logs collectively.
To be able to track the complete call link of each request, collect performance data of each service on the call link, calculate performance data and compare performance indicators (SLA), and even feedback to service governance in the far future , then this is the goal of distributed tracing
. In the industry, twitter's zipkin and Taobao's eagle eye are similar systems. They both originated from Google Dapper papers, just as Hadoop originated from Google Map/Reduce papers in history, and HBase originated from Google BigTable papers.
Okay, let’s sort it out. Google is called Dapper, Taobao is called Eagle Eye, Twitter is called ZipKin, Jingdong Mall is called Hydra, eBay is called Centralized Activity Logging (CAL), Dianping is called CAT, and we are called Tracing.
Such systems typically have several design goals:
(1) Low intrusion - as a non-business component, it should intrude as little or no intrusion into other business systems as possible, be transparent to the user, and reduce the burden on developers;
(2) Flexible application strategies - the scope and granularity of collected data can be (preferably at any time) determined;
(3) Timeliness - from the collection and generation of data, to the calculation and processing of data, to the final presentation, it is required to be as fast as possible;
(4) Decision support - whether the data can be useful at a decision support level, especially from a DevOps perspective;
(5) Visualization is king.
Let's first have an intuitive feeling:
The following shows the call chain drawing interface of ZipKin, Hawkeye, and Wowo in turn.
Figure 1 twitter zipkin call chain
Figure 2 The call chain of Taobao Eagle Eye
Figure 3 Jingdong Mall hydra call chain
Figure 4 Wowo tracing call chain
Move the mouse to each layer of the call chain and click, you can see specific information such as execution time, host IP, database operations, incoming parameters and even error stacks.
How Taobao does it:
All related calls of the same request are called call chains in Taobao EagleEye . At the same time, there are many network calls initiated by a certain server in parallel. How to identify which call chain this call belongs to? You can start with each middleware that initiates network calls.
When the front-end request arrives at the server, the application container will execute EagleEye's burying logic (similar to the Filter mechanism) before executing the actual business processing. The burying logic assigns a globally unique call chain ID to the front-end request. This ID is called TraceId in EagleEye. The embedded logic puts TraceId in a calling context object, and the calling context object will be stored in ThreadLocal . There is also a very important ID in the calling context, which is called RpcId in EagleEye. RpcId is used to distinguish the occurrence order and nesting hierarchy of multiple network calls under the same call chain . For requests received by the front end, the generated RpcId is always 0 .
当这个前端执行业务处理需要发起 RPC 调用时，淘宝的 RPC 调用客户端 HSF 会首先从当前线程 ThreadLocal 上面获取之前 EagleEye 设置的调用上下文。然后，把 RpcId 递增一个序号。在 EagleEye 里使用多级序号来表示 RpcId，比如前端刚接到请求之后的 RpcId 是0，那么 它第一次调用 RPC 服务A时，会把 RpcId 改成 0.1。之后，调用上下文会作为附件随这次请求一起发送到远程的 HSF 服务器。
HSF 服务端收到这个请求之后，会从请求附件里取出调用上下文，并放到当前线程 ThreadLocal 上面。如果服务A在处理时，需要调用另一个服务，这个时候它会重复之前提到的操作，唯一的差别就是 RpcId 会先改成 0.1.1 再传过去。服务A的逻辑全部处理完毕之后，HSF 在返回响应对象之前，会把这次调用情况以及 TraceId、RpcId 都打印到它的访问日志之中，同时，会从 ThreadLocal 清理掉调用上下文。如图6-1展示了一个浏览器请求可能触发的系统间调用。
图6-1-一个浏览器请求可能触发的系统间调用
图6-1描述了 EagleEye 在一个非常简单的分布式调用场景里做的事情，就是为每次调用分配 TraceId、RpcId，放在 ThreadLocal 的调用上下文上面，调用结束的时候，把 TraceId、RpcId 打印到访问日志。类似的其他网络调用中间件的调用过程也都比较类似，这里不再赘述了。访问日志里面，一般会记录调用时间、远端IP地址、结果状态码、调用耗时之类，也会记录与这次调用类型相关的一些信息，如URL、服 务名、消息topic等。很多调用场景会比上面说的完全同步的调用更为复杂，比如会遇到异步、单向、广播、并发、批处理等等，这时候需要妥善处理好 ThreadLocal 上的调用上下文，避免调用上下文混乱和无法正确释放。另外，采用多级序号的 RpcId 设计方案会比单级序号递增更容易准确还原当时的调用情况。
最后，EagleEye 分析系统把调用链相关的所有访问日志都收集上来，按 TraceId 汇总在一起之后，就可以准确还原调用当时的情况了。
图6-2-一个典型的调用链
如图6-2所示，就是采集自淘宝线上环境的某一条实际调用链。调用链通过树形展现了调用情况。调用链可以清晰地看到当前请求的调用情况，帮助问题定 位。如上图，mtop应用发生错误时，在调用链上可以直接看出这是因为第四层的一个(tair@1)请求导致网络超时，使最上层页面出现超时问题。这种调用链，可以在 EagleEye 系统监测到包含异常的访问日志后，把当前的错误与整个调用链关联起来。问题排查人员在发现入口错误量上涨或耗时上升时，通过 EagleEye 查找出这种包含错误的调用链采样，提高故障定位速度。
调用链数据在容量规划和稳定性方面的分析
如果对同一个前端入口的多条调用链做汇总统计，也就是说，把这个入口URL下面的所有调用按照调用链的树形结构全部叠加在一起，就可以得到一个新的树结构（如图6-3所示）。这就是入口下面的所有依赖的调用路径情况。
图6-3-对某个入口的调用链做统计之后得到的依赖分析
这种分析能力对于复杂的分布式环境的调用关系梳理尤为重要。传统的调用统计日志是按固定时间窗口预先做了统计的日志，上面缺少了链路细节导致没办法对超过两层以上的调用情况进行分析。例如，后端数据库就无法评估数据库访问是来源于最上层的哪些入口；每个前端系统也无法清楚确定当前入口由于双十一活动流量翻倍，会对后端哪些系统造成多大的压力，需要分别准备多少机器。有了 EagleEye 的数据，这些问题就迎刃而解了。
下图6-4展示了数据流转过程。
图6-4 鹰眼的数据收集和存储
京东如何实现的：
京东商城引入了阿里开源的服务治理中间件 Dubbo，所以它的分布式跟踪 Hydra 基于 Dubbo 就能做到对业务系统几乎无侵入了。
Hydra 的领域模型如下图7所示：
图7 hydra 领域模型以及解释
hydra 数据存储是 HBase，如下图8所示：
图8 hydra 架构
窝窝如何实现的：
2012年，逐渐看到自建分布式跟踪系统的重要性，但随即意识到如果没有对 RPC 调用框架做统一封装，就可能侵入到每一个业务工程里去写埋点日志，于是推广 Dubbo 也提上日程。2013年，确定系统建设目标，开始动手。由于 tracing 跟 DevOps 息息相关，所以数据聚合、存储、分析和展示由运维部向荣牵头开发，各个业务工程数据埋点和上报由研发部国玺负责。
经过后续向荣、刘卓、国玺、明斌等人的不断改进，技术选型大致如下所示。
- 埋点
- 实现线程内 trace 上下文传递，即服务器内部的方法互调时不需要强制在方法形参中加 Message 参数；
- 实现 trace 埋点逻辑自动织入功能，即业务开发人员不需要在方法中打印 trace 日志，只需要给该方法加注解标识 ；
- 原理：
- 利用 Javaagent 机制，执行 main 方法之前，会先执行 premain 方法，在该方法中将字节码转换器载入 instrumentation，而后 jvm 在加载 class 文件之前都会先执行字节码转换器。
- 字节码转换器中的逻辑为，识别出注解 trace 的类及方法，并修改该方法字节码，织入埋点逻辑。进入方法时会初始 trace 上下文信息，并存储在线程的 threadLocals 中，退出方法会打印 trace 日志并清空该方法的上下文。
- 数据聚合
- 应用层 trace 日志通过 flume agents 实时发送至 flume collector；
- 数据存储
- 服务端分别通过 hdfs-sink 和 hbase-sink，实时录入至 hbase、hdfs；
- hdfs 有 tmp 临时文件存放实时聚合过来的数据，每5分钟生成一个 done 文件；
- 数据分析和统计
- load 程序每 4 分钟检查 done 文件并存放至 hive 表 hkymessage 指定分区；
- 分析程序每5分钟执行一次, 将生成统计数据入库, 结果集数据如下：
数据格式：{5个分层的5个响应时段请求个数合集} {5个分层5-10s和大于10s散点数据合集} 当前5分钟最后一次请求rootid 统计时间
- 数据展示
基于这些数据分析和统计，我们就能绘制性能曲线图，从中可以发现哪些时间点哪些层有性能问题，然后一路点进去，直到找到到底是哪一个调用链里的哪一个环节慢。
图9 性能曲线默认图形
还可以从每一次调用结果分析出各层的异常曲线，并按照 memcached/redis/mongodb/mysql/runtime/fail 分类查看。
图10 异常曲线默认图形
还可以进一步统计各个业务工程的访问量、访问质量和平均访问时长，并于历史同期对比，从而快速理解系统服务质量。
如上所述，窝窝的 Tracing（鹰眼） 系统目前已投入使用，归并在 OAP（运维自动化平台）里。
-over-
