Root Cause Analysis of Anomalies of Multitier Services in Public Clouds

发表于 | 分类于 | | 本文总阅读量 次
字数统计: 984 | 阅读时长 ≈ 3

主要是用similarity和random walk去做根因分析，同时也提出了internal contention（函数本身layer之间故障的传播）和external contention（资源竞争）。

这篇工作主要解决公有云上多租户场景下的性能问题的根因定位。 工作主要包括两部分：一个非侵入式的data collection subsystem和一个root cause localization subsystem。 本文的主要贡献

  • 帮助云运营商准确定位任何异常情况的根源，无论根源是在同一租户还是来自其他租户。
  • 提出了一种非侵入式的方法来捕捉多层组件的复杂的依赖关系，这提高了我们的根源定位系统的可行性。
  • 解决方案能够在虚拟机和流程层面上定位根本原因，甚至在异常现象是由多个原因造成的情况下也能找出根本原因。
  • 设计了一种基于监测应用层和底层基础设施的两步定位算法，以及一种random walk procedure。实验表明，该算法优于以往的工作。

Types of anomaly propagation and system architecture

两种

  1. Internal factor：异常可能沿着服务调用的路径在多层次服务的组件之间传播
  2. External factor：异常可能从其他租户的虚拟机传播到服务的一个虚拟机上，因为他们竞争同一个物理服务器的资源

system overall architecture

当用户发现有一个请求的返回延时非常长的时候，提交一个异常。系统通过两步来确定异常。

  1. 找到所有可能引起异常的原因，构建anomaly propagation graph。
    1. trace online requests，collect and save data
    2. construct a VM communication graph
    3. 考虑colocation的影响，完善anomaly propagation graph
  2. 确定anomaly propagation graph里面每个点是root cause的可能性。
    1. compute the service time of each component within the multitier service and monitor the resource utilization
    2. 提出了一个概念：similarity，使用上面收集的信息来计算similarity
    3. 通过random walk算法，incorporate the probability of VMs

anomaly propagation graph

request tracing of multitier services

主要用了别人的工具PreciseTracer，这是一个给予Systemtap的kernel instrumentation。

VCG construction

然后就需要把PreciseTracer的调用链转换成VM Communication Graph，VCG。核心问题是一个VM可能出现好几次，怎么确定edge的方向？

其实很好理解，对于从j到i的Send和从i到j的Recv，他们两个在同一个host上，且Recv在Send前，那么创建一条边，从i到j。

APG construction

非常简单，通过Openstack的nova接口，看看哪些VM co-locate了。

root cause localization

两个核心点

  1. metric data和同一条causal path上的response time的similarity能够反应root cause。本质来说就是root更容易更busy，这个busy就导致response time上升，这中间是有正向关系的
  2. 为了防止时间上的巧合，采用random walk来自然地通过一些条件来筛选。也就是如果co-located的vm发生竞争，那么它们应该similarity都很高。

metrics data collection

主要采集两个指标

  1. service time computation，也就是send和recv之间+recv和send之间的时间差，也就是两个span相减
  2. resource utilization collection，用的ganglia

similarity calculating

用的PCC：对于直接通信的也就是VCG上的vm，用service time作为指标计算PCC；对于co-located的，在竞争的资源指标里面选一个PCC最大的。需要解决两个问题

  1. 找到有同样causal path的历史数据：通过拓扑排序
  2. 确定进行比较的开始时间和结束时间：结束时间是用户提交异常的时间，开始时间是性能开始下降的时间，请求时间除以平均请求时间大于一个阈值的最早时间。

random walk over APG

similarity大并不意味着是root cause，为此进行random walk。

起点是异常发生的VM，然后定义了一些规则。最后，让walker走很多步，more visits on a certain VM implies that the VM is more likely to be a root cause