论文提出了VAIF (Variance-driven Automated Instrumentation Framework)。根据variance来自动搜索可能的插桩选择空间，来实现自动插桩。针对Openstack改了OSProfiler，针对HDFS改了X-Trace。

这篇为啥和socc19的好像啊，也没给解释，就evaluation里面引了一下。

论文的三个insight如下

在许多分布式应用中，有具有类似的关键路径的workflow中的请求应该性能接近
分布式追踪捕捉请求的工作流程图（traces），其分辨率等于应用程序中的日志点的数量
High variance或者一直很慢的都需要更多的关注，通过识别请求的关键路径轨迹中对方差贡献最大的边来定位

TOWARDS AUTOMATION

Logging challenges

三个挑战

没有完美的一刀切的日志，导致信息量和开销之间的tradeoff
极其庞大的日志搜索空间
data overload导致大海捞针的问题

Addressing the requirements

四大原则

原则1: 识别那些具有相同关键路径，但是表现出高响应时间variance的trace。识别其对差异的贡献最大关键路径的边。在与这些区域相对应的代码区域中启用额外的追踪点。

原则2：识别那些具有相同关键路径的请求，这些请求具有较低的差异性，但具有较高的响应时间（即持续缓慢）。识别对响应时间起主导作用的关键路径跟踪边缘，并在与这些区域相对应的代码区域启用跟踪点。

原则3：识别那些具有相同关键路径，但是表现出高响应时间variance的trace。和原则1的区别是，需要识别哪些由已经启用的追踪点暴露的键/值对与请求的响应时间高度相关。用这些键和值的范围来增加追踪点的名称，或者直接将它们展示给开发者。比如mutex_queue_length的键值对和VM_CREATE的延时高度相关。

原则4：维护代表高差异或持续缓慢性能的轨迹点的历史，以及促使这些决定的统计数据。这一原则允许框架解释它为什么做出决定来定位问题。

VAIF

Design

包括控制平面和插桩平面。

Control logic & hypothesis forest

在每个周期，VAIF的控制逻辑都会探索哪些追踪点应该被启用以定位问题的假设。假设本身的形式是："根据轨迹是否包括新启用的跟踪点来区分它们，以帮助定位问题"。

假设树的节点（hypothesis nodes）包含指向应用假设的结果的指针。假设的结果有两个节点，一个是包含启用的跟踪点的跟踪点，另一个是不包含该跟踪点的跟踪点。每个节点包括一个字段，命名假设的追踪点，以及它在追踪中是存在还是不存在

Search space & search strategies

搜索空间包含。1）当所有追踪点都启用时，请求工作流程中潜在的关键路径；2）划分并发或同步的追踪点；3）追踪点中的键，应纳入分组和它们的bin范围

搜索策略包括。1）Hierarchical search；2）Flat search

VAIF PROTOTYPES

针对Openstack改了OSProfiler，针对HDFS改了X-Trace