数据洞察创新挑战赛-智能运维赛新手训练营：课时1：微服务系统中的异常检测与根因定位分析
微服务系统中的异常检测与根因定位分析
内容介绍
一、 多源异构的存储平台
二、SLS是什么
三、相关文献分享
本次分享将分为三个主要部分：首先，简要介绍多元化数据存储平台；其次，将详细讨论智能运维系统的分解工作；最后，分享一些相关的研究论文。
一、多源异构的存储平台
在这一部分中，我们首要要讨论的是为什么需要采用这个平台以及这个平台如何解决了哪些问题并提供了哪些能力。
一开始，当一个系统产生了警报或告警时，通常需要涉及指标、日志、链路等一系列排查和定位工作，这时会牵涉到多个模块的协同配合，系统之间的协作工作通常相当复杂。而且，由于在多系统环境中，自动化的数据关联常常受到限制，成为了一个巨大的瓶颈。这会导致排障流程变得较为冗长，从而影响了问题处理的时间。因此，对于我们来说，理想情况下，我们需要一个平台，可以轻松处理各种类型的数据，有效地解决数据关联的问题，并提供丰富的分析能力，以帮助我们快速进行故障诊断和问题定位，最终生成相关的报告，这就是我们在这部分要探讨的核心内容。
二、SLS是什么
SLS是什么呢，是一个为Log数据平台大规模、低成本和实时化的日志处理提供服务的平台。它集成了数据加工、查询、分析、可视化、报警、消费和投递等多种功能，为开发、运维和运营等场景提供了强大的支持。
接下来，我们将对智能运维系统进行一些详细拆解。
智能运维系统与地铁系统有一些重叠之处，从一开始，我们需要解决的问题包括数据采集、特征工程、模型构建等多个方面。下一步是实现模型的数据处理、超参数调整、预训练和模型上线等一系列操作，同时要考虑模型的实时更新和与不同监控系统的集成，这构成了一个完整的生命周期。
进一步拆解，我们可以将智能运维系统分为四个主要部分。第一部分是离线建模，第二部分是进线服务，第三部分是在线服务，最后一部分是用户数据标注和反馈。
系统会整合大量数据，包括客户的标注和系统事件等，这些数据在离线处理中被转化成不同特征并存储在系统中。不同特征对应不同任务，下游的模型任务也因此产生了各种多样的场景模型。这些模型发布后可以在在线服务中进行实时计算，进线服务主要关注最新异常数据的产生，以及在这个时间窗口内产生的指标和事件等数据。
然后，在前面提到的服务，需要快速地将数据提取并进行加工转换成特征，然后将其传递给模型。接着进行智能诊断，通过诊断，用户可以不断提供反馈，包括黑名单、白名单以及不同维度的信息等。这种互动产生了大量数据交流，总之，该系统需要具备高效的数据处理能力。
再往下，通过监测我们可以看到，在系统的最前端，它接收来自多种来源的结构化和个性化表达数据。
这些数据主要来自于指标事件系统、时间序列数据、日志数据，以及有关系统本身的发布和变更数据，通过对这些数据进行结构化处理，我们可以构建出微服务系统的依赖图，这个图可以通过多种方式生成，包括手工配置、容器化等方法，还可以使用类似 epf 的工具来监测网络流量，以了解流量的进出情况。
此外，我们还可以通过这种方法了解业务侧的跳转和关联，然后基于此构建领域模型。通过积累经验，不断优化领域模型，我们可以针对不同的数据情况进行建模和分析。最终，将这些事件产出，形成险集合，需要人工进行评判和操作，人工智能操作结合当前结果，不断积累经验，形成一个知识库。随后，我们可以利用各种手段，如大型语言模型等，生成故障手册等内容。
接下来，我们将重点关注智能运维领域的算法工作，并分享相关论文。首先，让我们看看需要算法工作的哪些方面。
首先，我们有时序场景，其中涉及到指标、因果关系和高维智能下探，这包括持续异常检测，甚至可以对整个微服务系统的指标异常进行建模。
接下来是非结构化文本处理，它通常分为两大类，一是规则型，将文本转换为模板，将事件转化为结构化数据，另一方面是自动标注，需要标注哪些是实体，哪些是服务名称等变量。此外，还有某些日志或者一段日志可能会表达特定含义，例如与机器或某一服务相关。这可能涉及到主题的提取，以及更复杂的故障报告的抽取，这些情况通常统称为非结构化的文本场景，其中涉及告警治理。
在系统分析中，通常从告警开始。一旦某个告警产生，系统需要迅速搜索与告警相关的异常节点、服务名称和观测指标等所有事件。最终，这些事件从高频发生到反复聚合，以便能够快速生成摘要和报告。然后，运维团队可以根据这些数据进行快速诊断和分析。
此外，还有一项重要工作是更新的定位和分析，其中包括基于调用链维度的系统瓶颈分析。这些瓶颈可能不是故障，但它们可能会影响系统的性能。还有一点是对异常的影响力评估。
最终，上述排查方法会生成很多处置选项。针对这些选项，我们可以根据历史故障报告生成不同故障场景的模拟，以便培训新员工或者提供参考指南。
在这个场景中，我们首先选择了一个相对基础且通用的情况，即时序事件场景，在这个场景中，问题可以统一成以下几类。
首先，是单指标异常检测，通常涉及对单一指标的异常检测和分析。这通常是比较简单的情况，例如在以下这张图中，我们可以看到在某个时间段内，可能存在多个异常点。
这种曲线的情况可以反映系统的一些问题，例如开始时的故障或某台机器的CPU抖动。第二种情况是在相对平稳的指标曲线中，可能会出现显著的下降和迅速的回升，或者整体趋势突然发生变化。这种情况下，通常会产生一个较大的波动。
另一种情况是由于版本升级或服务扩容等原因，导致某一指标的波动性增加，尽管它的波动仍然在正常范围内，但波动的振幅可能会变大。此外，还涉及到同类指标的实体异常，这意味着对于某一指标，我们可能不知道指标本身是否异常，但我们可以观察到在同一指标下有多个客户端，它们的数据分布可能有所不同，因此我们需要在同类指标下寻找离群的样本。
进一步，还涉及到单时序多维度的异常。这意味着在某一时刻，某些维度的数据可能会异常，如CPU下降或流量波动，但这不一定表示整个系统出现故障，而可能是由于特定业务或多租户系统中的某一用户引起的变化。
因此，我们需要通过不同的方式来确定实体对象是否异常，或者只是某一指标在某一维度上有分布差异。
对于时序数据，我们需要介绍两种方法。首先，我们需要了解如何观测时序数据，以及如何更好地理解时序数据的状态演变。在这方面，我们可以使用以下方法：
在处理长周期数据时，我们首先将数据切分为不同的时间片段，然后将这些时间片段量化成不同的状态。随着时间的推移，状态会发生变化，而通过观察状态之间的转移，我们可以更好地了解系统的健康状况。这里引入了一个新的概念，即状态的表示。状态的表示是指能否在某个时间片段内找到一个代表性的小片段，该片段能够有效地表达当前时间片段的形态。
对于历史数据，我们可以使用不同的方法提取许多时间片段，并为每个时间片段分配不同的状态。在时间维度上，我们可以将这些状态量化，并分析状态之间的转移。然后，我们可以使用这些状态和转移数据进行建模。具体而言，我们可以使用这些状态来预测下一个时间片段的状态转移，从而自动检测状态的异常。这种方法允许我们发现当某一状态的预测与实际结果存在较大偏差时，系统可能出现异常。
这种基于状态频繁性的方法已经在相关研究中得到了广泛应用，并发表在2020年的一篇论文中。核心思想可以通过下图来表示。
这个方法的出发点在于，我们是否能够找到一种通用的方法来处理时间序列数据，以确保它们在多个频率上保持一致性。您可以查看下面的图表来更好地理解。首先，我们有一个包含不同未标记时间序列的数据集。然后，我们分别在时间与频率上对这些时间序列进行表示，观察它们的差异。为了增加数据的多样性，我们可以引入一些数据增强技巧，例如添加噪音、波动或偏移，以使不同时间序列之间存在一些差异。接下来，通过一个映射模块，我们将不同领域的表示映射到一个共享的空间中，称为'Space Z'。
然后，我们执行一致性损失的设计，以确保相似的样本在'Space Z'中更加接近。这涉及到三种损失，即时域、频率域和时-频域。其中，时域一致性损失表示不同样本在时间域内的一致性，频率域一致性损失表示频率转换后的一致性，而时-频域一致性损失表示时域和频率域之间的一致性。
损失的逻辑相对简单，它要求在时间序列、频率和时-频域之间计算距离，并将它们作为整体损失的组成部分。最终，通过这个设计，我们能够更好地权衡时间、频率和时-频域之间的一致性，从而实现更好的泛化能力。
接下来，我们将从微服务的角度来看一些层次和方法。在微服务领域，我们通常可以看到三种类型的节点：服务节点、继承节点和基础节点。
不同的服务通常运行在不同的机器上，它们的载体是一些进程。这些服务之间可能存在各种关系，无论是基于微服务架构、容器化的微服务还是静态非容器化的服务，都可以抽象成一些关系模型。
右侧的图表表示了一个请求的生命周期中，不同阶段打印的不同日志以及状态顺序。在这个领域中，有许多相关的文章，例如第一个文章提到了'RCA'（Root Cause Analysis），思路相对清晰。这篇文章大约在三年前发表，它的核心点是通过某些手段，可以在分布式系统中进行大量的数据采集和观测。对于每个服务，它可以生成各种类型的指标。这些指标后续可以用于检测异常。
一旦发现异常节点，接下来的任务就是通过分析日志和指标来定位问题的根本原因，这通常涉及到查找引发异常的事件、指标或服务，然后从中找到问题的源头，这需要深入的系统理解和日志分析技能。
另一篇相关的文章则讨论了在微服务环境中的分布式系统中如何进行异常检测和根本原因分析。这些文章的核心思想是使用各种技术来监视、收集、分析和可视化服务之间的数据流，以便更容易地检测问题并追踪异常，这些技术包括使用开源工具和框架来处理和分析大规模的日志数据，以及构建实时仪表板和可视化工具以监视系统性能。
总的来说，这些文章探讨了在微服务架构中实现异常检测和根本原因分析的不同方法和技术，它们强调了监视、日志分析、指标收集和可视化在确保分布式系统可靠性和性能方面的重要性。
"我能够迅速构建属性图，这就是所谓的属性图（attributed graph）。在生成属性图时，我可以进行筛选，将一些与异常节点没有直接关联的节点去除。这样，我就可以生成一个包含异常信息的字符图。对于这些异常，我可以通过一些方法，为它们分配一些权重，并使用迭代算法将它们归纳到某个状态下，以得到一个经过排序的异常列表。在下面的图中，清晰地表达了算法的核心要点，010其实是之前已经简要提到的。在这里，服务节点通常用"S"表示，而物理机节点则用"H"表示。
同时，关系包括服务与服务之间的关系，以及服务与物理机之间的关系。
而第二、第三、第四步则分别是在当前环节的详细描述。第二步表述了当前环节中的所有异常节点，以及与它们直接相关的节点，形成一个子图，也就是234节点的子图。
它关联了ses五，h一个hr对，然后三，这相当于如何去统计不同的这些权重，这些权重肯定都是来自于系统的一些测量指标，还有人为经验去设计的一些参数，用于构建这些权重。
然后，在下一步中，我们通过对这些权重的图进行迭代策略来生成结果，最终清除了结果中的一些可疑信息，从而定位到一个服务的问题。那么接下来，我们将重点展开讨论这个算法的三个部分。
首先，我们将关注提取信息，第一部分被称为异常组件的权重。在这一部分中，我们会使用一些权重，如wwa和wah等，来计算异常的列表。然后，对于列表中的每一项，我们会分配一个固定的权重，用来标识当前异常的执行程度。接下来，wn表示正常服务和异常服务之间响应时间的相关性，表达了两个响应之间的关联性。异常服务节点与服务节点之间的响应时间和异常服务节点平均延迟时间之间的相关性。wh用于表示服务和物理机之间的权重关系，作者使用了服务、节点的评分以及rt来评估这种关系。接着，与主机的一些性能指标进行了一些计算，包括CPU利用率、内存大小、I/O等，最终得出了一些相互关联的判定。
在图中，还可以看到一些as，如as2和asns，这些是为了量化异常。也就是说，当前的异常是由这个节点引发的。他们需要考虑综合上下游和相关节点之间的异常权重计算。在这个阶段，可以采用多种方法，比如使用up或其他数据，甚至abg等等。你可以使用这些数据来更好地区分异常和正常情况。接下来，我们将讨论资源管理，它与上一篇文章相似，但关注点在c和d的部分。c和d部分主要涉及组件的处理，通过一些精细的手段来实现。
例如，EPF或其他工具可以用于获取服务请求的IP地址，从而构建依赖关系图，然后在这些依赖图中可以构造相关的指标。对于所有这些指标，可以使用一些因果推断算法，最终找到因果关系图并确定权重。问题可以简化为给定一些组件C和相应的观测指标M，如何找到引发异常的组件以及与该组件相关的指标？
为了更好地理解下面的工作，可以进行一些符号说明。例如，服务器实际上是组件C的一个实例，而更多的组件C可能会有多个指标。M表示指标集合，用M_C表示组件C的一组指标，而小写的mi表示组件C的单个指标。例如，对于服务，可能会有显示时间等。
接下来，图中的核心部分在于C和D之间的关系。A和B的关系相对容易理解，我们建立了一个图，然后在异常发生时，可以迅速进行筛选和过滤，将剩下的候选指标集合抽取出来。然后，我们可以使用相关的因果推断算法，如格兰杰因果检验或PC算法，以及结构方程模型等，对这些指标进行进一步分析。这些相关方法可以在需要时进行详细研究。
最终，我们可以将这些指标放入一个图中，每个节点表示组件C的独立指标MYS，边表示异常的传播路径。在上图中，我们可以看到存在一条边。
这个M一批常指向了M二P三，这表示指标M一P三影响了指标M二P三。随后，我们在这个图上进行迭代。
在迭代之后，最终它会收敛到某个状态，然后可以获得不同指标的一种排序，相较于之前的文章，这种方法能更准确地确定不同组件指标之间的因果关系，包括其影响集合的上下文。然后，往下继续介绍"Deep"部分。
与前两篇文章不同，"Deep"部分更多地关注不同模块和组件之间的连接。通过多种手段，可以快速获得相关的依赖图。然后，这些指标通过机器学习方法进行整合，形成一个因果图，然后应用不同的方法进行推断。这种方法在处理规模上升时非常有效，但准确性可能会下降。最近，有许多相关文章致力于解决微服务系统的问题，如基于追踪数据的方法以及如何整合不同信息来源等。
接下来，我们介绍的这篇文章是由大学的团队完成的。它处理了两类问题，一类是链路问题，另一类是与中断相关的问题。我们可以看到，A、B、D实际上是一个链路。在不同的链路上，会有不同的日志信息，如"Create"等。对于这些日志信息，我们可以根据结构和演化时间将它们绘制成下面的图。
这张图包含了上面的完整信息。每个框中，代表在生命周期内所打的日志顺序。不同的颜色代表不同的角色，例如服务器。
在不同的分支中，表示一些头部调用或异步调用，以及编码等。在这里，我可以看到不同的代里面实际上包含了不同的信息，比如在第一个代里叫做事件类型，然后后面是这个POST的API，表示操作的类型和不同的方法。然后，我们可以将另一条与此相关的日志抽象成这样的图。
接下来的工作描述了这个算法的具体工作方式，包括两部分数据和一些Python过程。在这个过程中，通常会使用一些正则表达式或其他工具来处理Python工作。然后，将其转化为不同的模型，然后使用tfd方法进行调整。根据刚才的结构，我们可以获得一个图。在这个过程中，它使用了带门线的kc。
为什么要使用带门线呢？因为我希望更好地描述某个故障或异常在传播过程中的情况，在这个过程中，我希望能够更好地了解当前节点的一步、两步和三步等工作，因此，采用了这种带门线的模型。
后面的内容是关于使用通用方法CDD进行检测的。当我们完成这一过程后，可以直接使用这个模块来执行检测。然后，我们可以一起来看一下当前模型的效果。左边的图表展示了在微服务系统中的准确度和召回率都相当高，整体的F1得分达到了0.954，这表现相当不错。
然而，需要注意的是，由于目前市场上缺乏大规模微服务的数据，并且对微服务的解构还没有得到全面考虑，因此仍需要进一步的研究和验证。
另一部分涉及到异常的检测过程，其中包括算法的结果。作者圈出了一个红色的部分，它表示某个异常的分数以及相关内容。综上所述，我们介绍了两类内容，一类是关于时间序列的处理，另一类是关于微服务系统如何进行有效分析的方法。
三、相关文献分享
接下来，我列举了一些相关文献，其中包括近五年来与日志领域相关的工作。
大家可以进一步阅读和学习这些文献。
