TraceRCA：通过Trace Analysis进行微服务系统的根因定位

前言

之前有一点时间对traceRCA比较感兴趣，读了几篇论文，今天突然发现自己的笔记里还有一篇写好笔记。但是没有整理的文章，直接发一下。

查了一下，现在代码已经开源了

• code： https://github.com/NetManAIOps/TraceRCA

• paper：https://netman.aiops.org/wp-content/uploads/2021/05/1570705191.pdf

一、Introduction

说下其他的缺陷，这个也是大多数算法的情况

强调是更加的practical

说明价值的巨大，这件事的意义所在：微服务巨大的损失，短时间内

二、Related works

分为两种模式

• invocation-based：更关注调用异常的相邻微服务更有可能是根本原因

• trace-based：更关注于整体的trace链路结构：MicroScope, TraceAnomaly, and MEPFL

三、Concepts

这里主要对trace本身的形成给了一个通俗易懂的解释，但解释的并不全，没有说出span等概念

例子理解下：

形成trace，需要在想要监控的链路上进行埋点。

对于span我让chatgpt通俗易懂的解释一下, 其中一道菜可能就是很多个微服务或者一个微服务：

想象一下你在做一道菜，菜单上列出了所有的步骤和所需材料。在这个例子中，整个烹饪过程可以看作是一个追踪，而每一个步骤就是一个span。

每个span都有一个唯一的标识符，就像每个步骤都有一个编号。它还有一个开始时间和结束时间，记录了每个步骤的执行时间。比如，炒菜这个步骤开始的时间是10点，结束的时间是10点15分。

每个span还可以记录一些其他的信息，比如这个步骤的名称、所使用的工具、材料等。比如，炒菜这个步骤可能记录着“炒菜”这个名称，还有使用的锅、油、火等信息。

除了基本信息外，span还可以记录与该步骤相关的事件和标签。事件可以是一些额外的说明，比如在炒菜的过程中发生了一次小小的火灾，可以记录下来。标签可以是一些键值对，用于记录与该步骤相关的特定信息，比如所用的食材、调味料等。

总之，span就是用来描述一个请求或操作的各个步骤的信息，包括开始时间、结束时间、名称、事件和标签等。它们可以帮助我们了解整个操作的执行情况，分析性能问题，找出错误或改进操作过程。

四、Method

包括三个部分

1. trace anomaly detection

2. suspicious root-cause microservice set mining

3. microservice ranking

4.1 trace anomaly detection

1. Multi-Metric Invocation Anomaly Detection:

taceRCA 检测不正常的trace 通过检测不正常的调用而不是直接检测不正常的trace，trace是不定长的（动态图），需要转换为定长的vector，低效并且不准确 and unsupervised。

特征需要用某种方法进行过滤，不是每个feature都是好用的（存在很多扰动的噪声，错误的user input）

两个步骤:

1. 自适应的选择有用的特征（看一个特征是否有用就看发生error的前后是否分布发生变化->说明有因果关系。）

2. 用选择的特征取检测调用的异常

4.1.1 自适应的选择有用的特征

特征的含义，就是调用链上的每个步骤（or 操作/服务），都有自己的指标数据，最常见的就是：延时，错误率，请求量等指标数据

看一个特征是否有用就看发生error的前后是否分布发生变化->说明有因果关系

因为不一样的repair相同的invocation的两端指标可能会差距很大，所以在考虑的时候主要是局部的repair对去考虑。相当于只考虑一个trace的一个局部的pair的，把这个考虑成是一个稳定的分布，对这个稳定的分布做异常检测。稳定分布用mean和标准差去拟合。

为了计算更加robust，引入slot和period

slot就意味着窗口，period就是周期，相当于引入过去的周期的窗口，和紧邻的窗口，因为这种场景下metric的周期性非常明显。

主要这样计算：

slot-> time windows

1. in the last slot

2. in the same slot of the last period

每一个invocation都有这些特征，用这些特征分别计算normal情况下的mean和std，之后算anomaly severity，最后算mean，错误发生之后重新计算这些值，错误之前计算这些特征值，做相减（相当于抓错误来临之后的change），大于百分之10，则我们认为这个特征是有用的。

4.1.2 race anomaly inference

每个invocation上，有很多这样构造的feature，如果任何一个feature上是异常的，则这个invocation是异常的。

查看是否存在一个有用的feature出现异常，大于某个threshold，则判定为异常

4.2 Suspicious Root-Cause Microservice Set Mining

找出可能的root cause 微服务集合

这里是microservice sets  而不是 microservice， reason是：

没有挖掘 微服务的序列和subgraph

这里用两个指标来刻画 two key metrics

1. support: 全部这些abnormal traces中通过全部这些微服务（来自于微服务集合）的trace的比例

2. confidence: 通过这些微服务的trace中异常的trace的个数

这两个都很高就是root cause microservice， 这两个就是有点类似于 precision和recall。

用核密度估计来画的non root cause和root cause的分布图。

用实验证实了这个定义，两个都高的情况下才更可能是root cause。

这个计算数量太大了，这么算不实际，所以要想办法去缩小范围，之后再计算，这里应用pattern mining algorithm （FP growth）来找出high supports的microservice sets

pattern mining的目标：

图中红色为异常的，{SA,SB,SD,SE}, {SA,SB,SC,SD} and {SA,SB,SC,SE} 其中都有找出SA->SB的调用关系，则这个SA->SB的support=1.0， 把大于0.1的找出来

4.3 Microservice Ranking

通过输入输出的调用关系的分数相减（因果报应）

分数计算：可疑分数是每个可疑集的JI分数和每个可疑集的集内可疑分数的组合。

其中J1:

五、实验部分

用open source的dataset：train-Ticket

注入三种错误

评价指标：

对于：single-root-cause

对于：不同level

对于：多root cause

和其他对比异常检测，说明特征选择的重要性：

• trace(MEPEL) supervised

• TraceAnomaly trace-based

• IF（isolation forest） invocation-based

做了消融实验

推荐阅读：

我的2022届互联网校招分享

我的2021总结

浅谈算法岗和开发岗的区别

互联网校招研发薪资汇总

公众号：AI蜗牛车

保持谦逊、保持自律、保持进步

发送【蜗牛】获取一份《手把手AI项目》（AI蜗牛车著）

发送【1222】获取一份不错的leetcode刷题笔记

发送【AI四大名著】获取四本经典AI电子书