背景
MonitorRank 是最早使用随机游走的策略定位故障根因服务的方法，MonitorRank 把系统的服务分成三类：
- 前端服务：负责接收用户的请求以及进一步调用下游请求以完成用户的请求。
- 应用服务：负责真正处理用户请求的逻辑。
- 数据服务：负责提供经过包装的数据。
（应用服务和数据服务又统称为后端服务）
在每个服务上，配置有传感器，会定时给出指标数据。通过服务之间的调用关系，可以形成一个调用拓扑图。图上的节点就是服务，边就是节点之间的调用关系。
框架
Metric Collection
将指标传递给一个称为Kafka的集中式代理系统，按更粗的时间粒度聚合（即设定的间隔）并存储到按时间分区的数据库中。
Batch Mode Engine
来自 Kafka 的指标数据也由批处理系统 Hadoop 使用，并存储在 Hadoop 的分布式文件系统 (HDFS) 上。 Hadoop 定期将指标数据的快照作为输入，并输出调用图和外部因素。
伪异常聚类：对于检测异常，这里使用历史度量数据文献中的各种检测算法之一。检测算法的输出是 { 异常的前端传感器、相应的metric、时间范围（时刻）}。由于这些检测到的异常可能不一定是真实的，因此我们将它们称为伪异常。对于每个伪异常，我们需要计算相应指标数据与所有其他传感器的相似度。
对于异常时刻t，相似度计算公式如下：
共享方差 δ2是相对于每个伪异常时刻 t 的所有传感器与异常的平均相关性 μ(t) 以及误差 ε(t)的
（这里与异常的相关性具体怎么计算原论文并没有体现）
聚类算法的输入是 (a) 种子前端传感器 vfe（即 v1） (b) 来自历史数据的各种伪异常时刻（t1、····、tk） (c) 模式相似度得分传感器的数量（S(t1)、····、S(tk)）
根据传感器的模式相似度得分将传感器（前端传感器除外）分为两组。一组由表示低模式相似性分数（接近零）的传感器组成，另一组包含显示高模式相似性分数（接近 μ(t)）的传感器。我们将后一组称为给定伪异常时刻的异常簇。
Real-time Engine
对于每个传感器 vi，相对于异常传感器 vfe 的 metric 相似性得分 Si 的计算如下：
(Sim(·,·)是两个时间序列数据之间的固定相似性函数)
基本思想是根据相似度分数在调用图上进行随机游走，通过在调用图中的邻居节点中随机选取下一个传感器。每个邻居节点的选取概率与其与给定异常的相关性成正比。
从任何一个怀疑的节点入手，每次都根据转移概率（目标节点和异常的相关性）从上一个节点的邻居中选择下一个节点。MonitorRank 假设在许多次随机游走过程中，被访问越多的节点越可能是根因，即被访问的概率就是根因排序依据的分数。
self-edges
实际上可能一个节点本身就是根因，只有其本身与异常的相关性很高，这会导致随机游走不得不游走到相关性很低的节点上。因此MonitorRank 额外定义了自环，自环的概率代表的就是一个节点本身就是根因的概率。
backward-edges
一旦随机游走时落入到了与给定异常不太相关的节点时，随机游走器很可能就自然的被困在调用图的分支内。因此 MonitorRank 给每一条边都引入了反向边，反向边的权重就代表了转移概率错误的概率
确定了转移概率 P 和偏好向量 u，PPV 就可以得到如下：
PPV即为最终的的得分向量
为什么使用随机游走
MonitorRank 的灵感来自于生物有机体通过执行随机游走有效地搜索其目标（例如气味来源），即使来自生物体的感官数据并不可靠 。此外，随机游走算法也类似于诊断期间的人类行为。当监控团队的工程师除了调用图之外对系统一无所知时，自然诊断方法之一是按照调用图随机遍历传感器，优先查看行为不当的节点。
结果
- RS、NEP、SC、TBAC为Baselines
- Mean Average Precision (MAP) 反映整体性能
