本文是基于kprobe的一个tracing工作。一个新颖点在于除了普通的逻辑之外还提出了一些新的图关系和图表示。
主要贡献有三个方面。
- 首先，为黑盒子的多层服务提出了一种精确的请求追踪算法，它只使用与应用无关的知识。
- 其次，我们提出了一种新的图来表示每个请求的因果路径。同时使用聚合因果路径模式来表示重复执行的因果路，进一步提出了因果路径模式的衍生性能指标，即组件的延迟百分比。
- 第三，开发了两种机制，按需追踪和采样，以显著提高系统的可扩展性。这边对trace的采样实际上值得注意！因为会发生漏一些东西的情况。
PreciseTracer design
PreciseTracer Architecture
图2
- TCP
Tracer记录目标应用程序组件的相关交互活动，并将这些日志输出到Correlator
- Gather部署在每个服务节点上，负责收集部署在同一节点上的服务的日志。Gather只关心在数据中心的范围内，服务请求何时开始、结束，以及组件何时接收或发送消息。Gather记录五个属性：（活动类型、时间戳、上下文标识符、消息标识符）和消息大小。对于每个活动，我们使用四元组（主机名、程序名、进程ID、线程ID）来描述其上下文标识符，并使用五元组（发送方的IP、发送方的端口、接收方的IP、接收方的端口、消息大小）来描述其消息标识符。
- 部署在分析节点上的Coordinator负责控制每个服务节点上的Gather
- Correlator负责将不同组件的这些活动日志关联到因果路径
- Ranker负责选择候选活动来组成因果路径
- Engine从Ranker的输出构建因果路径，然后报告因果路径
- 根据Correlator产生的因果路径，Analyzer提取有用信息，并报告分析结果
- Classifier负责将因果路径分类为不同的模式
- Extractor提供因果路径模式的分析结果
使用因果路径集合而不是
Abstractions
percentage就是用BEGIN到END的时间去除对应的时间。
Tracing Algorithm
因为算法没有记录直接因果关系，所以是通过一个sliding window去做reconstruct的。
Improving the System Scalability
基于kprobe。