论文笔记：MicroRCA: Root Cause Localization of Performance Issues in Micro services

MicroRCA: Root Cause Localization of Performance Issues in Micro services

MicroRCA通过将应用程序性能症状与相应的系统资源利用率关联起来，在不使用任何应用程序检测的情况下，实时推断根本原因。

根因定位基于一个属性图，该图为跨服务和机器的异常传播建模。

1 介绍：

利用MSA，应用程序被分解为具有轻量级交互的自包含和独立部署的服务

需要快速检测性能问题并找到根本原因，但是很难。

why:

1.复杂的依赖性:服务的数量通常可以是数百或数千-服务之间的依赖关系比传统的分布式系统要复杂得多-一个服务的性能下降可能会广泛传播并导致多个告警-难以定位根本原因。

2.众多的性能指标:可用的监视性能指标的数量非常多， 如果将所有这些指标都用于性能问题诊断，将会造成很大的开销

3.异构服务：允许开发团队使用不同的编程语言和技术堆栈；不同的技术栈表现出不同的性能异常。

4.频繁更新：微服务频繁更新以满足客户的需求。这种高度动态的环境加剧了根本原因定位的难度。

当前方法：

1. 应用程序进行工具化

2. 需要分析大量的指标

3. 通过构建因果图并基于应用程序级度量沿着图推断原因——可避免上述限制

   通过后端服务和前端服务之间的相关性进行排序，可能无法识别对前端业务影响不大或没有影响的故障业务。

本文提出的MicroRCA：基于容器的微服务环境设计的、与应用程序无关的系统。

1）持续收集应用程序和系统级别度量，并检测SLO(服务级别目标)度量上的异常

2）检测到异常，MicroRCA将构建一个带有服务和主机的属性图，以对异常在服务之间的传播进行建模。

图：不仅包括服务调用路径，还包括位于同一(虚拟)机器上的并置服务

3）将通信服务的异常现象与相关资源的使用情况进行关联，推断潜在的异常服务，并对潜在的根本原因进行排序。

通过服务异常与资源利用的相关性，MicroRCA可以识别出异常的非计算密集型服务，这些服务异常症状不明显，减轻了误报对根因定位的影响。

（为什么识别出非计算密集型服务可以减轻误报的影响？）

因为非计算密集型服务的异常不明显，所以能检测就能降低误报，降低误报则降低对根因定位的影响

原文：With the correlation of service anomalies and resource utilization, MicroRCA can identify abnormal non-compute intensive services that have non-obvious service anomaly symptoms, and mitigate the effect of false alarms to root cause localization.

主要工作：

1. 提出了一个带有服务和主机节点的属性图来模拟基于容器的微服务环境中的异常传播。——基于在应用程序和系统级别收集的指标，不需要应用程序检测
2. 提供了一种通过将服务性能症状与相应的资源利用率关联起来来识别异常服务的方法——适应异构性
3. 从不同类型的故障和不同类型的故障服务测试评估——测试

2 相关工作

故障根因分析：

基于日志解析：难以实施工作，需解析隐藏在日志中的异常信息

基于跟踪的方法：通过跟踪执行路径来收集信息，然后通过分析沿着路径的延迟偏差来识别根因，但须充分理解源代码，写跟踪代码

基于指标：使用来自应用程序和/或其他基础设施级别的指标来构建因果关系图，用于推断根本原因。Eg2:

Seer需要对源代码进行插装以获取指标，同时，当微服务频繁更新时，其性能可能会下降。

Loud可识别产生性能指标的任何错误组件。它直接利用异常检测系统的KPI指标的因果图，通过不同的图中心性算法对故障部件进行定位。然而，它需要对所有收集的指标执行异常检测，开销巨大。

……

总之这些方法 不能 不影响前端服务而确定根本原因。

3 系统概述

3.A全览：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-j7jgavNq-1632663676893)(C:\Users\Dell\AppData\Roaming\Typora\typora-user-images\image-20210916210924977.png)]

数据收集 ：从应用程序和系统收集指标。

应用程序指标：来自服务网格，包括两个通信服务之间的响应时间等

系统指标：来自监视系统，包括容器和主机资源利用率

两个级别的指标用于定位根本原因。

出现异常→原因分析引擎构建一个带有服务和主机节点的属性图G来表示异常的传播路径→引擎根据检测到的异常提取异常子图→推断最有可能导致异常的服务

3.C 异常检测

选择无监督学习算法基于距离的在线聚类异常检测方法。

异常：微服务的慢响应时间

3.D 原因分析引擎 见4

组成:属性图构造、异常子图提取和故障服务定位

属性图：表示异常通过服务和主机的传播

异常子图提取：PageRank 图中心性算法对故障服务进行定位

4 根因定位

4.A 属性图构造

表示微服务环境中的异常传播， 异常不仅沿着服务调用路径在服务之间传播，而且还传播到位于相同机器上的其他服务（服务与宿主机之间的调用）。

提取检测到异常之前特定时间范围的指标（假定为可靠运行），用以提供所有通信服务和服务与主机之间的关系。

通过枚举和解析 指标来发现图节点及其动态关系。

图节点的连接：服务Si向Sj发送请求，Si→Sj有向边

​ 主机Hj分配容器化的服务Si,Si→Hj有向边

4.B 异常子图（SG）提取

表示异常通过服务和主机传播的连接子图。

使用通信服务之间的响应时间，即属性图中服务节点之间的边作为异常检测目标。

异常服务节点：响应时间异常→异常边→异常边目的节点=异常节点

4.C 错误定位

通过子图连边权重计算连接节点间的相似度→计算异常节点的异常分数→基于图中心性算法定位

**子图权重：**节点对之间的相似性。

3种 权重逻辑：

1）异常边权重：表示异常边报错的置信度

2）异常业务节点与正常业务节点之间的权重：？？？

3）异常业务节点与正常主机节点之间的权重：以异常业务节点的平均异常响应时间与主机资源利用率Uh之间的最大相关系数来—业务异常症状与相应资源利用率之间的相似性。

**计算异常服务节得分：**公式（3）

采用服务节点的平均权重来表示对链接节点的影响。

假设容器资源利用率与服务性能相关→用异常服务节点的平均异常响应时间rt_a之间的最大相关系数来调整服务异常。

定位故障服务：图中心算法Personalized PageRank

个性化PageRank向量（PPV）v是每个节点的根因分数

定义转移概率矩阵P

定义偏好向量U，为分配节点时的偏好（优先性？）

当随机传送发生时，与异常相关的服务节点被访问得更频繁。

（4）表示每个步骤以概率 c 跳回到一个随机节点，并以概率1-c 沿图继续向前。排序后，我们从排序列表中删除主机节点。

在得到排序的候选列表后，将主机节点从排序列表中删除，因为 MicroRCA 旨在定位故障服务。 由于异常子图中服务节点之间的链接代表服务调用-被调用关系，因此需要在运行定位算法之前反转边。

5 实验结果

实验设置：kubernetes-sock shop-含有4个工作节点和一个主节点

工作节点：三个工作节点专用于微服务，一个用于数据收集。

**Sock-shop ：**由13个微服务组成，它们采用异构技术实现，通过 http 上的 rest 进行互通。

前端服务作为用户请求的入口点;

目录提供袜子目录和产品信息;

购物车载有购物车;

用户提供用户认证和存储用户帐户-支付及地址;

订单在用户登录后通过用户服务从购物车下单，然后分别处理支付和运输服务。

**Locust：**模拟用户负载

**prometheus：**数据采集

在服务级别，我们收集每对服务之间的响应时间。

在容器级和主机级，我们收集 cpu 使用情况、内存使用情况和总发送字节的大小。

**故障注入：**异常表现为增加的微服务响应时间。

会不会有不是以增加响应时间的为结果的故障？

延迟

cpu 占用

内存泄漏

baseline：

monitorrank 在识别度较大的支配节点方面有很好的表现。但是它不能识别叶子节点。

why：monitorrank 根据前端服务和后端服务之间的相关性计算相似性。微服务支付的异常降低了传播过程中的相关性，从而使根源定位失败。

Microscope在识别叶节点方面有更好的表现，但是在主节点识别方面更糟糕。

why:Microscope根据检测到的异常情况遍历图表，并将异常子节点放入潜在原因列表中，这使得当子节点报警时，它无法识别主要节点。

Microscope>monitorrank

monitorrank 根据前端服务和后端服务之间的相关性计算相似性。微服务支付的异常降低了传播过程中的相关性，从而使根源定位失败。

Microscope在识别叶节点方面有更好的表现，但是在主节点识别方面更糟糕。

why:Microscope根据检测到的异常情况遍历图表，并将异常子节点放入潜在原因列表中，这使得当子节点报警时，它无法识别主要节点。

Microscope>monitorrank