文章主要是用插桩去采样信息（基本还是执行时间），用call tree去做分类，通过CoV找到异常分类，通过RPCA在异常分类中找到异常组件。
文章主要分成三个design点
- collect performance data
- assemble performance data
- identify the primary causes of anomalies
Performance data collection
基于插桩，获得以下信息：
- host
- timestamp
- requestID
- MID
- MID是用来解决时间漂移的。时间漂移会导致只用requestID和时序构建不出来跨host的情况。加一个RequestID生成MID的log就可以了。（图五log的Host1第三行）
- Method
- Flag
Diagnosing anomalies without domain knowledge
Identifying Anomalous Categories
我们不能仅仅依靠一个请求的响应延迟来检查一个请求是否是异常的。 长的响应延迟并不表示失败。例如，一个从硬盘中读取文件的请求的响应延迟比另一个从缓存中读取文件的请求的响应延迟长几倍。
这边也是通过call tree来进行分类。但是是判断中整个call tree是否异常。判断的根据是coefficient of variation。 如果一个类别内的请求的延迟集中在一个特定的范围内，则该类别被认为是正常的；相反，如果一个类别的延迟过于分散，则被认为是异常的。
Identifying Anomalous Methods
在一个异常的请求类别中，我们现在的目标是找出对请求的性能异常有反应的异常方法的调用。
大多数具有相同调用树的请求都有类似的性能数据。换句话说，大部分的行是相关的。（一列是一个request的数据）。 因此用RPCA去做anomaly detection。（不用PCA是因为error不符合高斯分布）
一个原始矩阵M就变成了非干扰矩阵L和误差矩阵E，我们可以从E中找出干扰列（即异常方法）。 E里面cosine偏差大于阈值的认为是异常。