CN116756021A - 基于事件分析的故障定位方法、装置、电子设备及介质 - Google Patents

基于事件分析的故障定位方法、装置、电子设备及介质 Download PDF

Info

Publication number
CN116756021A
CN116756021A CN202310747971.1A CN202310747971A CN116756021A CN 116756021 A CN116756021 A CN 116756021A CN 202310747971 A CN202310747971 A CN 202310747971A CN 116756021 A CN116756021 A CN 116756021A
Authority
CN
China
Prior art keywords
event
sequence
fault
events
change
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202310747971.1A
Other languages
English (en)
Inventor
黄进
陈鹏飞
张涛
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Sun Yat Sen University
Original Assignee
Sun Yat Sen University
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Sun Yat Sen University filed Critical Sun Yat Sen University
Priority to CN202310747971.1A priority Critical patent/CN116756021A/zh
Publication of CN116756021A publication Critical patent/CN116756021A/zh
Pending legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/362—Software debugging
    • G06F11/3644—Software debugging by instrumenting at runtime
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G06F11/3466—Performance evaluation by tracing or monitoring
    • G06F11/3476—Data logging
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G06F11/3466—Performance evaluation by tracing or monitoring
    • G06F11/3495—Performance evaluation by tracing or monitoring for systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/362—Software debugging
    • G06F11/366—Software debugging using diagnostics

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Debugging And Monitoring (AREA)

Abstract

本发明公开了一种基于事件分析的故障定位方法、装置、电子设备及介质，方法包括：在目标系统模拟故障注入；其中，目标系统基于分布式运行时搭建得到；获取故障注入产生的事件数据，对事件数据进行持久化保存；对事件数据进行分组排序，得到若干不同的事件序列；对事件序列中的每条事件进行解析，生成事件模板；通过无监督方法对事件模板进行异常检测，得到变化故障；变化故障包括导致事件序列顺序变化的序列事件异常和导致事件时间间隔变化的性能问题；基于变化故障进行故障定位，确定异常事件序列，进而定位目标系统的异常部分。本发明能够基于事件分析进行准确的故障定位，可广泛应用于计算机技术领域。

Description

基于事件分析的故障定位方法、装置、电子设备及介质
技术领域
本发明涉及计算机技术领域，尤其是一种基于事件分析的故障定位方法、装置、电子设备及介质。
背景技术
近年来，在日常生活中提供各种服务(例如搜索引擎、社交媒体、翻译应用程序)的软件系统越来越普遍。现代软件相比传统本地软件规模更大复杂性更高，如何管理系统中的服务故障和性能下降成为市场的核心竞争力。在托管在kubernetes环境中的dapr这样复杂的分布式运行时系统中部署应用时，dapr控制面将把sidecar容器与应用程序容器部署在同一个pod上，这会引入较多的动态，可能干扰系统管理人员对故障问题的诊断。由于系统的组件众多，以及故障的可传播性(某个部件的故障不一定是它内部的问题，也可能是在分布式环境中由于故障的传播所导致的)，当出现问题时对故障进行定位将变得困难。用户无法得知故障的根因是在kubernetes集群，dapr sidecar容器，还是发生在测试的流程中。
发明内容
有鉴于此，本发明实施例提供一种基于事件分析的故障定位方法、装置、电子设备及介质，能够基于事件分析进行准确的故障定位。
一方面，本发明的实施例提供了一种基于事件分析的故障定位方法，包括：
在目标系统模拟故障注入；其中，目标系统基于分布式运行时搭建得到；
获取故障注入产生的事件数据，对事件数据进行持久化保存；
对事件数据进行分组排序，得到若干不同的事件序列；
对事件序列中的每条事件进行解析，生成事件模板；
通过无监督方法对事件模板进行异常检测，得到变化故障；变化故障包括导致事件序列顺序变化的序列事件异常和导致事件时间间隔变化的性能问题；
基于变化故障进行故障定位，确定异常事件序列，进而定位目标系统的异常部分。
可选地，在目标系统环境模拟故障注入，包括：
利用实验注入工具在目标系统进行故障自动注入；
或，响应于配置指令，在目标系统进行故障手动注入。
可选地，事件数据包括端到端测试事件、kubernetes事件和dapr事件，对事件数据进行持久化保存，包括以下至少之一：
将端到端测试事件保存到本地日志文件；
将kubernetes事件执行过程中，对api对象的操作记录在events中，并存储到etcd里；
采用node logging agent的方式收集dapr事件，通过在kubernetes集群的每个节点上以daemonset的方式部署一个logging agent服务，进而基于logging agent服务进入各节点上所有容器的事件目录，收集dapr事件并传递到后端存储进行保存。
可选地，对事件数据进行分组排序，得到若干不同的事件序列，包括：
通过事件标识符对事件数据中的各个事件进行分组，获得若干事件组别；
根据各事件组别中事件的时间戳顺序进行各事件组别的事件排序，得到若干不同的事件序列。
可选地，对事件序列中的每条事件进行解析，生成事件模板，包括：
基于固定深度树的日志解析方法，对事件序列中的每条事件进行预处理，得到token序列，进而删除冗余信息，抽取得到事件模板。
可选地，通过无监督方法对事件模板进行异常检测，得到变化故障，包括：
对事件模板进行向量转换，得到事件嵌入向量特征，并通过加权聚合得到事件语义向量，进而采用LSTM模型进行基于预测的异常检测，得到序列事件异常；
根据事件模板中各事件的时间差，得到时间差分序列，进而通过DeepLog方法检测时间差分序列中的异常时间间隔变化，得到性能问题。
可选地，基于变化故障进行故障定位，确定异常事件序列，进而定位目标系统的异常部分，包括：
基于变化故障进行故障定位，确定异常事件序列；
基于异常事件序列还原发生异常的滑动窗口，并对LSTM模型预测的下一条事件和真实事件进行比较，基于比较结果定位出发生序列事件异常和性能问题的异常部分。
另一方面，本发明的实施例提供了一种基于事件分析的故障定位装置，包括：
第一模块，用于在目标系统模拟故障注入；其中，目标系统基于分布式运行时搭建得到；
第二模块，用于获取故障注入产生的事件数据，对事件数据进行持久化保存；
第三模块，用于对事件数据进行分组排序，得到若干不同的事件序列；
第四模块，用于对事件序列中的每条事件进行解析，生成事件模板；
第五模块，用于通过无监督方法对事件模板进行异常检测，得到变化故障；变化故障包括导致事件序列顺序变化的序列事件异常和导致事件时间间隔变化的性能问题；
第六模块，用于基于变化故障进行故障定位，确定异常事件序列，进而定位目标系统的异常部分。
另一方面，本发明的实施例提供了一种电子设备，包括处理器以及存储器；
存储器用于存储程序；
处理器执行程序实现如前面的方法。
另一方面，本发明的实施例提供了一种计算机可读存储介质，存储介质存储有程序，程序被处理器执行实现如前面的方法。
本发明实施例还公开了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器可以从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行前面的方法。
本发明实施例首先在目标系统模拟故障注入；其中，目标系统基于分布式运行时搭建得到；获取故障注入产生的事件数据，对事件数据进行持久化保存；对事件数据进行分组排序，得到若干不同的事件序列；对事件序列中的每条事件进行解析，生成事件模板；通过无监督方法对事件模板进行异常检测，得到变化故障；变化故障包括导致事件序列顺序变化的序列事件异常和导致事件时间间隔变化的性能问题；基于变化故障进行故障定位，确定异常事件序列，进而定位目标系统的异常部分。本发明实施例通过对各个事件进行关联和分析，最终定位出故障所在的位置，发现产生问题的原因。除了收集系统正常执行数据外，还通过注入故障让系统产生相应的异常数据，实现了对正常/异常事件收集、存储、关联、分析。本发明能够基于事件分析进行准确的故障定位。
附图说明
为了更清楚地说明本发明实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
图1为本发明实施例提供的一种基于事件分析的故障定位方法的流程示意图；
图2为本发明实施例提供的dapr事件收集的整体架构示意图；
图3为本发明实施例提供的基于事件分析的故障定位方法的整体流程示意图；
图4为本发明实施例提供的一种电子设备的框架示意图。
具体实施方式
为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。
为便于本发明技术方案的理解，对本发明实施例可能涉及技术名词进行术语解释：
事件：事件是记录系统行为的一种方式，它用开发者可理解的文本来表现系统的执行状态，可作为系统排错和性能优化的依据。事件数据支持定位到特定的出错信息，支持细粒度的故障根因定位。利用事件数据可以了解系统的上下文。对于提升分布式系统故障诊断能力，提高系统可靠性而言很重要。
kubernetes：kubernetes即k8s，是能够对容器集群做编排管理的平台软件，具有自动运维管理docker应用程序的各项能力，比如容器调度，节点健康检查，自动扩缩容等。
kubernetes集群由master节点和node节点所组成，master节点是中央管控节点，运行管理集群的进程。node节点则是集群的工作节点,主要承担运行应用程序的任务。应用程序以pod的形式运行，pod是kubernetes中最小的调度单元，同一个pod内的容器能够通过localhost直接互相访问。sidecar容器指的是在应用容器的同一个pod里，启动的另一个用于完成辅助工作的容器。
kubernetes事件：events(事件)是kubernetes的一种资源对象，它记录了kubernetes集群中各个组件运行所遇到的各种事件，用于展示集群内发生的情况。events包括，容器镜像的拉取情况，当前pod被调度到哪个节点上运行，pod有无正确启动等。一旦kubernetes集群发生异常情况，可以通过events查找异常的时间点、涉及对象和原因等信息，比如为何pod没有启动、pod没有被调度。一次正常的应用部署，应该包括启动deployment调整replicaset数量，replicaset创建pod，将pod调度到合适的node，拉取指定镜像、创建容器、启动容器这些事件。
dapr：分布式应用运行时，指提供分布式应用所依赖的运行环境，而dapr，即DistributedApplication Runtime，是应用程序运行所需各种分布式能力的实现，可以让开发者聚焦业务，而不用考虑在分布式环境运行的问题。dapr是针对以RPC框架为基础的传统微服务架构而诞生的。之前分布式能力以库依赖的形式集成在业务代码的SDK中，使得应用程序的依赖逐渐臃肿且难于维护，而dapr可以将一些分布式能力从SDK中独立出来，封装下沉为一个和应用相伴运行的独立sidecar进程。开发人员只需通过yaml文件将提供不同功能的组件整合到dapr的构建块，然后在应用中编写和dapr使用HTTP/gRPC交互的代码来访问构建块，就可以从dapr中获得各种分布式功能，进而更专注于业务逻辑的实现，同时sidecar进程中的服务可以独立升级而不影响业务代码。dapr可以代码被调用的构建块能力包括：服务调用(使应用程序能够通过HTTP或gRPC消息形式相互通信)、状态管理(应用程序想要保留在单个会话之外的任何内容)、发布订阅(发布/订阅是松散耦合的消息传递模式，发布方将消息推送到订阅方订阅的主题)等。
dapr sidecar事件：sidecar容器，即和应用容器部署在同一个kubernetes pod中的，做辅助操作的容器。通过托管在kubernetes环境中的dapr部署应用时，dapr控制面会给应用所在的pod注入dapr sidecar容器并产生相应的事件，提供sidecar操作的可观测性。daprsidecar事件包括由dapr系统服务产生的信息、警告、错误和调试消息，能帮助用户识别问题。
端到端测试：e2e test，即end-to-end test，端到端测试，旨在通过复制应用程序部署中的用户行为来验证功能的正确性，确保系统的每个部分都能够正常地协同工作。这里使用的是dapr官方提供的e2e test，一次完整的成功测试包括有：进行设置，安装测试应用，添加并安装部署应用，验证应用的dapr sidecar是否启动，创建服务，创建pod端口转发器，全部组件安装完成即可运行测试，等待服务准备(即分配ip)，测试完成后自动拆卸将组件删除。
首先需要说明的是，事件可以反映软件系统的运行状态，在应用部署时，测试流程、kubernetes集群、dapr sidecar容器都会产生一些记录系统行为的事件，可以通过基于事件的分析和异常检测来发现系统异常行为，进而进行故障定位，保障系统可靠性。大多数故障是以异常事件的方式体现的，然而还有一部分故障属于性能问题，即部分功能被破坏。性能问题的事件都是正常事件，然而会因为一些故障组件减慢特定任务的执行时间，以事件之间时间间隔异常的形式来表现，这也是需要解决的问题。
因此，本发明要解决的技术问题是：在分布式运行时环境下，通过一些方式关联起系统各个组件的事件，对这些事件进行分析检测出异常，定位到故障是在哪一部分出现的，同时解决性能问题这种部分故障。此外，部署的应用包括会长期运行的service，和结束任务就会销毁、有完整生命周期的job两种类型，本发明主要针对的是job类型。
其中，事件是系统管理人员理解系统行为的重要数据，因为它们包含了发生在复杂系统组件上的信息，能够起到辅助故障定位的作用。对于传统的本地软件系统，系统管理人员会执行关键字搜索或规则匹配来定位可能与系统问题相关的异常日志。然而，随着现代软件系统生成事件数量的激增，已经有很多研究工作将收集到的系统事件进行自动化分析，挖掘事件特征进行异常检测，进而定位出故障位置。现有的事件异常检测方法主要可以分为三类：
1)基于传统机器学习的方法：
主要使用事件的量化信息来检测异常，如决策树，支持向量机SVM，logistic回归模型，他们都是采用了简单的模版计数统计特征作为输入进行训练。Xu等人则是使用主成分分析法PCA对事件模板计数向量进行建模，学习不同模板之间的模式。尽管这些方法可以通过数值结果检测某些异常，但它们无法考虑离散事件日志的顺序和时间结构。
2)基于工作流模型的方法：
假设有存在一个类似模型的有限状态机来表示事件转换状态的正常顺序。如果一条日志序列偏离了这个模型，就被视为异常。例如，通过学习重叠n-grams的适当分布提出了混合马尔可夫链模型，CloudSeer试图通过探索工作流推理问题来检测异常。然而，这些工作流模型的容量总是确定性的并且太小而无法捕获序列中复杂的长期依赖性。
3)基于深度学习的方法：
深度学习在表示、建模和学习能力上具有独特优势，可以使用预测、重建的方式处理和分析事件序列，从中提取特征来检测异常。
基于重建的方法尝试通过检查重建错误来学习然后检测异常。然而他们缺乏探索潜在空间中哪些部分代表正常而哪些部分不正常的手段，这可能会导致过拟合。
基于预测的方法则是通过基于滑动窗口预测下一个事件来检测异常，其中的代表性工作是DeepLog，它认为系统事件遵循着严格的逻辑和语言结构，相邻事件的关联性一般比较高，适合建模为自然语言序列来处理。DeepLog把一个事件序列看作一个文本，将事件序列中的每条事件对应的模板当作一个关键词来进行解析，然后使用长短期记忆网络LSTM对系统正常运行状态的事件序列建模。当有新的事件序列时，设置一个滑动窗口，将序列中该窗口内的历史事件作为LSTM的输入，输出为预测的下一时刻事件的概率分布，如果真实事件在模型预测的概率最大的前K个事件中，则认为它是正常事件，否则为异常。
相比DeepLog中直接使用事件模板索引作为模型输入，LogAnomaly为了保留事件模板之间的语义关系，根据词嵌入的原理设计了一种模板表示方法Template2Vec，用来准确地从事件模板中提取语义和语法信息。此外它还能同时考虑了事件序列信息和序列中的模板数量信息，以此为特征输入LSTM模型中检测是否存在故障。LogRobust是一种具有较好鲁棒性的异常检测模型，它考虑了事件数据的不稳定性，即随着时间推移会出现以前没有的事件或事件序列。LogRobust首先将每个事件转换成一个语义向量，即使事件发生了变化仍然可以表示为与原始事件相似的向量。然后，它使用基于注意力机制的双向LSTM神经网络进行异常检测，使得该模型在具有LSTM捕获事件序列中的上下文信息能力的基础上，还可以学习不同事件的重要性，帮助模型关注在事件序列中权重更大的事件。
由于软件系统中产生的事件大多是没有标签的，目前主流的研究思路是使用无监督的方法。当系统以健康状态运行时，生成的日志通常会呈现稳定和正常的模式，异常则表现为明显偏离此类模式的异常值。基于这一观察，无监督方法从大量历史事件中构建代表系统正常行为的参考模型，通过比较当前事件与正常事件的特征，判定事件有无违背相应特征来进行异常检测。
基于上述各类异常检测技术方案的分析，容易确定：
1、job类型的应用：
现有技术大多是针对会长期运行的service类型的应用进行的，少有用于完成任务即结束、具有明确完整生命周期的job类型的方法。job类型的应用有着清晰的开始和结束点，每一次平台都会做这样一遍流程，启动->提供服务->销毁，有一个完整的生命周期，不会长期运行。
2、分布式运行时系统事件的关联：
目前已有许多基于事件进行故障定位的工作，然而，这些工作只是在单个系统组件中进行的，缺少在分布式运行时环境下的应用。它们并没有考虑到故障的传播性，没有利用到分布式运行时系统中不同组件产生事件之间的关联性。对不同组件的事件分开来单独进行故障定位的方式，找到的不一定是故障根因。对分布式系统的执行请求会在系统内经过多个组件，这些组件输出相应的事件信息，对这些事件关联可以描绘出系统的请求处理轨迹，从而定位出故障所在的位置。
另一方面，分布式运行时系统中不同组件产生的事件是需要经过处理，才能将和一次应用部署相关的关联起来的。比如kubernetes集群中不同组件deployment、replicaset、pod产生的事件需要通过deployment name关联。
3、性能问题：
在实际的生产环境中，部分故障会表现为性能问题，即系统的部分功能被破坏，但并非全部。和一般的异常事件序列不同，那些有性能问题的事件序列与正常保持相同的顺序，但是会根据故障组件减慢特定事件的执行时间，比正常需要的时间要长得多。事实上，部分故障是许多现实世界中断背后的原因，因此是开发人员不能忽视的问题。在分布式运行时系统环境中，这样的性能问题包括：由于网络拥塞导致kubernetes pod拉取镜像耗时过长、因为相关进程故障导致kubernetes调度pod时间变长等。如果方法只是单纯考虑事件的语义信息，而不结合事件之间的时间间隔信息，将无法检测出性能问题。现有的方法采用静态分析来查找性能错误或使用侵入式方法来检测性能问题，但是它们各自有着难以在运行时检测、降低系统性能的问题。因此本发明通过选择挖掘事件的时间间隔变化来检测性能问题。
针对上述技术原理分析，本发明的目的是在分布式运行时环境中，针对job类型的应用，将系统中不同组件的事件关联起来，进行异常检测处理分析，同时通过挖掘事件之间的时间间隔变化检测性能问题，从而定位出故障所在的位置。一方面，如图1所示，本发明的实施例提供了一种基于事件分析的故障定位方法，包括：
S100、在目标系统模拟故障注入；
其中，目标系统基于分布式运行时搭建得到；
需要说明的是，一些实施例中，步骤S100可以包括：利用实验注入工具在目标系统进行故障自动注入；或，响应于配置指令，在目标系统进行故障手动注入。
一些具体实施例中，在故障注入前，首先进行实验环境(目标系统)搭建，具体包括：
在使用虚拟机搭建的kubernetes集群中部署dapr应用程序。为了让dapr在kubernetes集群环境上托管，首先需要安装dapr cli脚手架工具，然后借用它把dapr安装到kubernetes集群上。执行命令“dapr init-k”即可在当前上下文中初始化kubernetes集群上的dapr。dapr会在Kubernetes集群部署dapr-operator、dapr-sidecar-injector、dapr-placement和dapr-sentry这几个控制平面服务。搭建好环境后，通过执行一些dapr的端到端测试，在kubernetes环境中部署应用，然后将这些测试的执行过程记录、建模，得到事件模式。
进而，在搭建好的环境进行故障注入，为了获取关于分布式运行时系统故障的数据，需要采用故障注入的方式，在受控实验中故意将故障引入系统。通过这些实验产生故障的事件数据，再在这些数据的基础上做基于事件分析的故障定位的实验。针对想要测试的故障类型，采用相应的故障注入手段，包括使用工具自动注入故障和手动注入：
1)Chaosblade(实验注入工具)：
ChaosBlade是阿里巴巴开源的一款遵循混沌工程原理和混沌实验模型的实验注入工具，帮助企业提升分布式系统的容错能力。它可以在云原生平台上进行网络、进程、pod、container等的故障实验场景。注入的故障包括：由于网络故障导致pod生命探测失效；由于网络丢包而拉取镜像时间变长甚至失败；使pod容器定义改变发生故障；pod在运行过程中被杀死；pod的容器被移除；暂停和kubernetes相关的进程kube-scheduler、kubelet使相应的事件无法进行。此外还有使得dapr控制面组件发生故障而导致一些dapr操作无法执行。
2)手动注入：
有一些故障类型需要手动进行相应的配置，包括：设置应用pod需要调度到特定标签的node，而kubernetes集群中没有合适的节点而调度失败；设置镜像拉取策略为never且本地没有要求的镜像，导致拉取镜像失败；和其他dapr app发生了端口占用冲突；组件配置不正确；没有ip地址可以分配给loadbalancer service。
为了验证模型检测性能问题的有效性，即对时间违规变化的敏感性，注入一些额外的延迟来产生性能问题，比如使网络丢包导致kubernetes拉取镜像时间变长、暂停和kubernetes相关进程使相应的事件延迟进行等。
S200、获取故障注入产生的事件数据，对事件数据进行持久化保存；
需要说明的是，事件数据包括端到端测试事件、kubernetes事件和dapr事件，一些实施例中，步骤S200可以包括以下至少之一：将端到端测试事件保存到本地日志文件；将kubernetes事件执行过程中，对api对象的操作记录在events中，并存储到etcd里；采用node logging agent的方式收集dapr事件，通过在kubernetes集群的每个节点上以daemonset的方式部署一个logging agent服务，进而基于logging agent服务进入各节点上所有容器的事件目录，收集dapr事件并传递到后端存储进行保存。
一些具体实施例中，为了利用系统各个部分的事件数据来对系统进行异常检测和故障定位，不能只是把事件打印到控制台，需要有能收集并持久化保存这些事件的方法进行事件收集。下面说明系统各个部分事件的收集和存储方式：
1)端到端测试：
端到端测试流程事件在进行测试时会自动打印保存到本地日志文件中。
2)kubernetes：
在kubernetes执行的过程中，对api对象的所有重要操作，都会被记录在events(事件)中，存储到etcd里。考虑到如果不加管理地将大量的事件都存储起来，会对etcd存储系统带来较大的性能与容量压力，因此kubernetes只会默认保存最近1小时的events，用户无法看到历史中过去时间很久的events。所以如果要利用events来做异常检测，就需要先收集和长期保存这些事件。
指令"kubectl describe InvolvedObject"可以根据InvolvedObject进行搜索，匹配和它相关的所有事件，因此考虑通过将它返回的文本结果转发保存到本地文件，解决events保留时间不够长的问题。对不同的资源对象进行describe的时候，能看到的events内容都是与它所描述的资源对象有直接关联的。
events当中除了有事件信息，还有每条事件发生距离当前的时间，可以通过相减这些相对时间得到相邻事件之间的时间间隔。
3)dapr(同Dapr)：
dapr sidecar以容器形式部署在kubernetes集群中，只需要通过读取宿主机目录/var/log/containers/*.log下的容器事件，就能收集dapr sidecar事件。采用nodelogging agent的方式来收集事件，通过在kubernetes集群的每个节点上以daemonset的方式部署一个logging agent服务，agent有权限进入该节点上所有容器的事件目录，收集事件并传递到后端存储里保存起来。logging agent采用fluentd事件收集系统，它能够收集事件并将其转换成json格式。而logging backend则使用elasticsearch搜索引擎，它能够将事件信息进行分割并建立索引，之后使用elasticsearch第三方客户端通过代码查询、调取和处理这些事件。最后通过分析与可视化平台kibana将事件展现出来，整体架构如图2所示。
S300、对事件数据进行分组排序，得到若干不同的事件序列；
需要说明的是，一些实施例中，步骤S300可以包括：通过事件标识符对事件数据中的各个事件进行分组，获得若干事件组别；根据各事件组别中事件的时间戳顺序进行各事件组别的事件排序，得到若干不同的事件序列。
一些具体实施例中，在收集得到事件后，进行事件关联，具体为：通过事件标识符将事件划分为不同的组，然后按照事件时间戳顺序进行排序，得到不同的事件序列。在每个事件序列中，所有事件共享一个唯一且通用的关键标识符，表明它们来自同一个测试执行。执行一次测试部署应用所产生的所有日志，都是和这个应用相关的。
在分布式运行时场景中，这样的标识符是应用部署在kubernetes集群中的pod的name。在端到端测试流程事件中，可以看到部署应用过程中的所有kubernetes pod name；此外，由于kubernetes pod name中包括了deployment和replicaset部分的name，因此也可以将kubernetes集群中相关组件的事件关联；最后，在dapr sidecar容器的事件中包含有字段instance，即daprd sidecar容器所在pod的名称。综上，通过kubernetes的pod name这一关键标识符将系统不同部分的事件关联了起来。以这种方式生成的事件序列，通常具有不同的长度，代表着不同的应用部署情况。
S400、对事件序列中的每条事件进行解析，生成事件模板；
需要说明的是，一些实施例中，步骤S400可以包括：基于固定深度树的日志解析方法，对事件序列中的每条事件进行预处理，得到token序列，进而删除冗余信息，抽取得到事件模板。
一些具体实施例中，在基于事件做故障定位之前，首先需要进行事件解析：通过对事件序列中的每条事件进行解析，生成事件模板。系统原始事件往往是非结构化的文本信息，在不同系统之间事件的格式和语义有很大差异。为了降低事件数据的复杂性，要有对事件进行处理和特征提取的方法，将事件解析成结构化格式，以便下游分析。事件解析尝试识别原始事件的常量/静态部分和变量/动态部分，常量部分称为事件模板，变量部分根据系统的具体运行而不同，因此可以省略。
在本发明中，使用的生成事件模板的解析方法是Drain，一种基于固定深度树的日志解析方法。当一个新的原始事件消息到达时，Drain将根据领域知识通过简单的正则表达式对其进行预处理。然后通过事件消息长度进行搜索，这是基于具有相同的日志消息长度可能具有相同日志事件的日志消息的假设。接着搜索事件组，通过遵循编码在树内部节点中的设计规则来指导搜索过程，找到存储事件组的树叶子节点。如果找到合适的事件组，事件消息将与存储在该事件组的事件匹配。否则，将创建一个新的事件组。
利用这样的事件解析方法，对事件序列中的事件进行预处理，变成由token组成的序列，并且删除无意义的符号、泛化数字、IP等冗余信息，最终抽取得到事件模板。下表1是事件解析的一个示例。
表1
S500、通过无监督方法对事件模板进行异常检测，得到变化故障；
需要说明的是，变化故障包括导致事件序列顺序变化的序列事件异常和导致事件时间间隔变化的性能问题；一些实施例中，步骤S500可以包括：对事件模板进行向量转换，得到事件嵌入向量特征，并通过加权聚合得到事件语义向量，进而采用LSTM模型进行基于预测的异常检测，得到序列事件异常；根据事件模板中各事件的时间差，得到时间差分序列，进而通过DeepLog方法检测时间差分序列中的异常时间间隔变化，得到性能问题。
一些具体实施例中，由于在现实场景中通常无法获得标签，标记大量数据非常耗时，所以在本文中，在对事件进行解析得到事件模板后，使用无监督方法进行异常检测。将导致事件序列顺序变化的故障称为序列事件异常，将事件时间间隔变化称为性能问题。
1)序列事件异常：
事件文本序列从异常的序列顺序中观察到序列事件异常，包括缺失、冗余、替换事件等情况。对于事件文本序列，使用类似LogAnomaly的方法，把事件模板转换成语义向量来作为异常检测的输入，这样可以提高异常检测的准确性。在第一个使用LSTM进行事件异常检测的工作DeepLog中，事件模式是从事件的顺序关系中学习的，每个事件信息都由其事件的索引表示，即事件模板id形成的one-hot向量。为了学习事件的语义来作出更明智的决策，使用更复杂的事件嵌入向量特征。具体来说，先随机初始化每个单词的嵌入向量，将事件中的词嵌入为向量。一些工作采用现成的预训练词向量，但是在遵循它们配置时没有观察到太大的改进，一个重要的原因是分布式运行时系统中专有名词较多，事件中的很多词都没有被预训练的词汇覆盖。然后使用tf-idf方法，tf-idf(term frequency–inversedocumentfrequency)是一种用于信息检索与数据挖掘的常用加权技术。TF是词频(TermFrequency)，IDF是逆文本频率指数(Inverse Document Frequency)。tf表示单词在当前事件中的出现频率word代表单词在当前事件的数量，total代表事件所有单词的数量，word越多证明越重要；idf是单词在多个事件中出现的频率L代表事件序列中的事件数量，Lword代表出现单词word的事件数量，越多则表明它对于事件的代表性越不够，权重应该降低。根据每个单词的tf-idf权重来聚合词嵌入向量/>其中wi是tf-idf权重，vi是词向量，N是事件的单词数量，i代表第几个单词，最终得到事件的语义向量。
进而采用LSTM模型进行基于预测的异常检测，使用系统正常运行状态下产生的事件序列来训练LSTM模型。这种基于预测的模型根据先前的观察结果预测下一个出现的事件。具体来说，对于在时间步t出现的事件et，首先形成一个输入窗口W，其中包含et之前的m个日志事件，即W＝[et-m,...,et-2,et-1]。这是通过将事件序列分成更小的子序列来完成的。划分过程由窗口大小和步长两个参数控制。训练模型学习下一个事件的条件概率分布P(et＝ki\W)，其中ki∈K(i＝1,...,n)，K是事件模板的总数，i是第几个事件模板。在检测阶段，经过训练的模型对新的输入窗口进行预测，并将其与实际日志事件进行比较。如果实际事件不是模型预测的topK事件，则发出异常警报。
2)性能问题：
事件时间序列则是从异常的时间间隔变化中察觉到异常。有性能问题的事件文本序列保持和正常序列相同的顺序，但是会因为特定任务的故障组件减慢其执行时间。因此，引入时间信息作为特征来补充异常检测方法。
计算两个事件e1和e2的时间差Δt，然后得到时间差分序列ΔT＝{Δt1,Δt2,...,Δti,...}，此外使用-1来填充时间序列的开头。得到这样的一些时间序列后，观察到时间序列和以事件模板索引组成的事件序列类似，于是选用异常检测方法DeepLog来检测时间序列中的异常时间间隔变化。
还需要说明的是，对于性能问题，也可以不直接把事件之间时间间隔原始序列作为输入，而是先将时间序列符号化，例如SAX算法(Symbolic Aggregate Approximation)，使用字符来表示一定范围内的时间大小，解决时间变化比较大的问题，减少需要的训练数据数量。然而，使用符号化方法将时间粗粒度化后，由于进行了标准化，在做异常诊断时我们就无法把故障具体定位到某个准确的时间点，只知道时间序列是异常的。
其中，其它一些实施例，还可以使用其它的异常检测方法，比如基于重建的方法，使用自动编码器来学习正常日志事件序列的表示。经过训练的模型能够正确编码正常的日志模式。在处理异常实例时，重建损失变得相对较大。这种方法相比基于预测的方法在相同正常数据上训练时表现较差，然而它更能抵抗包含异常的训练数据，对具有噪音的数据表现出鲁棒性，不去学习异常的事件模式。使用哪种方法取决于训练数据中异常比例的多少。又或者使用其它更加先进的异常检测方法，然而面对分布式运行时场景，由于正常模式比较单一，上述的异常检测方法准确率已经足够高，而且部署这一方法较为简便。
一些具体实施例中，还针对上述方案进行实验评估，具体包括：
用于在分布式运行时系统各个部分收集得到的事件和时间序列数量如表2。为了让无监督模型从无异常的数据中学习正常模式，训练数据中没有异常序列，只有正常序列；而验证和测试数据中则包含了一部分的异常序列，异常占全部序列的比例如图括号内所示。其中训练、验证、测试集的数据比例为3:1:6。如果序列中的任何一个窗口被预测为异常，则序列被视为异常。
表2
对于实验评估指标，由于事件异常检测是一个二元分类问题(正常/异常)，可以使用precision、recall和f1 score来评估。具体来说，precision衡量异常事件序列被成功识别在所有预测为异常的事件序列中的占比：recall计算在所有实际异常中成功识别的异常的占比：/>f1score是precision和recall的调和平均值： TP是模型预测正确的异常序列数，FP是被模型错误预测的正常序列数，FN是模型遗漏的异常序列数。表3是在每个数据集上的评估数据结果，可以看到precision、recall、f1 score三项数据都是比较高的，这是因为事件序列、时间序列的正常模式比较单一，比较容易将异常区分出来。这意味着我们可以通过这一异常检测方法来进行较为准确的故障定位。
表3
数据集 准确率 召回率 F1分数
端到端测试事件 0.9680 0.9846 0.9763
kubernetes事件 0.9877 1.0000 0.9938
dapr事件 0.9876 0.9143 0.9495
事件时间 1.0000 1.0000 1.0000
S600、基于变化故障进行故障定位，确定异常事件序列，进而定位目标系统的异常部分。
需要说明的是，一些实施例中，步骤S600可以包括：基于变化故障进行故障定位，确定异常事件序列；基于异常事件序列还原发生异常的滑动窗口，并对LSTM模型预测的下一条事件和真实事件进行比较，基于比较结果定位出发生序列事件异常和性能问题的异常部分。
一些具体实施例中，采用的故障定位方法，是通过异常检测方法检测到异常事件序列后，还原发生异常的具体滑动窗口、模型预测的下一条事件和真实的事件来进行，定位出发生序列顺序异常、性能问题的异常部分。输入一次测试产生的所有类型的事件序列和时间，判断哪一部分异常。例如输入事件窗口为["Started container*","Pullingimage*","Successfully pulled image*","Created container*","Startedcontainer"]，正常执行时下一个事件为结束事件，然而真实事件为"Readiness probefailed:*"，发生了序列顺序异常。输入时间窗口为["Scale up replica set*to*(-1)","Created pod:*(0)"]，正常只需要数秒就可以调度pod到某个node，然而因为暂停了kube-scheduler进程，使得做调度的时间变长，产生了时间间隔变化"Successfully assigned*to*(17)"，发生了性能问题。
为完整阐述本发明实施例的技术原理，下面结合部分具体实施例对上述整体流程步骤作进一步说明，应当理解，下述为本发明的解释，不能看作对本发明的限制。
本发明通过基于事件分析实现分布式运行时系统的故障定位。通过对分布式运行时系统中各个组件的事件进行关联和分析，可以定位出故障所在的位置，发现产生问题的原因。整体流程如图3所示：
首先搭建kubernetes环境部署Dapr运行端到端测试，然后通过注入故障让系统产生相应的异常数据，进而依次通过事件收集、事件关联、事件解析和异常检测，并最终实现故障定位。具体通过对正常/异常事件(包括端到端测试事件、kubernetes事件和Dapr事件，并记录相关事件时间)进行收集、存储、分析。最后，还包括对在搭建的kubernetes集群环境中部署dapr应用产生的事件数据集进行实验，评估这一技术方案的可行性和有效性的步骤。
其中，实验中涵盖了几乎所有dapr功能的测试，包括/actors,/bindings,/health,/invoke,/metadata,/publish,/state,/secrets等dapr构建块的使用，api操作包含post,put,get,delete。在端到端测试完成后，会自动把相关kubernetes集群组件删除，因此属于是job类型的应用部署。
本发明通过如下技术特征以解决现有技术的相关问题：
1、job类型的应用。现有技术少有用于完成任务即结束、具有明确完整生命周期的job类型的方法。job类型的应用有着清晰的开始和结束点，有一个完整的生命周期，不会长期运行。本发明针对这一类型的应用进行了异常检测和故障定位，对应用的起始和结束事件做了特别标识，便于模型学习训练。
2、分布式运行时系统事件的关联。本发明在分布式运行时系统收集到的事件，包括端到端测试中请求loadbalancer服务，创建kubernetes pod，dapr sidecar调用api使用组件功能等，实际上相当于是在平台上留下的痕迹。我们在平台侧，把这些和应用部署和运行相关的事件痕迹做了关联，这样就形成了应用的整个生命周期。我们不需要侵入应用，也不需要它的业务指标，就可以对应用做异常检测和故障定位，查找在应用生命周期的哪个部分发生了问题。
为了利用分布式运行时系统中不同组件产生事件之间的关联性，我们从系统不同组件的事件中筛选出能将它们拼接起来的关键属性，然后把平台侧的事件串联得到事件序列，再根据时间戳、序列等信息来用模型做相应的故障定位分析。在每个序列中，所有事件共享一个唯一且通用的标识符，表明他们来自同一个测试执行。
3、性能问题的处理。在实际的生产环境中，部分故障会表现为性能问题，即系统的部分功能被破坏，但并非全部。和一般的异常事件序列不同，那些有性能问题的事件序列与正常保持相同的顺序，但是会根据故障组件减慢特定事件的执行时间，比正常需要的时间要长得多。对于性能问题，可以通过挖掘事件之间的时间间隔变化来检测，使用一种嵌入方法来编码这些时间信息，进行异常检测，然后和事件序列的语义信息一起用作故障定位的参考。
综上，本发明通过对分布式运行时系统中各个组件的事件进行关联和分析，最终定位出故障所在的位置，发现产生问题的原因。除了收集系统正常执行数据外，还通过注入故障让系统产生相应的异常数据，实现了对正常/异常事件收集、存储、关联、分析的方法。相较于现有技术，本发明至少包括如下有益效果：
a.本发明展示了分布式运行时系统中的事件具体应该怎么收集和存储。
b.本发明针对不会长期运行，有完整生命周期的job类型应用故障定位。
c.本发明在平台侧将分布式运行时系统中和应用部署和运行相关的事件通过唯一标识符关联，形成了应用生命周期内产生所有事件的序列。我们不需要侵入应用，不需要知道应用内部产生的事件，也无需它的业务指标，只要分析时间戳、事件序列等信息就可以对应用做异常检测。我们实现了故障定位，可以查找在应用生命周期内，哪个部分的系统组件发生了什么问题。
d.本发明考虑到了对系统的部分功能被破坏的故障，也即性能问题的处理。我们通过挖掘事件之间的时间间隔变化来检测性能问题，使用一种嵌入方法来编码这些时间信息，进行异常检测，然后和事件序列的语义信息一起用作故障定位的参考。
另一方面，本发明的实施例提供了一种基于事件分析的故障定位装置，包括：第一模块，用于在目标系统模拟故障注入；其中，目标系统基于分布式运行时搭建得到；第二模块，用于获取故障注入产生的事件数据，对事件数据进行持久化保存；第三模块，用于对事件数据进行分组排序，得到若干不同的事件序列；第四模块，用于对事件序列中的每条事件进行解析，生成事件模板；第五模块，用于通过无监督方法对事件模板进行异常检测，得到变化故障；变化故障包括导致事件序列顺序变化的序列事件异常和导致事件时间间隔变化的性能问题；第六模块，用于基于变化故障进行故障定位，确定异常事件序列，进而定位目标系统的异常部分。
本发明方法实施例的内容均适用于本装置实施例，本装置实施例所具体实现的功能与上述方法实施例相同，并且达到的有益效果与上述方法达到的有益效果也相同。
如图4所示，本发明实施例的另一方面还提供了一种电子设备400，包括处理器410以及存储器420；
存储器420用于存储程序；
处理器410执行程序实现如前面的方法。
本发明方法实施例的内容均适用于本电子设备实施例，本电子设备实施例所具体实现的功能与上述方法实施例相同，并且达到的有益效果与上述方法达到的有益效果也相同。
本发明实施例的另一方面还提供了一种计算机可读存储介质，存储介质存储有程序，程序被处理器执行实现如前面的方法。
本发明方法实施例的内容均适用于本计算机可读存储介质实施例，本计算机可读存储介质实施例所具体实现的功能与上述方法实施例相同，并且达到的有益效果与上述方法达到的有益效果也相同。
本发明实施例还公开了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器可以从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行前面的方法。
在一些可选择的实施例中，在方框图中提到的功能/操作可以不按照操作示图提到的顺序发生。例如，取决于所涉及的功能/操作，连续示出的两个方框实际上可以被大体上同时地执行或方框有时能以相反顺序被执行。此外，在本发明的流程图中所呈现和描述的实施例以示例的方式被提供，目的在于提供对技术更全面的理解。所公开的方法不限于本文所呈现的操作和逻辑流程。可选择的实施例是可预期的，其中各种操作的顺序被改变以及其中被描述为较大操作的一部分的子操作被独立地执行。
此外，虽然在功能性模块的背景下描述了本发明，但应当理解的是，除非另有相反说明，的功能和/或特征中的一个或多个可以被集成在单个物理装置和/或软件模块中，或者一个或多个功能和/或特征可以在单独的物理装置或软件模块中被实现。还可以理解的是，有关每个模块的实际实现的详细讨论对于理解本发明是不必要的。更确切地说，考虑到在本文中公开的装置中各种功能模块的属性、功能和内部关系的情况下，在工程师的常规技术内将会了解该模块的实际实现。因此，本领域技术人员运用普通技术就能够在无需过度试验的情况下实现在权利要求书中所阐明的本发明。还可以理解的是，所公开的特定概念仅仅是说明性的，并不意在限制本发明的范围，本发明的范围由所附权利要求书及其等同方案的全部范围来决定。
功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，RandomAccess Memory)、磁碟或者光盘等各种可以存储程序代码的介质。
在流程图中表示或在此以其他方式描述的逻辑和/或步骤，例如，可以被认为是用于实现逻辑功能的可执行指令的定序列表，可以具体实现在任何计算机可读介质中，以供指令执行装置、装置或设备(如基于计算机的装置、包括处理器的装置或其他可以从指令执行装置、装置或设备取指令并执行指令的装置)使用，或结合这些指令执行装置、装置或设备而使用。就本说明书而言，“计算机可读介质”可以是任何可以包含、存储、通信、传播或传输程序以供指令执行装置、装置或设备或结合这些指令执行装置、装置或设备而使用的装置。
计算机可读介质的更具体的示例(非穷尽性列表)包括以下：具有一个或多个布线的电连接部(电子装置)，便携式计算机盘盒(磁装置)，随机存取存储器(RAM)，只读存储器(ROM)，可擦除可编辑只读存储器(EPROM或闪速存储器)，光纤装置，以及便携式光盘只读存储器(CDROM)。另外，计算机可读介质甚至可以是可在其上打印程序的纸或其他合适的介质，因为可以例如通过对纸或其他介质进行光学扫描，接着进行编辑、解译或必要时以其他合适方式进行处理来以电子方式获得程序，然后将其存储在计算机存储器中。
应当理解，本发明的各部分可以用硬件、软件、固件或它们的组合来实现。在上述实施方式中，多个步骤或方法可以用存储在存储器中且由合适的指令执行装置执行的软件或固件来实现。例如，如果用硬件来实现，和在另一实施方式中一样，可用本领域公知的下列技术中的任一项或他们的组合来实现：具有用于对数据信号实现逻辑功能的逻辑门电路的离散逻辑电路，具有合适的组合逻辑门电路的专用集成电路，可编程门阵列(PGA)，现场可编程门阵列(FPGA)等。
在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本发明的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不一定指的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任何的一个或多个实施例或示例中以合适的方式结合。
尽管已经示出和描述了本发明的实施例，本领域的普通技术人员可以理解：在不脱离本发明的原理和宗旨的情况下可以对这些实施例进行多种变化、修改、替换和变型，本发明的范围由权利要求及其等同物限定。
以上是对本发明的较佳实施进行了具体说明，但本发明并不限于实施例，熟悉本领域的技术人员在不违背本发明精神的前提下还可做出种种的等同变形或替换，这些等同的变形或替换均包含在本发明权利要求所限定的范围内。

Claims (10)

1.一种基于事件分析的故障定位方法，其特征在于，包括：
在目标系统模拟故障注入；其中，所述目标系统基于分布式运行时搭建得到；
获取所述故障注入产生的事件数据，对所述事件数据进行持久化保存；
对所述事件数据进行分组排序，得到若干不同的事件序列；
对所述事件序列中的每条事件进行解析，生成事件模板；
通过无监督方法对所述事件模板进行异常检测，得到变化故障；所述变化故障包括导致事件序列顺序变化的序列事件异常和导致事件时间间隔变化的性能问题；
基于所述变化故障进行故障定位，确定异常事件序列，进而定位所述目标系统的异常部分。
2.根据权利要求1所述的一种基于事件分析的故障定位方法，其特征在于，所述在目标系统环境模拟故障注入，包括：
利用实验注入工具在所述目标系统进行故障自动注入；
或，响应于配置指令，在所述目标系统进行故障手动注入。
3.根据权利要求1所述的一种基于事件分析的故障定位方法，其特征在于，所述事件数据包括端到端测试事件、kubernetes事件和dapr事件，所述对所述事件数据进行持久化保存，包括以下至少之一：
将所述端到端测试事件保存到本地日志文件；
将所述kubernetes事件执行过程中，对api对象的操作记录在events中，并存储到etcd里；
采用node logging agent的方式收集所述dapr事件，通过在kubernetes集群的每个节点上以daemonset的方式部署一个logging agent服务，进而基于所述logging agent服务进入各所述节点上所有容器的事件目录，收集所述dapr事件并传递到后端存储进行保存。
4.根据权利要求1所述的一种基于事件分析的故障定位方法，其特征在于，所述对所述事件数据进行分组排序，得到若干不同的事件序列，包括：
通过事件标识符对所述事件数据中的各个事件进行分组，获得若干事件组别；
根据各所述事件组别中所述事件的时间戳顺序进行各所述事件组别的事件排序，得到若干不同的事件序列。
5.根据权利要求1所述的一种基于事件分析的故障定位方法，其特征在于，所述对所述事件序列中的每条事件进行解析，生成事件模板，包括：
基于固定深度树的日志解析方法，对所述事件序列中的每条事件进行预处理，得到token序列，进而删除冗余信息，抽取得到事件模板。
6.根据权利要求1所述的一种基于事件分析的故障定位方法，其特征在于，所述通过无监督方法对所述事件模板进行异常检测，得到变化故障，包括：
对所述事件模板进行向量转换，得到事件嵌入向量特征，并通过加权聚合得到事件语义向量，进而采用LSTM模型进行基于预测的异常检测，得到所述序列事件异常；
根据所述事件模板中各事件的时间差，得到时间差分序列，进而通过DeepLog方法检测所述时间差分序列中的异常时间间隔变化，得到性能问题。
7.根据权利要求6所述的一种基于事件分析的故障定位方法，其特征在于，所述基于所述变化故障进行故障定位，确定异常事件序列，进而定位所述目标系统的异常部分，包括：
基于所述变化故障进行故障定位，确定异常事件序列；
基于所述异常事件序列还原发生异常的滑动窗口，并对所述LSTM模型预测的下一条事件和真实事件进行比较，基于比较结果定位出发生所述序列事件异常和所述性能问题的异常部分。
8.一种基于事件分析的故障定位装置，其特征在于，包括：
第一模块，用于在目标系统模拟故障注入；其中，所述目标系统基于分布式运行时搭建得到；
第二模块，用于获取所述故障注入产生的事件数据，对所述事件数据进行持久化保存；
第三模块，用于对所述事件数据进行分组排序，得到若干不同的事件序列；
第四模块，用于对所述事件序列中的每条事件进行解析，生成事件模板；
第五模块，用于通过无监督方法对所述事件模板进行异常检测，得到变化故障；所述变化故障包括导致事件序列顺序变化的序列事件异常和导致事件时间间隔变化的性能问题；
第六模块，用于基于所述变化故障进行故障定位，确定异常事件序列，进而定位所述目标系统的异常部分。
9.一种电子设备，其特征在于，包括处理器以及存储器；
所述存储器用于存储程序；
所述处理器执行所述程序实现如权利要求1至7中任一项所述的方法。
10.一种计算机可读存储介质，其特征在于，所述存储介质存储有程序，所述程序被处理器执行实现如权利要求1至7中任一项所述的方法。
CN202310747971.1A 2023-06-21 2023-06-21 基于事件分析的故障定位方法、装置、电子设备及介质 Pending CN116756021A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202310747971.1A CN116756021A (zh) 2023-06-21 2023-06-21 基于事件分析的故障定位方法、装置、电子设备及介质

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202310747971.1A CN116756021A (zh) 2023-06-21 2023-06-21 基于事件分析的故障定位方法、装置、电子设备及介质

Publications (1)

Publication Number Publication Date
CN116756021A true CN116756021A (zh) 2023-09-15

Family

ID=87947574

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202310747971.1A Pending CN116756021A (zh) 2023-06-21 2023-06-21 基于事件分析的故障定位方法、装置、电子设备及介质

Country Status (1)

Country Link
CN (1) CN116756021A (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN117520999A (zh) * 2024-01-08 2024-02-06 浙江德塔森特数据技术有限公司 一种边缘数据中心设备的智能运维方法和系统

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN117520999A (zh) * 2024-01-08 2024-02-06 浙江德塔森特数据技术有限公司 一种边缘数据中心设备的智能运维方法和系统
CN117520999B (zh) * 2024-01-08 2024-04-05 浙江德塔森特数据技术有限公司 一种边缘数据中心设备的智能运维方法和系统

Similar Documents

Publication Publication Date Title
US11226892B2 (en) Analyzing software test failures using natural language processing and machine learning
Zhang et al. Robust log-based anomaly detection on unstable log data
US11568134B2 (en) Systems and methods for diagnosing problems from error logs using natural language processing
Lo et al. SMArTIC: Towards building an accurate, robust and scalable specification miner
CN105283848B (zh) 用分布式目标来进行应用跟踪
CN105283851B (zh) 用于选择跟踪目标的成本分析
CN105283866B (zh) 包括使用相似频率的优化分析的应用跟踪方法和系统
US20170109657A1 (en) Machine Learning-Based Model for Identifying Executions of a Business Process
US20170109676A1 (en) Generation of Candidate Sequences Using Links Between Nonconsecutively Performed Steps of a Business Process
US20170109668A1 (en) Model for Linking Between Nonconsecutively Performed Steps in a Business Process
US20090063387A1 (en) Apparatus And Method For Problem Determination And Resolution
Qin et al. Studying aging-related bug prediction using cross-project models
US20170109667A1 (en) Automaton-Based Identification of Executions of a Business Process
Shihab An exploration of challenges limiting pragmatic software defect prediction
Bogatinovski et al. Self-supervised anomaly detection from distributed traces
US20170109639A1 (en) General Model for Linking Between Nonconsecutively Performed Steps in Business Processes
US10509719B2 (en) Automatic regression identification
CN107003931B (zh) 将测试验证从测试执行分离
US11449488B2 (en) System and method for processing logs
US10528456B2 (en) Determining idle testing periods
US20170109638A1 (en) Ensemble-Based Identification of Executions of a Business Process
Caglayan et al. Usage of multiple prediction models based on defect categories
CN116756021A (zh) 基于事件分析的故障定位方法、装置、电子设备及介质
De Sanctis et al. A model-driven approach to catch performance antipatterns in ADL specifications
US20170109640A1 (en) Generation of Candidate Sequences Using Crowd-Based Seeds of Commonly-Performed Steps of a Business Process

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination