本篇文章主要解决两个分布式追踪的问题：metric selection和dependency graph
Sieve建立在两个核心组件上：
- a metrics reduction framework
- 首先通过观察一段时间内的信号，自动过滤掉不重要的指标，从而降低指标的维度。
- a metrics dependency extractor
- 通过测试Granger因果关系，使用预测因果关系模型推断系统中分布式组件之间的度量依赖关系。
开源 https://sieve-microservices.github.io/
Sieve overview
最直接的一个观点是，观测所有component的所有metrics是没必要的。
sieve的工作流程可以分成三步：
- Load the application：通过offline给application加负载，通过communication非侵入式地得到call graph，还得到metrics
- Reduce metrics：通过cluster得到代表性的metrics
- Identify dependencies：通过call graph和上面得到的metrics，看call graph上的组件是否有相互影响的metrics，如果有就连一条边
Design
load the application
obtaining metrics。记录metric time series。主要采集两种指标：system metrics和application metrics。
obtaining call graph。已知有几种方法能够获得call graph：
- instrumentation
- tcpdump这种从network traffic入手
- ptrace去追踪网络相关的API
论文中采用的是sysdig，但仍然也是采取观察系统调用的方式。 利用一个内核模块，sysdig将系统调用作为事件流提供给用户应用程序。 该事件流还包含被监控进程的信息，因此网络调用可以被映射到微服务组件，即使它们是在容器中运行。
此外，它可以通过用户定义的filter提取communication peer。
采用sysdig，有两个优点：
- 非侵入式
- overhead小
reduce metrics
论文中采用的是k-shape方法进行降维。相比之下，PCA不容易解释，random projections牺牲了精度，同时在不同的运行中有不同的结果（稳定性问题）。
filtering unvarying metrics。先把var小于0.002的筛掉，这些metrics不怎么变，所以没用。
k-shape clustering。 k-shape主要关注时间序列的形状上的相似性。k-shape使用shape-based distance (SBD)。 好像具体出处是这篇论文：《k-Shape: Efficient and Accurate Clustering of Time Series》
根据sieve的数据特性，论文做出了三个具体的调整
- k-shape要求长度一致，于是论文加了spline interpolation of the third order (cubic)做插值
- 根据名称的相似性（例如通过Jaro距离计算相似性）对度量时间序列进行预聚类，并使用这些聚类作为初始分配，而不是默认的随机分配
- k-shape要求实现决定cluster的最终数量。论文迭代改变这个最终数量，并且用silhouette value来衡量quality of clusters
representative metrics。就是从cluster里面选一个代表元，这个代表元是cluster center的SBD最近的metric。
identify dependencies
使用call graph来reduce the number of components that need to be investigated。 具体来说，就是把一个组件的representative metric和neighbour component的representative metric做pair-wise的比较。
比较用的是Granger Causality test，这种test有助于确定一个时间序列是否有助于预测另一个时间序列。 这个test后面的直觉是，如果一个指标X对另一个指标Y有格兰杰因果关系，那么与只使用Y的历史相比，我们可以通过使用X和Y的历史更好地预测Y。
论文中用最小二乘法建立了pair-wise的线性模型，还加了一个延迟，比较是否有因果关系用的是F-test。 此外还有一些别的设计考虑。
然后如果有因果关系，就加一条有向边。
application
sharelatex
sharelatex是一个微服务应用。我们使用Sieve的依赖关系图，为sharelatex提出了扩容的策略，具体来说，提出了
- 指导性指标（即在扩展规则中使用的指标）
- 扩展行动（即与通过增加/减少受最低/最高阈值限制的实例数量来应对不同负载有关的行动）
- 扩展条件（即基于指导性指标触发相应扩展行动的条件）
试验结果：sieve找到了一个比CPU-usage更好的指标http-requests_Project_id_GET_mean。
openstack
做openstack上问题的根因分析。引擎比较了应用程序两个不同版本的依赖图：（1）正确的版本；（2）有问题的版本。
这里给了一套根因分析的流程，感觉可以参考一下。（C是correct version，F是faulty version）
- analyzes the presence or absence of metrics between C and F versions，如果有不一样，很可能问题出在这上面（感觉很奇怪？）
- 使用第1步的结果，根据组件的新颖性得分（即新的或被丢弃的指标总数）对组件进行排名，产生一组初始的有趣的组件，用于RCA。
- 聚类聚集了在一段时间内表现出类似行为的组件指标。对于RCA来说，具有新的或被抛弃的指标的聚类与该组件的未改变的聚类相比，应该是更有趣的（有一些例外，在下面解释）。对于一个给定的组件，我们计算其集群的新颖性分数，作为新的和被丢弃的指标数量的总和，并产生一个{组件，指标列表}对的列表，其中指标列表考虑来自具有较高新颖性分数的集群的指标。
- 此外，我们跟踪一个组件的集群在C和F版本之间的相似性（反之亦然）。这样做是为了识别两个事件。(1) 版本之间边的出现（或消失）；以及(2) C和F版本之间保持的关系的属性变化
- 如果集群x和y（分别属于component A和B）各自的metric构成在C和F版本之间没有明显的变化，则称为 "版本间保持"
- 通过Jaccard similarity coefficient来算相似度
- 进一步过滤
- 最后得到一个{component, metric list} pairs
We expect the RCA engine’s outcome to include the Neutron component, along with metrics related to VM launches and networking.