开发者学堂课程【阿里云可观测峰会-行业实践分论坛：阿里云可观测峰会-行业实践分论坛】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/776/detail/13940
阿里云可观测峰会-行业实践分论坛
五、微服务异常诊断与根因分析算法实践
接下来分享的主题是微服务异常诊断与分析方法实践。
1，个人介绍
刘贵阳，是2018年加入阿里云服务团队。目前在该团队主要负责AIOps系统建设，主要关注持续异常检测、因果推断、病因分析这个问题。
本次分享将围绕三个方面发展，第一部分是AIOps系统有哪些能力，第二部分是异常诊断和对应分析法介绍，第三部分是微服务分析案例。这一部分呢，主要从方面展开，第一部分是AIOps系统，为了挑战，第二部分是从基础的视角检查一下ios系统能力，第三部分是日服务平台具备什么样的能力。
来看一下挑战。在过程中会发现，所面临的这个产品是众多的，模块众多，所涉及到的对象指标世界也是非常多的，非常复杂的。第二部分就是比较快，变化比较快，这里面主要有两部分，一部分是微服务的网络结构，很复杂，依赖关系很复杂，所以说导致服务变更频繁的日志格式转化出来的平凡的变化。还有就是界定不是很清晰，就是单点异常和界定异常的准确的来确定。第二个就是之间的关系，其实做答的包括一个服务内部之间关系是非常复杂而异常，随着网络传导的传播力度也非常复杂。
接下来，从学习的视角来看，第二次应该具有哪些能力，经历了一些数据的演进要解决AIOps的一些问题，必须要具备的是数据的建模能力好，从数据跟建模就避免过来看一下，就是到底需要从系统采集哪些特色数据，以及这些数据再喂给模型之前需要哪些有用的特征，假设已经这样一套非常复杂的工具帮去解决特征的这个部分，接下来这种设计不同的一些不同的一些模型课程还要去配不同的一些模型。当拿到一个模型之后，会涉及到模型评估模型的更新评估主要会分为性能的评估以及准确的评估模型的更新可能会涉及到这个模型是不是不太适用了，以及对于一些未见过的数据，或者一些比较就是偏离，偏离分布的一些数据，可能有些东西的策略这个时候可能都需要去更新的一些模型。在整个生命周期过程中其实每一步都少不了人的一些参与。比如说最开始的时候需要明确有哪些数据，以及的课程质量怎样，数据质量怎样，同时呢还要会模型做监控，还要对模型做一些事情，到时候要考虑哪些方法？
接下来呢，要谈一谈SLS是什么，日志服务平台呢其实是一个云原生可观测的一个平台，为这个log、 trace的提供这种大规模低成本实时服务。然后最核心的两个点在于统一的接入，可以展示的服务，然后它可以覆盖的场景是包含了开发、运维、运营、安全。
接下来来看SLS提供的一些基础。首先下面这一层数据接入层，在这一层里面，其实是要对系统的可观测性的数据作全方位地介入。比如说变更事件程序日志，中间键的一些日志，包括系统的一些系统日志，甚至可能依赖的一些产品的一些日志，包括所服务的这些云原生的这些code ：matrix的一些指定的数据。往上提供了两个非常核心的能力，一个是对于的数据的一些服化处理，一个工具叫做加工，还有一个就是非常的分析能力，就是思考的能力。通过这种转换，可以把云原始数据按照不同的场景跟需求不同的特征存在的laptop，甚至top道中去，然后在这个之上，会有不同的这种消费的形式，比如可以通过搜索方法可以做这种设计的这种查询，同时可以通过这种方法，去做一个消费，同时可以去批量的去拉出来的数据，然后做这种模型的训练。在这之上会针对这些特征，包括指标特征，根本特征，能够一些标签，就是一个比较重要的这种标签标注的一些能力，在这个基础之上，才具备了建模的一些基本的要素，可以利用一些算法工具，比如说统计算法，机器学习算法，深度学习算法去借比如各个场景的一些问题，比如说扩容到景区和文本模式的挖掘，然后根据分析的定位等等，以及系统的稳定性的一些观测等。
到了下一个板块，就是异常诊断算法跟APP的一些介绍。这里先要进行对于微服务做一些系统一些拆解，同时要从数据和算法的角度去看一下如何来建模能比较好的去解决这个问题，从不同角度来查一下。
针对于历史数据而言，其实能做一些工作，比如说从历史数据里面挖掘出来一些系统的瓶颈，然后以及系统在调度过程中的一些热点，就是通过系统的一些指标，可以做相关的一些类，比如说哪些可能。可以把它放到不同的这个体系里面去工作，就做一些指标的关联跟应用分析，这个时候其实更多的场景就是在一个垂直角度来看，各个模块之间的指标的一些异动联动的一些问题，还有就是全面的分析，这个时候呢，可能会涉及到动力跟这个网络传播链等等，最后一部分做成关系，这部分也是非常重要的，因为在线上这种其实量比较少的，在产生故障的时候，其实是要大量的去汇聚所有的所有的些告警指标，包括工单等等，然后事后，可以去根据它来复盘来去做这种流量的回放，然后去做这种演练。再往下，在当前的事件，可能最核心的观点就在于诱因长在哪里，然后以及能不能够更准一点做一些配合，然后针对这些产生的这些历程之后，要做快速的止损，以及非常好的这种更新的这种传播性，就是要做一些分析。对于一些未发生的一些事情呢，可能需要做一些故障的预测，容量的预测，包括可能做一些趋势，一些判别，包括热点，热点分析等等，这个地方其实核心的这几点，其实是隐藏掉的一些分享，觉得还是很到位的，所以直接用了。
可以通过系统角度来看认为有哪几部分。
第一部分呢叫做离线建模，这个过程呢，非常核心的点在于离线的出仓，这个仓里面呢，是所有的数据，同时呢，还有这些服务标准服务里面呢，它能帮去做的一些样本，在机舱里面呢，是通过分析的作业可以产生特征，然后根据下游的很多场景的任务呢，去训练不同的一些模型，这样呢，以备于后续来使用。
再往下，把这部分做进系统这部分，这部分系统的核心能力在于会实时计算，部分会提供特征的生成跟不行的准备，可以看到这边有很多数据，数据会通过这个分析的作业，跟这个一些近似的这个模块儿，会生成需要的一些特征创业特征服务
到最后呢，就是真正的这时候就需要通过计算在线计算模块把的热数据的一些特征，包括的一些模型过来，然后做这种对服务系统做一些推断
这个是一个典型的微服务的一个部署的一个模型，可以看到两边分别是两台物理机，在物理机上通过这种虚拟化的手段隔离出来不同的环境，服务是或者在两台机器上的服务器也是很多代理商服务，服务和服务之间是通过这种网络可以关联起来的。这样的一套系统，其实的服务的部署，其实是非常是混不的，故障中国可以非常快速传播，服务跟基金的关系？其实是动态发生变化的，指标季度其实是比较细的，其实可以做到级别的一些调监控。针对左边的这一个物理模型可以抽一下，可以把它变成两部分，第一部分呢，就是服务点跟机械的一些依赖关系，这部分可以通过的数据可以拿到，第二部分可以通过流数据可以找到服务跟服务的一些关联，所以就把这个图给补充完整。
一起来看一下微服务系统需要关注哪些点。第一部分可能主要是容量的一些管理，就是基础的一些利用率，以及能否提供这种弹性的这种扩缩容。第二部分，其实就是管理配置的编排，，主要点在于就是应用服务间的依赖关系，以及自动化部署。第三部分就是今天所关注的核心就是服务质量监控和诊断，这个时候可能会涉及到数据的采集，包括这个基础设施，以及服务的一些监控和快速进行更新的定位诊断。
首先来了解第一个点，就是如何通过指标了解系统，下面稍微抽象一下的服务模型，就是云生源微服务环境中，其实服务是依赖于容器，处在不同的。这里呢，一共有这几类指标，一类叫做服务的业务的指标呢，可能更多意义上讲，应该是流量，延时等等，第二部分，就是所依赖的这些库存每时每刻消耗的一些资源来讲，就是通过这种网络流量，然后以及的cpu的这个使用率等等，包括磁盘的io的情况，还有一个就是所部署的物理机的一些指标，有这几个对象，对于单个对象的而言，需要关注的是这个对象本身的健康怎样，以及在这个过程下可能作为指标，指标之间的依赖关系是如何？
第二个呢，就是把它做一个系统而言，可以看一下这个系统健康度怎样，然后以及系统各模块之间的一些依赖关系是如何的呢？就可以提出就会出来三个问题，第一个问题是当前是否有多维度之间的关系是怎变的，系统之间的异常是如何传导的？
首先来看一下，就是如何通过图来看这种单时序的一个演化，称为zebra。是从系统中计算出来的，就是每隔15秒去采样，在15秒之内某一个服务的一个平均的延迟情况，可以看到它的波动噪音还是很大，但是可以看到这两个点，其实在细微之处有一个下降还有一个是缓慢上升的，这种模式实现的，需要关注一下这个模式什么样的模式，这时候会引入一个新的概念叫做split，这个应该是当年应该是零几年，二零几年的时候的PCK的一个文章，主要的点在于在一段在一个单位的一个序列里面，能否通过一些小的一些连续的波形，然后来表达当前这个序列，使得当前的这个表达具有一定的排性，这句话的含义就是说，要要在一段观测里面找到一个连续的一个波形，这个波形更加清楚代表自己。
这个过程中就可以沿着这个思路，有很多的同学会去研究系统的一些表达变化，这个时候会提出一个东西，叫做演化状态演化的一个网络，简单讲就是说在一个单纬度的一个时间序列里面，可以把它按照一定都可以做切分。比如可以按照小时或者是按照天级别或者做一些在每一个区分地分里面，可以找到一个或者任意多个连续的一个设备的一个状态，用来唯一表达某一个分段的一个表达，看到X减一跟T跟T加一，其实加一这个时间段分别寻找出了不同的这样的一些表达，就是1234，然后在这个在这个持续演化的过程中，其实是可以美誉出来这个序列所有的状态，就可以知道序列之间状态的一个演化关系，说白了其实就是状态一到状态二，在观测序列上来说它的一个转移。就可以在某一段时间之前这段时间拿到可以拿到一个状态之间的演化关系好，这样就可以通过一个网络图来表达图网络中的一些节点，其实就是这个网络其实就能比较好的来表达一段时间观测以来当前的一个状态。接下来其实要去做一些预测，预测什么呢？预测下一个时间段，一个时间段的状态应该长什么样子，所以就可以通过XP剪一根XT时刻来预测X加一这个时刻的状态是什么样子呢？就可以做一个网络，这样可以把每一个图网络作为当前系统的一个一个领域。可以把当前的这个网络作为作为系统在一段时间的一个一般的把这个一般的放到一个序列的一个模型，类似于RN或者M这样的一个算法里面，模型里面可以学到它系统演化的一个特征，从而可以去预测下一个时刻，一个状态，就可以构造出来一个样本的空间，这样的一个特征，然后去做这个文章是发表在这个2021年的一个WCM上。
来看一下这个文章的一个实验结果，可以看一下，目前可能主要是描述这个流量的一个情况，有两个维度指标，一个是流量，这个流量还有一个网流量，这个流量里面，可以发现1234，4个时间片的一个视频。可能是呈现这样的状态，在这个第二就是两个这个时间序列，先把进行对换，可以分别找不同的这个可以举出比如说si的2、3，怎样分别对应的是B图中的一些状态的节点，然后通过这种反复的这种学习，可以达到稳态情况下的一个竞争关系。这样的话就可以看到，比如说在这个第二个时间阶段，可以看到2跳到8，8跳到23，2这条线比较粗，意味着偏离，偏离异常的一个概率比较大，可能会有些问题需要去关注，这样就比较好的去看，在单位的时间上来看扩大当时体的这个图来看一个状态，一个演化规律，能够提供比较好的一个特性。
刚才提的其实更多的是从这个角度上来看时间特征，能不能通过系统角度来看一个高端的一个点的方法。对于现阶段的检测，做的其实就是系统，可能有很多个节点，多个对象里面都有作为一个特征，每个特征呢，会通过若干扰检测器产生不同的一些事件，包括同比、环比或者检测，包括机械的一些手段，产生很多的一些事件。然后再通过，再通过反馈的一些手段，比如说人工达标，或者是说人工来调浴池套餐等等的手段，然后进而指导这些检测器更好地工作。可以发现在整个过程中，所处的这个对象其实还是在微博系统中的某些观测对象，就带来一个问题，就是所需要关注的维度是众多的，数量众多的，然后在数学这个角度上来讲，就是它发生异常的概率是非常大的，但是是不是都要去关注这些呢？可能也也不太一定，所以说想的是能不能但是怎来做一个客户端，针对于这个系统的一个检测。
一起来看这两个数据，第一个数据是系统中十个词在某一个维度，就是每分钟的这个流量的这样的一个时序图，可以看到，就是们的首先第一点，波动还是比较大的，噪音也是比较明显的。第二个，看到它的形态是非常丰富的，比如说像这个cars跟这个pop，可能是这种缓慢的走动式的上升，还有一个就是缓慢的这种阶梯式的下降。还有一个问题就是它的Y轴。还有就是这个轴其实差异是比较大的，这种的话对于设计微服务来说，其实是非常挑战
第二个，就是从一个实体对象来出发，比如可以看的多为特征的一个构造，可以看到有的这个每分钟的这个流量，然后以及在一分钟以内就是超过十毫秒的请求的数量以及超过100毫米的数量。甚至还有的平均响应延时，以及九五分数的一些事情呢，看到它这个有很多可能相似的很有可能都是一条直线，可能有很多种特征也是非常丰富的
这个时候，需要几个问题，第一个就是如何区分流量的自然下降。如何区分流量下降，还是依赖服务的产生危险异常而引发的当前这个服务的一个下降，这是第一个。第二个就是算法模型，能否适应系统的一些自律。因为在生活中会有很多种就是自动重启的一些方法，或者是比如说这个服务可能超过了一些负载，可能超过的现场就重启了。如果配置的个PPT的话，可能在某个情况下，可能会随着这个流量或者消耗，可能会做一些扩展，这个时候其实都会变成系统学习的一部分，就是经常遇到的一个问题，就是告警报的治理能在告警产生阶段都处理掉。是因为数量告诉让实在是太多了，所以大概率上会产生这样一个风暴，能不能从系统来做就只有一个告警可以解决问题这个时候就自然想到一个问题，就是说这些都是围绕着能否把系统作为一个整体进行检测。
接下来，可以一起来看一下设计的一个出发点，就是说本身应该就是一个恢复的一个模块，它就是一个结构示意图。每一个图，每一个图中的这个节点，其实都是有这种依赖和被依赖的，就是影响被影响的关系的。每一个服务其实都是对上层提供的，有这几张只要潜在的一个规则，第一个就是服务的ella可以反映出来服务的质量，第二个就是各个子系统分别对应方保证服务，还有就是系统异常会按照一定的逻辑向上传递。接下来如果涉及到系统，要采集，想的就是可以通过这种流量，不同的压力流量python，然后给系统注入一些流量，然后来模拟系统一个服务情况。而产生这些正常时候的系统的一些观测，可以做一些，每隔一段时间可以给系统注入这些
异常可能大部分是媒体出来的，比如说内存泄露等等，把这个不如享受这个现场录下来，都有一个负样本，接下来要去建模，对图模型其实更好的是在于处理了，就是具有传递依赖关系的这些景点的一些特征的一个原理用什么呢？就挂这个分类任务，这个分类任务主要的问题就是在解决，就是当前这个服务是不是正常，以前可能是哪一个服务，可能有问题的一种方法来去学习，然后来帮去定位到底哪个。
第二个，就是刚才其实一直都在讲的是系统中的指标观测，可能稍微系统的文本给很多信息，这一部分可能会涉及到就是第一部分的图会是的这个系统的，就是物理机的信息，这里面会包含在什么时间，然后某一台机器上执行了一个命令，然后命令的一些状态
这张图表达的是的一个世界中心的日志物理意义，就是说某台机器上的某一个PUD失败了。这样的一些数据，其实可以做一些事情，就是可以对系统的事件做一个粗分类，这个粗分类其实就是哪一个模块，比如说K8S的模块，然后一些操作有一些action，然后以及的这个内容，这个时候可以先对数据做一些标签分类，是这些处理的部分呢，是非常关键的，就是要把文本中的一些噪音去掉，或者是把这些，没有别的情况给挂掉。比如说像第一个里面可以把时间这个点，因为按照顺序来排文本，所以时间可能特别关键，然后进程ID可能也可以把它去掉，然后还有就是些hold，因为它很多都是些MD5包括随之产生的一些url编码把这东西去掉，就能拿到一个比较干净的一个文本，可以做一些不同的微整，这个时候会引入。
这个系统上做一些微调，使它能更好地适应的日志的时候，通过就能产生出来一些文本的一个向量，从而实现了text这样的一个表达，这个时候可以按照实体，按照采集的时间，然后把事件实体维度上做展开，就可以看到一个事件的一个序列特征。刚才提到了是时间序列
接下来，要谈一下就是系统的这个graph ：graph里面其实最核心的点就在于就是这个边怎来拿到这个图？其实稍微一个模型，就是这里面有三类，第一类是，还有一类是服务的进程节点，它有这几种关系，有一种关系就是a是部署在组成的，可能就是一个部署关系，这种其实就是说服务本身的压力可能会产生影响，系统的一些指标，其实也会影响到这个服务本身，对有一种关系的一种非常的，还有一个叫做正常的一个行业。
第三个，就是服务器跟服务器的关系通过。这些编辑中或者在现实生活中这些信息，可以用这一种手段是可以通过这个测试，可以比较容易拿到破跟机器的问题。第二可以通过这个网络上的抓包分析，可以拿到eco的一些关系。可以通过这个方法可以可已通过数据。
在拿到了这个节点根节点的特征，以及边的关系之外，这个时候要去构造一个模型去用来做的一个定位，这个时候就参考是应该是两年前发的教义构图设计网络这篇文章，然后在服务系统中，其实是有不同类型的节点，不同类型的节点之间其实是有不同权重的边的关系的传导，这里会出来这4种直接的关系，就是服务跟机器之间的一个关系，第二个就是服务跟服务之间的关系，第三个是指标跟服务之间的一些关系，还有就是机器跟服务的一些关系，这四个就构成了这样的四个异构图这样的一个。就通过简单的简单的这些关系，把成果然后放到一个链接里面去学，学的是各个节点的一个MV，然后最终接到一项任务，其实是一个分类任务，因为会反复的朗读异常，然后去定位当前这个故障状态下可能是哪一个节点，某一个产生一些异常。可以通过一个MV，然后就可以去对接分配任务，可以把这个网络给关联起来，通过这种方法可以去学习。
接下来最后一部分就是微博系统的这个案例分析
下面介绍的环境，数据，都是围绕着日志服务展开的。在这个是搭建了这样一个系统，可以通过ilogtail去采集这个物理机的一些指标信息，可以从ilogtail去物理机上去采集的这个word的信息，同时还可以通过在集群中去采集这个K8S的promertheus的一些数据，同时要做一些这种探针的方法，然后学习的一些数据。然后再K8S把这个网络的数据也改过来能够形成一个比较完整的一个环节。
涉及到一些数据实验特征，这张图表达的就是这个微服务系统的物理机的一些特征，可以比较快速的去拿到这个系统的一些数据，包括cpu利用率，然后包括它的内存的使用情况，包括磁盘的使用情况等。还有一个信息是这个K8S的一些指标也是可以统计出来的，第三个就是配置数据，会拿到这个入口服务，入口服务的一些服务指标这就是第三个指标就是的世界数据。同时还有就是系统的一些数据。这些数据都可以通过的服务非常好的做加工跟整理以及特征的一些转化生成
进行实验环境的介绍，在这一部分先进行一些流量的模拟，使用cast进行流量模拟提供了不同用户，不同服务入口以及不同的频率，还有就是不同波形的一些流量的压力。使得现在的这个更就是波形更丰富，然后更能逼近的一些场景。第二个就是在实践中一些异常，这块使用的是SGT工具，分别在物理金融环境中注入了以下四种故障，第一个呢，Cpu故障，第二个就是内存泄露，第三个是网络延时，还有一个网络丢包的命令呢，就在表格中已经指出来，这个里面需要讲一点，就是希望这些异常尽可能的去影响的服务质量，否则很难起到真实的这种故障诊断定位的作用。最简单例子，比如说一台物理机内存可能是32个GB，目前这个系统跟这个微服务一共可能用了十几个GB，把这个物理机上注入一个10GB或者是注入一个3GB，这样会照成一个内存的一个泄露，或者内存的使用。，仅仅就是在这个官司流程，只能让你的机器的内存指标可能有所上升，这个时候其实并不是一个有效的能影响服务质量的一个异常，所以就建议在主场的时候，更多一点考虑如何影响服务，这样的话才能找出这种真实的这种环境。
这一块就就勾勒出一张就是微服务的一个动图，这里面粉色的这个节点主要表达的是服务节点，服务之间是有连接的，就意味着就在时间还有一部分，就是一个方框，表达的是这个服务之间的依赖。
接下来进行一些实验结果的说明，实验样本是在一个聚会群中部署了这样的一个服务系统，通过反复的就是增加流量的压力，然后以及三四小时的一些异常，然后得到的实验数据，然后通过的思考，可以得到相关的一些特征，然后以及POD跟ECS等等，可以拿到就是点之间的一些关系。就是在这几个主要服务里面，分别注入了不同的历程，cpu，内存这个这个异常里面都是比较好的去定位的，就是在这个网络里面其实定位还不是特别好，究其根源是因为网络其实它的传导性是非常复杂的，而且流量当时的情况也是可以看到像这个user，包括这个前端等等，这个只能稍微低一点也是因为在途中的一个开通的一个所关联的一个点的词也是有关的，可能关联了很多很多的服务
下一步的一个重点，就是现阶段其实实验室大量的使用的网络，对于日常的现场的技能要做进一步的探索，就是系统其实很多地方都需要标签，比如说文本的构造这部分可能需要一些运量，可能会接下一个任务使得特征可能更好，当拿到的一些标签，这个东西其实对于生产来说其实是比较难的，对于去构成这样的一套实验环境，其实这个还是蛮高的，第三部分就是探索是否具有更的网络结构比较好的去迁移到其的微服务网络的物理环境的结构。能不能有些手段可以使得的微服务的这个网络结构跟微服务之间，就是可能没有一些关系比较迁移，第二个就是产品的功能这一块会逐步的将这个场景的算法整合到舞台去，然后接下来会在平台上提供建模标注的一些能力。
