2023-01-11发表2023-01-11更新论文笔记 / 微服务智能运维11 分钟读完 (大约1610个字)0次访问

NSDI19 - Zeno - Zeno Diagnosing Performance Problems with Temporal Provenance

总结

提出了时序建模分析，精准刻画请求延时来源
提出了一个工具，给定trace中的两个事件，能刻画事件之间调用链以及为什么第二个事件慢
并不是用来分析系统性能问题，更多的是一种查询显示工具

背景

诊断问题时，定位瓶颈只是第一步。例如定位到网络延时、服务器负载。但正在的问题可能在于通过瓶颈链路发送流量的其他服务，或者通过请求使服务过载的机器。

Intro

现有工具无法解决的问题：假设一台配置错误的机器向存储后端发送大量rpc，该后端过载并延迟了来自其他客户机的请求。

M过多的请求阻塞了真正需要服务的机器C的请求
注意拿咖啡的例子
- 现有的方法在这种情况下不能满足的原因是它们只关注函数因果关系，它们解释了为什么给定的计算会有某些特定的结果。这种解释只关注计算的直接输入:例如，如果我们想解释一杯咖啡的存在，我们可以关注咖啡豆的来源、杯子的来源和咖啡师的行为。相比之下，时间因果关系也可能涉及其他看似不相关的计算:例如，买咖啡花了太长时间的原因可能是在我们前面等候的顾客太多，而这反过来可能是其他地方的交通堵塞导致大量顾客路过当地商店的结果。同时，在解释延迟时，一些功能依赖性可能被证明是不相关的:例如，即使咖啡豆是制作咖啡所需要的，它们也可能不是造成延迟的原因，因为它们已经在商店中可以买到。
本文更注重于时序因果(temporal causality)，而dapper更注重于功能因果（functional causality)
本文提出一种时序因果的概念和方法，以及如何将其与现有的诊断技术相结合

Overview

M对B的请求被称为off-path cause
在google cloud platform中，发现2014年1月至2016年5月，我们选择了所有95个事件报告，既描述了症状，也描述了原因。我们发现超过三分之一(34.7%)的事故是时间错误

传统的trace树
- 无法确定什么是瓶颈根因
Provenance
- Provenance：表示一种方法。当操作员要求对某个感兴趣的事件(例如，包的到达)进行解释时，系统可以生成一个递归解释，将事件与一组原因(如包的原始传输和相关路由状态)联系起来。

Approach

① 捕获并简历系统处理请求的顺序 - 定性分析

② 时间推理和调度理论中的关键路径分析之间的联系 - 时间贡献度计算 - 定量分析

③ 可视化

Temporal provenance

序列边
- dapper的调用关系为因果边，系统调用的顺序为序列边
- 序列边表示一台机器上事件的处理先后顺序
- INS表示事件触发，DRV表示事件处理。黑色线表示因果：A会触发B、C。绿色虚线表示先后，A事件，接着B被处理，接着C被处理。（注意这种表示方法和dapper不一样）
查询
- 目的：探究请求和响应之间延时的原因
- 形式：T-Query(e1, e2)，要求e1,e2需要有因果关系
- 算法
  1. 查询经典来源 P:=Query(e2)，则e1一定会包含在p中
  2. 识别p中所有有因果边连接但没有顺序边连接的点(v1,v2)，则v2因为一些原因被延迟(例如上图的C和B，没有因果边，C可能被某些事件延迟)
  3. 不断增加路径和事件，最终得到延迟原因
延迟注释：贡献度计算
- 目的：判断每个子树对整体延时的贡献度
- 规则：(作者提出三条规则，总结为两条人话)
  - 规则一：整体延时由后向前，递归得分配耗时
    
    A在5s结束，发现B结束用了4s，C结束用了2s，时间递归分配
  - 规则二：无法分配的延时，按照潜在的speed-up分配
    
    难点：A在6s开始，是因为B很慢导致，还是E很慢导致。(X,Y为两台机器)
    
    可以发现，如果B提前，则A不可能提前，因为被E阻塞，要等E返回。但E提前，A会被提前。所以给DRV(B)分配了4s，剩下的B到A的时间，以及E自己的时间，被分给了E请求接收、处理、发送