CN114327964A - 业务系统的故障原因处理方法、装置、设备及存储介质 - Google Patents
业务系统的故障原因处理方法、装置、设备及存储介质 Download PDFInfo
- Publication number
- CN114327964A CN114327964A CN202011080651.8A CN202011080651A CN114327964A CN 114327964 A CN114327964 A CN 114327964A CN 202011080651 A CN202011080651 A CN 202011080651A CN 114327964 A CN114327964 A CN 114327964A
- Authority
- CN
- China
- Prior art keywords
- fault
- fault alarm
- determining
- sequence mode
- index
- 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
Links
Images
Landscapes
- Debugging And Monitoring (AREA)
Abstract
本申请提供了一种业务系统的故障原因处理方法、装置、电子设备及计算机可读存储介质，涉及人工智能和云技术中的智能运维；方法包括：获取业务系统的故障告警日志和运行指标的升降变化信息；根据运行指标的升降变化信息，确定运行指标频繁序列模式；将相似度高于相似度阈值的任意两个故障告警日志标记为相同的故障告警类型，根据标记得到的故障告警类型，确定故障告警类型频繁序列模式；根据运行指标频繁序列模式和故障告警类型频繁序列模式，确定与故障告警日志中包括的故障对象对应的关联对象；根据故障对象和关联对象的时序关系，确定故障对象的故障原因。通过本申请，能够适应业务系统动态变化的故障检测需求，提高故障原因检测的准确率。
Description
技术领域
本申请涉及人工智能和云技术，尤其涉及一种业务系统的故障原因处理方法、装置、电子设备及计算机存储介质。
背景技术
人工智能(Artificial Intelligence，AI)是计算机科学的一个综合技术，通过研究各种智能机器的设计原理与实现方法，使机器具有感知、推理与决策的功能。随着技术的发展，人工智能技术将在更多的领域得到应用，并发挥越来越重要的价值。
随着数字化转型的推进，业务系统内的各种运行指标和调用关系日益复杂，结合人工智能的智能运维技术应运而生。故障定位是智能运维技术的典型应用，结合云技术的故障检测，针对业务系统发生的故障，能够迅速定位，并快速、准确、有效地分析出故障的原因，有效避免类似故障事件发生，减少故障带来的损失。
然而，申请人在实施本申请实施例的过程中发现，目前的故障原因分析方法需要依赖人工定位判断故障的逻辑来梳理故障之间的关联关系，不仅工作量大，而且故障情况覆盖率低，无法满足大规模的业务系统(例如互联网应用运维)的针对效率和准确率的诊断需求。
发明内容
本申请实施例提供一种业务系统的故障原因处理方法、装置、电子设备及计算机可读存储介质，能够适应业务系统动态变化的故障检测需求，提高故障原因检测的准确率和效率。
本申请实施例的技术方案是这样实现的：
本申请实施例提供一种业务系统的故障原因处理方法，包括：
获取业务系统的故障告警日志和运行指标的升降变化信息；
根据所述运行指标的升降变化信息，确定运行指标频繁序列模式；
将相似度高于相似度阈值的任意两个故障告警日志标记为相同的故障告警类型，根据标记得到的故障告警类型，确定故障告警类型频繁序列模式；
根据所述运行指标频繁序列模式和所述故障告警类型频繁序列模式，确定与所述故障告警日志中包括的故障对象对应的关联对象；
根据所述故障对象和所述关联对象的时序关系，确定所述故障对象的故障原因。
本申请实施例提供一种业务系统的故障原因处理装置，包括：。
获取模块，用于获取业务系统的运行指标的升降变化信息和故障告警日志；
运行指标模块，用于根据所述运行指标的升降变化信息，确定运行指标频繁序列模式；
故障告警类型模块，用于将相似度高于相似度阈值的任意两个故障告警日志标记为相同的故障告警类型，根据标记得到的故障告警类型，确定故障告警类型频繁序列模式；
筛选模块，用于根据所述运行指标频繁序列模式和所述故障告警类型频繁序列模式，确定与所述故障告警日志中包括的故障对象对应的关联对象；
识别模块，用于根据所述故障对象和所述关联对象的时序关系，确定所述故障对象的故障原因。
在上述方案中，所述业务系统的故障原因处理装置还包括：关联对象模块，用于根据所述运行指标频繁序列模式和所述故障告警类型频繁序列模式，确定所述业务系统中多个候选对象的对象权重；根据所述多个候选对象的对象权重，从所述多个候选对象中筛选得到与所述故障告警日志中包括的故障对象对应的关联对象。
在上述方案中，所述关联对象模块，还用于针对所述多个候选对象中的每个候选对象执行以下处理：根据所述运行指标频繁序列模式，确定所述候选对象的指标序列模式支持度；根据所述故障告警类型频繁序列模式，确定所述候选对象的故障告警类型序列模式支持度；对所述指标序列模式支持度和所述告警类型序列模式支持度进行加权求和处理，得到所述候选对象的对象权重。
在上述方案中，所述关联对象模块，还用于当所述故障对象的运行指标和所述候选对象的运行指标同时存在于所述运行指标频繁序列模式中时，将所述运行指标频繁序列模式的发生频率确定为所述候选对象的指标序列模式支持度；当所述故障对象的运行指标和所述候选对象的运行指标未同时存在于所述运行指标频繁序列模式中时，将预设的最小支持度阈值确定为所述候选对象的指标序列模式支持度。
在上述方案中，所述关联对象模块，还用于当所述故障对象的告警类型和所述候选对象的告警类型同时存在于所述故障告警类型频繁序列模式中时，将所述故障告警类型频繁序列模式的发生频率确定为所述候选对象的故障告警类型序列模式支持度；当所述故障对象的告警类型和所述候选对象的告警类型未同时存在于所述故障告警类型频繁序列模式中时，将预设的最小支持度阈值确定为所述候选对象的故障告警类型序列模式支持度。
在上述方案中，所述关联对象模块，还用于根据所述候选对象的对象权重对所述故障对象和所述候选对象进行加权聚类处理，得到多个聚类簇；将与所述故障对象属于同一聚类簇的所述候选对象，确定为与所述故障告警日志中包括的故障对象对应的关联对象。
在上述方案中，所述识别模块，还用于根据所述故障对象和所述关联对象的时序关系，确定在所述故障对象之前最先运行的关联对象；将在所述故障对象之前最先运行的关联对象，确定为所述故障对象的故障原因。
在上述方案中，所述将相似度高于相似度阈值的任意两个故障告警日志标记为相同的故障告警类型之前，所述故障告警类型模块，还用于在对所述故障告警日志进行编码处理，得到所述故障告警日志的文本向量；根据所述文本向量确定任意两个故障告警日志之间的相似度。
在上述方案中，所述将相似度高于相似度阈值的任意两个故障告警日志标记为相同的故障告警类型之前，所述故障告警类型模块，还用于对所述故障告警日志进行分词处理，确定分词处理得到的每个词语的词向量；对所述每个词语的词向量进行加权求和处理，得到所述故障告警日志的文本向量。
本申请实施例提供一种业务系统的故障原因处理装置，包括：
存储器，用于存储可执行指令；
处理器，用于执行所述存储器中存储的可执行指令时，实现本申请实施例提供的业务系统的故障原因处理方法。
本申请实施例提供一种计算机可读存储介质，存储有可执行指令，用于引起处理器执行时，实现本申请实施例提供的业务系统的故障原因处理方法。
本申请实施例具有以下有益效果：
从告警日志和运行指标中挖掘出运行指标频繁序列模式和故障告警类型频繁序列模式，由于运行指标频繁序列模式、故障告警类型频繁序列模式与业务系统运行数据的变化是同步的，因此序列模式能够及时准确地反映业务系统的故障的动态变化的特点，进而通过序列模式来挖掘故障对象以及故障原因，能够适应业务系统动态变化的故障检测需求，提高故障原因检测的效率和准确率。
附图说明
图1是本申请实施例提供的业务系统的故障原因处理系统架构结构示意图；
图2是本申请实施例提供的业务系统的故障原因处理装置的结构示意图；
图3是本申请实施例提供的业务系统的故障原因处理方法的流程示意图；
图4是本申请实施例提供的业务系统的故障原因处理方法的流程示意图；
图5是本申请实施例提供的业务系统的故障原因处理方法的流程示意图；
图6是本申请实施例提供的业务系统的故障原因处理方法的流程示意图。
具体实施方式
为了使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请作进一步地详细描述，所描述的实施例不应视为对本申请的限制，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例，都属于本申请保护的范围。
在以下的描述中，涉及到“一些实施例”，其描述了所有可能实施例的子集，但是可以理解,“一些实施例”可以是所有可能实施例的相同子集或不同子集，并且可以在不冲突的情况下相互结合。
除非另有定义，本文所使用的所有的技术和科学术语与属于本申请的技术领域的技术人员通常理解的含义相同。本文中所使用的术语只是为了描述本申请实施例的目的，不是旨在限制本申请。
对本申请实施例进行进一步详细说明之前，对本申请实施例中涉及的名词和术语进行说明，本申请实施例中涉及的名词和术语适用于如下的解释。
1)故障告警日志：网络设备、系统及服务程序等，在运行时可以通过故障告警日志记录产生的故障告警信息，每一条故障告警日志可以记载着对应故障的日期、时间、使用者及相关操作等信息。
2)运行指标：指系统中的软硬件在运行时的各项指标数值，例如剩余内存大小、磁盘空间、后台事务总耗时、历史故障次数、请求数、发送数据量、回调耗时、吞吐率、健康度、异常数、请求响应时长等。
3)故障告警类型：故障告警日志中包括的故障属于特定的故障类型，例如硬件冲突、软件故障、网络故障等。
申请人在实施本申请实施例的过程中发现，相关技术的故障原因分析技术，需要引入大量先验知识，依赖人工的故障定位判断逻辑，但由于人工制定的规则不好扩展，灵活性较低，对于复杂多变的运维环境，经过一定运行时间后，规则覆盖率会显著减低，需要不断地人工更新知识库和规则库，成本较大。近来，也有基于知识图谱技术来分析故障原因的方法，但图模型技术依赖海量的高质量数据，且图网络的复杂度随着网络节点的增加大幅增加，训练耗时也随之增加，降低了工业运维诊断的效率。
对此，本申请实施例提供一种业务系统的故障原因处理方法、装置、电子设备和计算机可读存储介质，能够适应业务系统动态变化的故障检测需求，提高故障原因检测的准确率。下面说明本申请实施例提供的业务系统的故障原因处理设备的示例性应用，本申请实施例提供的业务系统的故障原因处理设备可以实施为笔记本电脑，平板电脑，台式计算机，移动设备等各种类型的用户终端，也可以实施为服务器或者服务器集群，还可以采用由用户终端和服务器协同的方式实施。下面，将说明设备实施为服务器时的示例性应用。
参见图1，图1是本申请实施例提供的业务系统的故障原因处理系统100的一个架构示意图，业务系统中的服务器(示例性示出了服务器400-1和服务器400-2)通过网络300连接服务器200，服务器200也可以称为故障分析服务器，用于实施本申请实施例提供的业务系统的故障原因处理方法，服务器200通过与数据库500连接实现数据的存取，其中，网络300可以是广域网或者局域网，又或者是二者的组合。
示例性的，业务系统实施的业务可以是各种互联网服务，例如搜索、导航和购物等，对应的业务系统可以包括后台服务器集群、数据库系统和分布式存储系统等，例如图1中示出的服务器400-1和服务器400-2。在业务系统运行过程中，业务系统的各项运行指标会动态变化，例如服务器400-1和服务器400-2的请求数、发送数据量、吞吐率、请求响应时长等指标会随着业务系统的运行而实时变化，当业务系统运行出现异常或者发生故障时会生成故障告警日志，服务器200可以从服务器400-1和服务器400-2获取运行指标数据和故障告警日志，并结合运行指标数据和故障告警日志挖掘出故障的原因，随后，可以在与运维人员的人机交互界面中显示故障的处理过程和故障原因，也可以通过短信或者邮件的方式将故障的处理过程和故障原因发送给运维人员，以使运维人员可以快速了解业务系统的故障情况、定位故障原因，以便及时高效的对故障进行修复。
在一些实施例中，服务器200可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、CDN、以及大数据和人工智能平台等基础云计算服务的云服务器，本申请实施例中不做限制。
参见图2，图2是本申请实施例提供的业务系统的故障原因处理服务器200的结构示意图，图2所示的服务器200包括：至少一个处理器210、存储器250、至少一个网络接口220。服务器200中的各个组件通过总线系统240耦合在一起。可理解，总线系统240用于实现这些组件之间的连接通信。总线系统240除包括数据总线之外，还包括电源总线、控制总线和状态信号总线。但是为了清楚说明起见，在图2中将各种总线都标为总线系统240。
处理器210可以是一种集成电路芯片，具有信号的处理能力，例如通用处理器、数字信号处理器(DSP，Digital Signal Processor)，或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等，其中，通用处理器可以是微处理器或者任何常规的处理器等。
存储器250可以是可移除的，不可移除的或其组合。示例性的硬件设备包括固态存储器，硬盘驱动器，光盘驱动器等。存储器250可选地包括在物理位置上远离处理器210的一个或多个存储设备。
存储器250包括易失性存储器或非易失性存储器，也可包括易失性和非易失性存储器两者。非易失性存储器可以是只读存储器(ROM，Read Only Memory)，易失性存储器可以是随机存取存储器(RAM，Random Access Memory)。本申请实施例描述的存储器250旨在包括任意适合类型的存储器。
在一些实施例中，存储器250能够存储数据以支持各种操作，这些数据的示例包括程序、模块和数据结构或者其子集或超集，下面示例性说明。
操作系统251，包括用于处理各种基本系统服务和执行硬件相关任务的系统程序，例如框架层、核心库层、驱动层等，用于实现各种基础业务以及处理基于硬件的任务；
网络通信模块252，用于经由一个或多个(有线或无线)网络接口220到达其他计算设备，示例性的网络接口220包括：蓝牙、无线相容性认证(WiFi)、和通用串行总线(USB，Universal Serial Bus)等；
在一些实施例中，本申请实施例提供的业务系统的故障原因处理装置可以采用软件方式实现，图2示出了存储在存储器250中的业务系统的故障原因处理装置253，其可以是程序和插件等形式的软件，包括以下软件模块：获取模块2531、运行指标模块2532、故障告警类型模块2533、筛选模块2534和识别模块2535，这些模块是逻辑上的，因此根据所实现的功能可以进行任意的组合或进一步拆分。将在下文中说明各个模块的功能。
将结合本申请实施例提供的服务器的示例性应用和实施，说明本申请实施例提供的业务系统的故障原因处理方法。
参见图3，图3是本申请实施例提供的业务系统的故障原因处理方法的一个流程示意图，将结合图3示出的步骤进行说明。
在步骤101中，获取业务系统的故障告警日志和运行指标的升降变化信息。
在一些实施例中，可以获取业务系统的运行指标在多个采样点的指标值；根据预设时间间隔的采样点的运行指标的指标值，得到运行指标的升降变化信息。
其中，运行指标的升降变化信息表征在采样时间内的运行指标的变化趋势。
举例来说，为了获取运行指标的升降变化信息，可以实时采集业务系统的运行指标的时间序列数据，在每隔预置时间间隔(例如5s、5min、1h等)设置采样点，获取业务系统运行指标的指标值，根据在相邻采样点获取的指标值来判断运行指标值在每个单位时间间隔内的升降，并分别进行时序升降信息标记以获取运行指标时序升降信息。以1小时间隔为例，记录各个运行指标的升降趋势变化如表1，表1是业务系统运行指标升降变化示意表：
表1业务系统运行指标升降变化示意表
如表1所示，A指标、B指标和C指标均为业务系统的运行指标，在0-1时，运行指标的时序升降信息为减、增、增；在1-2时，运行指标的升降变化信息为增、减、增；在2-3时，运行指标的升降变化信息为减、增、减。
其中，业务系统的运行指标包括以下至少之一：剩余内存大小、磁盘空间、后台事务总耗时、历史故障次数、请求数、发送数据量、回调耗时、吞吐率、健康度、异常数、请求响应时长。
在一些实施例中，获取的业务系统中的故障告警日志，可以是业务系统服务器根据运行指标计算生成的，也可以是由独立的监控系统根据业务系统的运行情况生成的。
在步骤102中，根据运行指标的升降变化信息，确定运行指标频繁序列模式。
获取业务系统的运行指标的升降变化信息后，可以通过算法挖掘出运行指标频繁序列模式，即确定出一段时间范围内各运行指标升降信息在各个时间区间内频繁出现的变化模式。
在一些实施例中，可以通过前缀投影的序列模式挖掘(Prefixspan)算法挖掘运行指标频繁序列模式。Prefixspan算法的具体计算过程如下：在序列集合中，找出单位长度为1的一项运行指标升降序列前缀和对应投影数据集；统计运行指标升降序列前缀出现频率，即指标升降序列的支持度；将支持度高于最小支持度阈值的前缀添加到数据集，获取频繁项集序列模式；对所有长度为i(i为整数)且满足最小支持度要求的前缀递归挖掘：
1)挖掘前缀的投影数据集，如果投影数据为空集合，则返回递归；
2)统计对应投影数据集中各项的最小支持度，将满足支持度的各单项与当前缀合并，得到新前缀，不满足支持度要求则递归返回；
3)令i＝i+1，前缀为合并单项后的各个新前缀，分别递归执行3)；
返回运行指标升降序列样本集中所有频繁序列模式，并作为运行指标频繁序列模式。
其中，最小支持度阈值的计算公式为min_sup＝a×n，其中，a为最小支持率，最小支持率参数可以根据运行指标的升降变化信息的数量进行调整，n为采集运行指标数据的天数。
举例来说，假设基于步骤101得到业务系统在2020年07月01日8-9时的运行指标的升降变化信息为“A增-B增-C增-D减-E增-F减”，在2020年07月02日8-9时的运行指标的升降变化信息为“A减-B增-C增-D减-E减-F减”，其中，“A减”表示运行指标A在8-9时数值下降，“B增”表示运行指标B在8-9时数值上升。接下来，基于Prefixspan算法挖掘运行指标的频繁序列模式，假设所设定的最小支持度阈值为0.5，首先统计运行指标值发生变化的频率，结果如下：
A增：1；A减：1；B增：2；C增：2；D减：2；E增：1；E减：1；F减：2。
满足最小支持度阈值的一项前缀与其对应的后缀分别为：
B增：C增-D减-E增-F减/C增-D减-E减-F减；
C增：D减-E增-F减/D减-E减-F减；
D减：E增-F减/E减-F减；
F减：空。
同样地，满足最小支持度阈值的二项前缀和与其对应的后缀分别为：
B增-C增：D减-E增-F减/D减-E减-F减；
C增-D减：E增-F减/E减-F减；
D减-F减：空。
同样的，满足最小支持度阈值的三项前缀和与其对应的后缀分别为：
B增-C增-D减：E增-F减/E减-F减；
C增-D减-F减：空。
同样的，满足最小支持度阈值的四项前缀和与其对应的后缀为：
B增-C增-D减-F减：空。
将所挖掘的最长前缀序列作为业务系统运行指标升降序列的频繁序列模式，即将“B增-C增-D减-F减”作为运行指标频繁序列模式。此外，该模式会随着历史时间范围内业务系统运行情况的实时更新发生变化，实时挖掘得到最新的变化趋势。
通过设置时间间隔分析业务系统运行指标增减趋势，并基于趋势挖掘运行指标频繁序列模式，发现运行指标的升降信息之间隐含着的运行指标间潜在因果关系和关联关系。
在步骤103中，将相似度高于相似度阈值的任意两个故障告警日志标记为相同的故障告警类型，根据标记得到的故障告警类型，确定故障告警类型频繁序列模式。
在一些实施例中，参见图4，图4示出的是本申请实施例提供的业务系统的故障原因处理方法的一个流程示意图，将相似度高于相似度阈值的任意两个故障告警日志标记为相同的故障告警类型之前，还包括步骤106-步骤107，下面进行说明。
在步骤106中，对故障告警日志进行编码处理，得到故障告警日志的文本向量。
示例性的，对故障告警日志进行分词处理，确定分词处理得到的每个词语的词向量；对每个词语的词向量进行加权求和处理，得到故障告警日志的文本向量。其中，可以使用条件随机场或者隐马尔科夫模型等机器学习算法来对故障告警日志进行分词处理，对分词得到的每个词语使用Word2vec词向量模型进行编码，得到每个词语的词向量，并使用词频-逆文档频率(TF-IDF，term fre quency-inverse document frequency)方法计算故障告警日志中每个词语的权重，得到故障告警日志中每个词语的词向量和权重后，对每个词语进行加权求和处理得到故障告警日志的文本向量，完成故障告警日志文本向量化。
在步骤107中，根据文本向量确定任意两个故障告警日志之间的相似度。
在获取故障告警日志的文本向量后，可以通过计算任意两个故障告警日志的文本向量的距离，并利用文本向量的距离来表征任意两个故障告警日志之间的相似度。其中，文本向量的距离包括以下至少之一：余弦相似度、曼哈顿距离、欧几里得距离、明式距离。
通过计算故障告警日志的文本向量并使用文本向量的距离来表征任意两个故障告警日志的相似度，加快了任意两个故障告警日志相似度的比较速度，便于确定属于同类型的故障告警日志。
在一些实施例中，标记得到故障告警类型后，可以通过算法挖掘出业务系统的故障告警类型频繁序列模式，即确定出一段时间范围内各故障告警类型在各个时间区间内频繁出现的变化模式。
举例来说，可以通过前缀投影的序列模式挖掘(Prefixspan)算法挖掘故障告警类型频繁序列模式，挖掘方式与挖掘运行指标频繁序列模式相同。假设进行故障告警类型标记后，得到业务系统在2020年07月01日8-9时的故障告警类型序列为“A类型告警-B类型告警-C类型告警”，在2020年07月02日8-9时的故障告警类型序列为“A类型告警-C类型告警”，在2020年07月03日8-9时的故障告警类型序列为“B类型告警-E类型告警-C类型告警”，假设所设定的最小支持度阈值为0.5，首先统计故障告警类型的出现频率，结果如下：
A类型告警：2；B类型告警：2；C类型告警：3；E类型告警：1。
满足最小支持度阈值的一项前缀与其对应的后缀分别为：
A类型告警：B类型告警-C类型告警/C类型告警；
B类型告警：C类型告警；
C类型告警：空。
同样地，满足最小支持度阈值的二项前缀和与其对应的后缀分别为：
A类型告警-C类型告警：空；
B类型告警-C类型告警：空。
将所挖掘的最长前缀序列作为业务系统故障告警类型序列的频繁序列模式，即将“A类型告警-C类型告警/B类型告警-C类型告警”作为故障告警类型频繁序列模式。此外，该模式会随着历史时间范围内业务系统运行情况的实时更新发生变化，实时挖掘得到最新的变化趋势。
在步骤104中，根据运行指标频繁序列模式和故障告警类型频繁序列模式，确定与故障告警日志中包括的故障对象对应的关联对象。
参见图5，图5示出的是本申请实施例提供的业务系统的故障原因处理方法的一个流程示意图。图3中的步骤104可以由步骤1041-1042实现，下面具体说明。
在步骤1041中，根据运行指标频繁序列模式和故障告警类型频繁序列模式，确定业务系统中多个候选对象的对象权重。
在一些实施例中，为了分析故障的原因，可以在业务系统中确定与故障相关的多个候选对象，其中，候选对象可以是业务系统中与发生故障的故障对象耦合的对象。针对多个候选对象中的每个候选对象执行以下处理：根据运行指标频繁序列模式，确定候选对象的指标序列模式支持度；根据故障告警类型频繁序列模式，确定候选对象的故障告警类型序列模式支持度；对指标序列模式支持度和告警类型序列模式支持度进行加权求和处理，得到候选对象的对象权重。
其中，为了确定候选对象的指标序列模式支持度，当故障对象的运行指标和候选对象的运行指标同时存在于运行指标频繁序列模式中时，将运行指标频繁序列模式的发生频率确定为候选对象的指标序列模式支持度；当故障对象的运行指标和候选对象的运行指标未同时存在于运行指标频繁序列模式中时，将预设的最小支持度阈值确定为候选对象的指标序列模式支持度。
承接上述示例，在步骤102中确定的运行指标频繁序列模式是B增-C增-D减-F减，假设故障对象的运行指标包括B、C，候选对象的故障运行指标包括D，则说明故障对象的运行指标和候选对象的运行指标同时存在于运行指标频繁序列模式中，此时，将运行指标频繁序列模式的发生频率确定为候选对象的指标序列模式支持度，即，
例如，频繁序列模式B增-C增-D减-F减在2020年07月01日8-9时和2020年07月02日8-9时采集的样本中均出现了，则序列模式出现样本数为2，总样本数为2，因此，频繁序列模式B增-C增-D减-F减的发生频率为1，候选对象的指标序列模式支持度也为1。
假设故障对象的运行指标未包括B、C、D、F，或候选对象的故障运行指标未包括B、C、D、F，则说明故障对象的运行指标和候选对象的运行指标未同时存在于运行指标频繁序列模式中，此时，将预设的最小支持度阈值确定为候选对象的指标序列模式支持度，例如，在上述示例中，设定的最小支持度阈值为0.5，因此，候选对象的指标序列模式支持度为0.5。
其中，为了确定候选对象的故障告警类型序列模式支持度，当故障对象的告警类型和候选对象的告警类型同时存在于故障告警类型频繁序列模式中时，将故障告警类型频繁序列模式的发生频率确定为候选对象的故障告警类型序列模式支持度；当故障对象的告警类型和候选对象的告警类型未同时存在于故障告警类型频繁序列模式中时，将预设的最小支持度阈值确定为候选对象的故障告警类型序列模式支持度。
承接上述示例，在步骤103中确定的故障告警类型频繁序列模式是A类型告警-C类型告警/B类型告警-C类型告警，假设故障对象的故障告警类型为A，候选对象的故障运行指标包括C，则说明故障对象的告警类型和候选对象的告警类型同时存在于故障告警类型频繁序列模式中，此时，将故障告警类型频繁序列模式的发生频率确定为候选对象的故障告警类型序列模式支持度，即，
例如，频繁序列模式A类型告警-C类型告警在2020年07月01日8-9时、2020年07月02日8-9时和2020年07月03日8-9时采集的样本中出现了2次，则序列模式出现样本数为2，总样本数为3，因此，频繁序列模式A类型告警-C类型告警的发生频率为2/3，候选对象的指标序列模式支持度也为2/3。
假设故障对象的运行指标未包括A、C，或候选对象的故障运行指标未包括A、C，以及故障对象的运行指标未包括B、C，或候选对象的故障运行指标未包括B、C，则说明故障对象的告警类型和候选对象的告警类型未同时存在于故障告警类型频繁序列模式中，此时，将预设的最小支持度阈值确定为候选对象的故障告警类型序列模式支持度，例如，在上述示例中，设定的最小支持度阈值为0.5，因此，候选对象的故障告警类型序列模式支持度为0.5。
候选对象的对象权重体现了候选对象与故障对象之间的关联性强弱，为了得到候选对象的对象权重，可以通过对指标序列模式支持度和告警类型序列模式支持度进行加权求和处理。指标序列模式支持度越高，即包括候选对象的运行指标和故障对象的运行指标的特定升降模式经常出现，说明候选对象和故障对象两者之间的关联性越强。告警类型序列模式支持度越高，即包括候选对象的故障告警类型和故障对象的故障告警类型的经常出现，说明候选对象和故障对象两者之间的关联性越强。对指标序列模式支持度和告警类型序列模式支持度进行加权求和处理，可以综合运行指标的升降信息和故障告警类型信息来确定候选对象的对象权重，提高与故障对象有关的关联对象的查找准确率。
举例来说，假设指标序列模式支持度的权重为m1和告警类型序列模式支持度的权重为m2,候选对象的对象权重计算方式如下：
对象权重＝m1*指标序列模式支持度+m2*告警类型序列模式支持度
其中，m1+m2＝1，m1和m2的数值可以根据采集的运行指标升降变化信息和故障告警日志的数据量和数据质量进行设定，例如，当采集的业务系统的运行指标的升降变化信息的数量和质量比采集的故障告警日志高时，可以将m1设置为0.7，m2和设置为0.3。
在步骤1042中，根据多个候选对象的对象权重，从多个候选对象中筛选得到与故障告警日志中包括的故障对象对应的关联对象。
示例性的，根据候选对象的对象权重对故障对象和候选对象进行加权聚类处理，得到多个聚类簇；将与故障对象属于同一聚类簇的候选对象，确定为与故障告警日志中包括的故障对象对应的关联对象。
举例来说，先构建业务系统中各对象的对象特征，如内存大小、磁盘空间、后台事务总耗时、历史故障次数、请求数、发送数据量、回调耗时、吞吐率、健康度、异常数、请求响应时长等。需要说明的是对象的特征与业务系统的运行指标可以存在交集。通过聚类算法对故障对象和候选对象的对象特征进行基于对象权重的加权聚类，得到多个聚类簇。确定故障对象所处的聚类簇，并将与故障对象属于同一聚类簇的候选对象，确定为与故障告警日志中包括的故障对象对应的关联对象。
通过加权聚类的方式获取故障对象的关联对象，既考虑到了故障对象与候选对象的特征的相似性，也考虑到了运行指标的升降变化信息与故障告警日志中隐含的关联关系，可以确保关联对象与故障对象具有较强的关联性，以提高故障原因分析的效率和准确性。
在步骤105中，根据故障对象和关联对象的时序关系，确定故障对象的故障原因。
当确定了与故障对象相关的关联对象后，可以根据故障对象与关联对象的运行时序来确定故障的原因，完成故障原因分析。
在一些实施例中，根据故障对象和关联对象的时序关系，确定在故障对象之前最先运行的关联对象；将在故障对象之前最先运行的关联对象，确定为故障对象的故障原因。
其中，时序关系包括以下之一：对象执行时序、发生故障告警的时序、运行指标变化的时序。
举例来说，经过步骤104后，确定业务系统中对象A与B之间具有关联关系，即对象B为故障对象，对象A为对象B的关联对象。根据对象A与对象B的时序关系：例如历史数据中显示先接收到A的故障告警，后接收到B的故障告警，或者A先发生运行指标变化，B后发生运行指标变化，那么确定对象A为父事件，对象B为子事件，即确定对象A为对象B的故障原因。
下面，将说明本申请实施例在一个实际的应用场景中的示例性应用。
示例性的，本申请实施例提供的业务系统的故障原因处理方法可以集成到智能运维软件并运行在服务器200中，以针对互联网业务(例如搜索、导航和购物等)的后台服务器(例如图1中示出的服务器400-1和服务器400-2)在运行过程中的故障进行分析，并在与运维人员的人机交互界面中显示故障的处理过程和故障原因，也可以通过短信或者邮件的方式将故障的处理过程和故障原因发送给运维人员，以使运维人员可以快速了解故障情况、定位故障原因，以便及时高效的进行修复。
参见图6，图6中示出的是本申请实施例提供的业务系统的故障原因处理方法的一个流程示意图，分别包括步骤601，提取运行指标的时间序列数据和故障告警信息；步骤602，对故障告警日志进行文本向量化；步骤603，文本向量相似度计算对同类故障告警进行标识；步骤604，挖掘运行指标升降和故障告警类型隐含的序列模式；步骤605，对故障候选关联对象特征加权聚类确定故障原因。下面分别介绍。
步骤601，提取运行指标的时间序列数据和故障告警信息。可以获取业务系统的两部分数据用于故障告警的智能原因分析：一部分是实时采集的运行指标时序信息；另一部分是基于运行指标计算和上报的故障告警信息。运行指标升降变化信息需要对原始的运行指标时序信息进行数据处理，即设置多时间间隔(例如5s、5min、1h等)，判断运行指标值在每个单位时间间隔内的升降并分别进行时序升降信息标记。以1小时间隔为例，记录业务系统的运行指标的升降趋势变化如表1所示，表2是业务系统指标升降变化示意表：
表2业务系统指标升降变化示意表
步骤602，对故障告警日志进行文本向量化。故障告警日志属于半结构化数据，特点是实时而且数据丰富，有利于问题发现和定位。将故障告警日志文本进行文本向量化，具体做法是：首先对文本进行文本分词(仅限中文，英文则不需要分词)，利用Word2vec词向量模型训练获取文本中每个词的词向量，由于故障告警日志里面有许多格式词，目的是统一告警规范，因此这些格式词在很多故障告警日志中都会出现，为了降低这部分格式词对文本向量化特征表示的影响，采用TFIDF计算各个故障告警日志中每个词的特征权重。
利用TFIDF构建各个故障告警日志文本的特征词权重目的在于：若一个词在该日志文本经常出现，而在其他日志文本很少出现，那么说明该词对该日志文本的识别具有区分能力。
TF为词频，即某个词在所有的文本中出现的频率，IDF为逆文档频率，TFIDF的计算公式如下。
TF-IDF＝词频(TF)*逆文档频率(IDF)
得到故障告警日志文本中每个词的词向量和词特征权重后，对每个词进行加权求和得到该故障告警日志文本的文本向量，完成故障告警日志的文本向量化。
步骤603，文本向量相似度计算对同类故障告警进行标识。基于602得到的各个故障告警日志文本的文本向量，通过计算文本向量的距离获取任意两个故障告警日志之间的相似度，将相似度高于设定阈值的故障告警日志标识为同类告警。
步骤604，挖掘运行指标升降和故障告警类型隐含的序列模式。
运行指标之间的升降变化信息往往隐含着运行指标之间是否有潜在的因果关系和关联关系，因此挖掘运行指标升降变化信息的序列模式对于故障原因分析是非常必要的。本申请基于prefixspan算法挖掘运行指标值变化中的运行指标频繁序列模式。同时，使用多最小支持度策略，最小支持度min_sup＝a*n，其中，n为采集运行指标信息的时间范围天数，a为最小支持率，最小支持率可以根据采集的运行指标信息的数量进行调整。
prefixspan算法的具体操作步骤如下：
1.找出单位长度为1的指标时序升降序列前缀和对应投影数据集；
2.统计指标时序升降序列前缀出现频率并将支持度高于最小支持度阈值的前缀添加到数据集，获取频繁一项集序列模式；
3.对所有长度为i且满足最小支持度要求的前缀递归挖掘：
1)挖掘前缀的投影数据集，如果投影数据为空集合，则返回递归；
2)统计对应投影数据集中各项的最小支持度，将满足支持度的各单项与当前缀合并，得到新前缀，不满足支持度要求则递归返回；
3)令i＝i+1，前缀为合并单项后的各个新前缀，分别递归执行第3步；4.返回指标时序升降序列样本集中所有频繁序列模式。
以上是Prefixspan算法的原理描述，以下举例说明指标时序升降序列模式具体的挖掘方式。
基于获取的运行指标升降变化信息，其中包含对应变化的指标标识符，如A指标增加表示为“A增”，结果如表3所示：
表3运行指标时序升降序列示意表
| 日期(天) | 时间段 | 指标时序升降序列 |
| 20200701 | 8-9时 | A增-B增-C增-D减-E增-F减 |
| 20200702 | 8-9时 | A减-B增-C增-D减-E减-F减 |
接下来，基于Prefixspan算法挖掘不同天时间间隔(也可以是不同天不同时间段)内指标时序升降序列中隐含的序列模式，假设所设定的最小支持度阈值为0.5，首先统计所有指标值发生变化的频率，如表4所示：
表4运行指标发生变化的情况统计表
满足最小支持度阈值的一项前缀与其对应后缀分别，如表5所示：
表5一项前缀与其对应后缀示意表
同样地，满足最小支持度阈值的二项前缀和对应后缀，如表6所示：
表6二项前缀与其对应后缀示意表
满足最小支持度阈值的三项前缀和对应后缀，如表7所示：
表7三项前缀与其对应后缀示意表
满足最小支持度阈值的四项前缀和对应后缀，如表8所示：
表8四项前缀与其对应后缀示意表
| 四项前缀 | 对应后缀 |
| B增-C增-D减-F减 |
将所挖掘的最长前缀序列作为业务系统运行指标频繁序列模式，该模式会随着历史时间范围内的数据实时更新变化，实时挖掘得到最新隐含序列模式。将所挖掘的最长前缀序列作为业务系统运行指标升降序列的频繁序列模式，即将“B增-C增-D减-F减”作为运行指标频繁序列模式。此外，该模式会随着历史时间范围内业务系统运行情况的实时更新发生变化，实时挖掘得到最新的变化趋势。
对应的，指标序列模式支持度计算方式为：
基于步骤603将同类故障告警进行标记，得到了故障告警日志的故障类型，挖掘故障告警类型的频繁序列模式，挖掘方法同上述运行指标频繁序列模式。
示例说明如下：按故障告警时间在各个指定时间范围内先后顺序，获取以下故障告警类型样本，如表9所示：
表9故障告警类型样本示意表
| A类型告警 | B类型告警 | C类型告警 |
| A类型告警 | C类型告警 | |
| B类型告警 | E类型告警 | C类型告警 |
假设所设定的最小支持度阈值为0.5，首先统计所有故障告警类型的出现频率，如表10所示：
表10故障告警类型情况统计表
| 故障告警类型 | A类型告警 | B类型告警 | C类型告警 | E类型告警 |
| 出现次数 | 2 | 2 | 3 | 1 |
过滤不符合最小支持度阈值的事件类型，剩余事件类型进行频繁序列模式挖掘。
满足最小支持度阈值的一项前缀与其对应后缀如表11所示：
表11一项前缀与其对应后缀示意表
满足最小支持度阈值的二项前缀和对应后缀如表12所示：
表12二项前缀与其对应后缀示意表
| 二项前缀 | 对应后缀 |
| A类型告警C类型告警 | |
| B类型告警C类型告警 |
将所挖掘的最长前缀序列作为业务系统故障告警类型序列的频繁序列模式，即将“A类型告警-C类型告警/B类型告警-C类型告警”作为故障告警类型频繁序列模式。此外，该模式会随着历史时间范围内业务系统运行情况的实时更新发生变化，实时挖掘得到最新的变化趋势。此时，将故障告警类型频繁序列模式的发生频率确定为所述候选对象的故障告警类型序列模式支持度，计算方式与指标序列模式支持度计算方式相同。
步骤605，对故障候选对象特征加权聚类确定故障原因。步骤605可以通过步骤6051-6053实现，下面具体说明。
步骤6051，构建对象特征。可以使用业务系统中对象的属性特征或事件特征来构建对象特征，如内存大小、磁盘空间、后台事务总耗时、历史故障次数、请求数、发送数据量、回调耗时、吞吐率、健康度、异常数、请求响应时长等。
业务系统中的对象之间会具有相同的属性，以对象是业务系统中的组件为例，每个组件有同样的属性，如组件的内存、磁盘、后台事物总耗时、历史故障次数，从中选取50维作为特征，然后对特征进行预处理和特征构建，具体步骤包括：舍弃缺失值过多的特征，若某特征数据缺失的数量超过阈值则舍弃这个特征，同时删除单值特征；进行异常值处理：根据特征分布，舍弃特征数值太大、排在前预设比例的异常值，具体预设比例根据应用场景而设定；缺失值处理：连续型特征用均值填充，离散型特征用常数填充作为单独类别；特征衍生：通过特征变换、特征平方、特征加减进行特征组合和衍生；特征处理：连续型特征进行分箱离散化、离散型特征进行one-hot编码。
步骤6052，确定候选对象权重。具体计算方式为：
对象权重＝m1*指标序列模式支持度+m2*告警类型序列模式支持度
其中，m1+m2＝1，m1和m2均设置为0.5则两个模式支持度等权，m1和m2具体数值可以根据实际场景进行调整。当候选组件的指标和故障组件的指标同时出现在序列模式中时，指标序列模式支持度等于步骤604中的序列模式支持度。例如，假设挖掘出的最长前缀序列为ABCD，A为故障组件的指标，B为候选组件的指标，可以得出A、B两指标具有很强的关联性，因此故障组件和该候选组件也具有强相关性，因此，将最长前缀序列的序列模式的支持度作为该候选组件的指标序列模式支持度。当故障组件的指标未出现在序列模式中时，按步骤604中的最小支持度阈值设置(理论上应小于或等于该设置的最小支持度阈值)。对于不构成序列模式的组件样本，支持度按步骤604中的最小支持度阈值设置(理论上应小于或等于该设置的最小支持度阈值)；告警类型隐含序列模式支持度的计算方式同理。
步骤6053，特征加权聚类。构建加权聚类算法对特征向量进行聚类，具体聚类过程如下，在传统的基于划分的聚类算法中，一般都是对聚类样本同等对待，例如K-means算法、EM算法等。在不考虑聚类对象的权重的前提下，K-means聚类算法在准则函数收敛时结束聚类，准则函数的公式为
其中，J为凝聚度，用来衡量聚类效果，k为类簇的总数目，mi是类簇i中的成员总数；
为类簇i中的第j个成员；
为类簇i的中心向量，计算公式为：
考虑对象权重的加权聚类算法，加权后聚类的准则函数计算公式为：
其中，J′为凝聚度，用来衡量加权聚类的效果，k为类簇的总数目，mi是类簇i中的成员总数；
为类簇i中的第j个成员；
为聚类样本加权后的类中心向量，计算公式为：
其中，wj为聚类样本i的权重，对应步骤6052中的候选对象的对象权重，通过加权聚类得到聚类结果。
将与故障组件聚类到同个类别下的候选组件作为故障组件的关联组件，进一步根据故障发生时间、时序时间锁定故障事件中的父子关系，完成故障原因分析。
例如已锁定组件A与组件B之间有关联，根据A与B的故障发生时间、指标变化时序关系：例如历史数据中先接收到A的告警故障，后接收到B的告警故障，或者A先发生时序指标变化，B后发生时序指标变化，那么确定A为父事件，B为子事件。当聚类后，同个类别下有多个组件时，在前发生是后发生父事件，在后发生是前发生的子事件。
下面继续说明本申请实施例提供的业务系统的故障原因处理装置的实施为软件模块的示例性结构，在一些实施例中，如图2所示，存储在存储器250的业务系统的故障原因处理装置253中的软件模块可以包括：
获取模块2531，用于获取业务系统的运行指标的升降变化信息和故障告警日志；
运行指标模块2532，用于根据所述运行指标的升降变化信息，确定运行指标频繁序列模式；
故障告警类型模块2533，用于将相似度高于相似度阈值的任意两个故障告警日志标记为相同的故障告警类型，根据标记得到的故障告警类型，确定故障告警类型频繁序列模式；
筛选模块2534，用于根据所述运行指标频繁序列模式和所述故障告警类型频繁序列模式，确定与所述故障告警日志中包括的故障对象对应的关联对象；
识别模块2535，用于根据所述故障对象和所述关联对象的时序关系，确定所述故障对象的故障原因。
在一些实施例中，所述业务系统的故障原因处理装置还包括：关联对象模块，用于根据所述运行指标频繁序列模式和所述故障告警类型频繁序列模式，确定所述业务系统中多个候选对象的对象权重；根据所述多个候选对象的对象权重，从所述多个候选对象中筛选得到与所述故障告警日志中包括的故障对象对应的关联对象。
在一些实施例中，所述关联对象模块，还用于针对所述多个候选对象中的每个候选对象执行以下处理：根据所述运行指标频繁序列模式，确定所述候选对象的指标序列模式支持度；根据所述故障告警类型频繁序列模式，确定所述候选对象的故障告警类型序列模式支持度；对所述指标序列模式支持度和所述告警类型序列模式支持度进行加权求和处理，得到所述候选对象的对象权重。
在一些实施例中，所述关联对象模块，还用于当所述故障对象的运行指标和所述候选对象的运行指标同时存在于所述运行指标频繁序列模式中时，将所述运行指标频繁序列模式的发生频率确定为所述候选对象的指标序列模式支持度；当所述故障对象的运行指标和所述候选对象的运行指标未同时存在于所述运行指标频繁序列模式中时，将预设的最小支持度阈值确定为所述候选对象的指标序列模式支持度。
在一些实施例中，所述关联对象模块，还用于当所述故障对象的告警类型和所述候选对象的告警类型同时存在于所述故障告警类型频繁序列模式中时，将所述故障告警类型频繁序列模式的发生频率确定为所述候选对象的故障告警类型序列模式支持度；当所述故障对象的告警类型和所述候选对象的告警类型未同时存在于所述故障告警类型频繁序列模式中时，将预设的最小支持度阈值确定为所述候选对象的故障告警类型序列模式支持度。
在一些实施例中，所述关联对象模块，还用于根据所述候选对象的对象权重对所述故障对象和所述候选对象进行加权聚类处理，得到多个聚类簇；将与所述故障对象属于同一聚类簇的所述候选对象，确定为与所述故障告警日志中包括的故障对象对应的关联对象。
在一些实施例中，所述识别模块，还用于根据所述故障对象和所述关联对象的时序关系，确定在所述故障对象之前最先运行的关联对象；将在所述故障对象之前最先运行的关联对象，确定为所述故障对象的故障原因。
在一些实施例中，所述将相似度高于相似度阈值的任意两个故障告警日志标记为相同的故障告警类型之前，所述故障告警类型模块，还用于在对所述故障告警日志进行编码处理，得到所述故障告警日志的文本向量；根据所述文本向量确定任意两个故障告警日志之间的相似度。
在一些实施例中，所述将相似度高于相似度阈值的任意两个故障告警日志标记为相同的故障告警类型之前，所述故障告警类型模块，还用于对所述故障告警日志进行分词处理，确定分词处理得到的每个词语的词向量；对所述每个词语的词向量进行加权求和处理，得到所述故障告警日志的文本向量。
本申请实施例提供一种计算机可读存储介质，存储有可执行指令，用于引起处理器执行时，实现本申请实施例提供的业务系统的故障原因处理方法。
在一些实施例中，计算机可读存储介质可以是FRAM、ROM、PROM、EP ROM、EEPROM、闪存、磁表面存储器、光盘、或CD-ROM等存储器；也可以是包括上述存储器之一或任意组合的各种设备。
在一些实施例中，可执行指令可以采用程序、软件、软件模块、脚本或代码的形式，按任意形式的编程语言(包括编译或解释语言，或者声明性或过程性语言)来编写，并且其可按任意形式部署，包括被部署为独立的程序或者被部署为模块、组件、子例程或者适合在计算环境中使用的其它单元。
作为示例，可执行指令可以但不一定对应于文件系统中的文件，可以可被存储在保存其它程序或数据的文件的一部分，例如，存储在超文本标记语言(H TML，Hyper TextMarkup Language)文档中的一个或多个脚本中，存储在专用于所讨论的程序的单个文件中，或者，存储在多个协同文件(例如，存储一个或多个模块、子程序或代码部分的文件)中。
作为示例，可执行指令可被部署为在一个计算设备上执行，或者在位于一个地点的多个计算设备上执行，又或者，在分布在多个地点且通过通信网络互连的多个计算设备上执行。
综上所述，通过本申请实施例具有以下有益技术效果：
(1)基于序列模式挖掘算法挖掘运行指标和故障告警类型的模式特征，模式特征会随着历史数据的变化而变化，适应了动态运维变化的需求。
(2)基于所挖掘的指标时序升降序列模式和标识告警序列模式进行支持度加权聚类，整个故障原因分析过程无监督，不需要提前标注故障关联关系，节省了人力成本，提升了效率。
(3)本申请对故障对象与其关联对象进行支持度加权聚类，能够将与待分析的故障对象关系紧密的目标群体聚集在一起，从而得到故障原因，分析结果更准确。
以上所述，仅为本申请的实施例而已，并非用于限定本申请的保护范围。凡在本申请的精神和范围之内所作的任何修改、等同替换和改进等，均包含在本申请的保护范围之内。
Claims (10)
1.一种业务系统的故障原因处理方法，其特征在于，包括：
获取业务系统的故障告警日志和运行指标的升降变化信息；
根据所述运行指标的升降变化信息，确定运行指标频繁序列模式；
将相似度高于相似度阈值的任意两个故障告警日志标记为相同的故障告警类型，根据标记得到的故障告警类型，确定故障告警类型频繁序列模式；
根据所述运行指标频繁序列模式和所述故障告警类型频繁序列模式，确定与所述故障告警日志中包括的故障对象对应的关联对象；
根据所述故障对象和所述关联对象的时序关系，确定所述故障对象的故障原因。
2.根据权利要求1所述的方法，其特征在于，所述根据所述运行指标频繁序列模式和所述故障告警类型频繁序列模式，确定与所述故障告警日志中包括的故障对象对应的关联对象，包括：
根据所述运行指标频繁序列模式和所述故障告警类型频繁序列模式，确定所述业务系统中多个候选对象的对象权重；
根据所述多个候选对象的对象权重，从所述多个候选对象中筛选得到与所述故障告警日志中包括的故障对象对应的关联对象。
3.根据权利要求2所述的方法，其特征在于，所述根据所述运行指标频繁序列模式和所述故障告警类型频繁序列模式，确定所述业务系统中多个候选对象的对象权重，包括：
针对所述多个候选对象中的每个候选对象执行以下处理：
根据所述运行指标频繁序列模式，确定所述候选对象的指标序列模式支持度；
根据所述故障告警类型频繁序列模式，确定所述候选对象的故障告警类型序列模式支持度；
对所述指标序列模式支持度和所述告警类型序列模式支持度进行加权求和处理，得到所述候选对象的对象权重。
4.根据权利要求3所述的方法，其特征在于，所述根据所述运行指标频繁序列模式，确定所述候选对象的指标序列模式支持度，包括：
当所述故障对象的运行指标和所述候选对象的运行指标同时存在于所述运行指标频繁序列模式中时，将所述运行指标频繁序列模式的发生频率确定为所述候选对象的指标序列模式支持度；
当所述故障对象的运行指标和所述候选对象的运行指标未同时存在于所述运行指标频繁序列模式中时，将预设的最小支持度阈值确定为所述候选对象的指标序列模式支持度。
5.根据权利要求3所述的方法，其特征在于，所述根据所述故障告警类型频繁序列模式，确定所述候选对象的故障告警类型序列模式支持度，包括：
当所述故障对象的告警类型和所述候选对象的告警类型同时存在于所述故障告警类型频繁序列模式中时，将所述故障告警类型频繁序列模式的发生频率确定为所述候选对象的故障告警类型序列模式支持度；
当所述故障对象的告警类型和所述候选对象的告警类型未同时存在于所述故障告警类型频繁序列模式中时，将预设的最小支持度阈值确定为所述候选对象的故障告警类型序列模式支持度。
6.根据权利要求2所述的方法，其特征在于，所述根据所述候选对象的对象权重，从所述候选对象中筛选得到所述故障告警日志中包括的故障对象对应的关联对象，包括：
根据所述候选对象的对象权重对所述故障对象和所述候选对象进行加权聚类处理，得到多个聚类簇；
将与所述故障对象属于同一聚类簇的所述候选对象，确定为与所述故障告警日志中包括的故障对象对应的关联对象。
7.根据权利要求1所述的方法，其特征在于，所述根据所述故障对象和所述关联对象的时序关系，确定所述故障对象的故障原因，包括：
根据所述故障对象和所述关联对象的时序关系，确定在所述故障对象之前最先运行的关联对象；
将在所述故障对象之前最先运行的关联对象，确定为所述故障对象的故障原因。
8.根据权利要求1至7任一项所述的方法，其特征在于，所述将相似度高于相似度阈值的任意两个故障告警日志标记为相同的故障告警类型之前，还包括：
对所述故障告警日志进行编码处理，得到所述故障告警日志的文本向量；
根据所述文本向量确定任意两个故障告警日志之间的相似度。
9.根据所述权利要求8所述的方法，其特征在于，所述对所述故障告警日志进行编码，得到所述故障告警日志的文本向量，包括：
对所述故障告警日志进行分词处理，确定分词处理得到的每个词语的词向量；
对所述每个词语的词向量进行加权求和处理，得到所述故障告警日志的文本向量。
10.一种业务系统的故障原因处理装置，其特征在于，包括：
获取模块，用于获取业务系统的运行指标的升降变化信息和故障告警日志；
运行指标模块，用于根据所述运行指标的升降变化信息，确定运行指标频繁序列模式；
故障告警类型模块，用于将相似度高于相似度阈值的任意两个故障告警日志标记为相同的故障告警类型，根据标记得到的故障告警类型，确定故障告警类型频繁序列模式；
筛选模块，用于根据所述运行指标频繁序列模式和所述故障告警类型频繁序列模式，确定与所述故障告警日志中包括的故障对象对应的关联对象；
识别模块，用于根据所述故障对象和所述关联对象的时序关系，确定所述故障对象的故障原因。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202011080651.8A CN114327964A (zh) | 2020-10-10 | 2020-10-10 | 业务系统的故障原因处理方法、装置、设备及存储介质 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202011080651.8A CN114327964A (zh) | 2020-10-10 | 2020-10-10 | 业务系统的故障原因处理方法、装置、设备及存储介质 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN114327964A true CN114327964A (zh) | 2022-04-12 |
Family
ID=81032838
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202011080651.8A Pending CN114327964A (zh) | 2020-10-10 | 2020-10-10 | 业务系统的故障原因处理方法、装置、设备及存储介质 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN114327964A (zh) |
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN115174350A (zh) * | 2022-06-30 | 2022-10-11 | 济南浪潮数据技术有限公司 | 一种运维告警方法、装置、设备及介质 |
| CN115543667A (zh) * | 2022-09-19 | 2022-12-30 | 成都飞机工业（集团）有限责任公司 | 一种piu子系统的参数关联性分析方法、装置、设备及介质 |
| CN115878421A (zh) * | 2022-12-09 | 2023-03-31 | 国网湖北省电力有限公司信息通信公司 | 一种基于日志时序关联特征挖掘的数据中心设备级故障预测方法、系统及介质 |
| CN116150636A (zh) * | 2023-04-18 | 2023-05-23 | 苏州上舜精密工业科技有限公司 | 一种传动模组的故障监测方法及系统 |
-
2020
- 2020-10-10 CN CN202011080651.8A patent/CN114327964A/zh active Pending
Cited By (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN115174350A (zh) * | 2022-06-30 | 2022-10-11 | 济南浪潮数据技术有限公司 | 一种运维告警方法、装置、设备及介质 |
| CN115174350B (zh) * | 2022-06-30 | 2024-07-02 | 济南浪潮数据技术有限公司 | 一种运维告警方法、装置、设备及介质 |
| CN115543667A (zh) * | 2022-09-19 | 2022-12-30 | 成都飞机工业（集团）有限责任公司 | 一种piu子系统的参数关联性分析方法、装置、设备及介质 |
| CN115543667B (zh) * | 2022-09-19 | 2024-04-16 | 成都飞机工业（集团）有限责任公司 | 一种piu子系统的参数关联性分析方法、装置、设备及介质 |
| CN115878421A (zh) * | 2022-12-09 | 2023-03-31 | 国网湖北省电力有限公司信息通信公司 | 一种基于日志时序关联特征挖掘的数据中心设备级故障预测方法、系统及介质 |
| CN115878421B (zh) * | 2022-12-09 | 2023-11-14 | 国网湖北省电力有限公司信息通信公司 | 一种数据中心设备级故障预测方法、系统及介质 |
| CN116150636A (zh) * | 2023-04-18 | 2023-05-23 | 苏州上舜精密工业科技有限公司 | 一种传动模组的故障监测方法及系统 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN108415789B (zh) | 面向大规模混合异构存储系统的节点故障预测系统及方法 | |
| CN110928718B (zh) | 一种基于关联分析的异常处理方法、系统、终端及介质 | |
| CN114327964A (zh) | 业务系统的故障原因处理方法、装置、设备及存储介质 | |
| US9832280B2 (en) | User profile configuring method and device | |
| CN103513983B (zh) | 用于预测性警报阈值确定工具的方法和系统 | |
| CN111506478A (zh) | 基于人工智能实现告警管理控制的方法 | |
| CN111930547A (zh) | 一种故障定位方法、装置及存储介质 | |
| US20160055044A1 (en) | Fault analysis method, fault analysis system, and storage medium | |
| CN112308126A (zh) | 故障识别模型训练方法、故障识别方法、装置及电子设备 | |
| CN112988509B (zh) | 一种告警消息过滤方法、装置、电子设备及存储介质 | |
| CN117971606B (zh) | 基于ElasticSearch的日志管理系统及方法 | |
| CN113821418B (zh) | 故障根因分析方法及装置、存储介质和电子设备 | |
| CN112306820B (zh) | 一种日志运维根因分析方法、装置、电子设备及存储介质 | |
| CN113537337A (zh) | 训练方法、异常检测方法、装置、设备和存储介质 | |
| CN111949646A (zh) | 基于大数据的设备运行状况分析方法、装置、设备及介质 | |
| CN112148578A (zh) | 基于机器学习的it故障缺陷预测方法 | |
| CN112433874A (zh) | 一种故障定位方法、系统、电子设备及存储介质 | |
| CN113515434B (zh) | 异常分类方法、装置、异常分类设备及存储介质 | |
| CN111581056B (zh) | 基于人工智能的软件工程数据库维护与预警系统 | |
| CN114461644A (zh) | 一种数据采集方法、装置、电子设备及存储介质 | |
| CN115640300A (zh) | 一种大数据管理方法、系统、电子设备和存储介质 | |
| CN113220551A (zh) | 指标趋势预测及预警方法、装置、电子设备及存储介质 | |
| CN116866152A (zh) | 风险操作管控方法、装置、电子设备及存储介质 | |
| CN115495587A (zh) | 一种基于知识图谱的告警分析方法及装置 | |
| CN113778792B (zh) | 一种it设备的告警归类方法及系统 |
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 |