CN109905436A - 根因事件的确定方法、装置及存储介质 - Google Patents
根因事件的确定方法、装置及存储介质 Download PDFInfo
- Publication number
- CN109905436A CN109905436A CN201711299205.4A CN201711299205A CN109905436A CN 109905436 A CN109905436 A CN 109905436A CN 201711299205 A CN201711299205 A CN 201711299205A CN 109905436 A CN109905436 A CN 109905436A
- Authority
- CN
- China
- Prior art keywords
- event
- notification event
- service
- specified
- cluster
- 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
Landscapes
- Debugging And Monitoring (AREA)
Abstract
本申请公开了一种根因事件的确定方法、装置及存储介质，属于信息处理领域。所述方法包括：通过分布式应用系统中参与调用的多个服务分别绑定的代理程序，在该多个服务的字节码中分别插入指定拦截代码；根据该多个服务的字节码中插入的该指定拦截代码，分别获取该多个服务的调用日志；根据获取的调用日志确定该分布式应用系统的应用拓扑；根据该应用拓扑和存储的该分布式应用系统的事件关联规则，从指定通知事件集合中确定根因事件。本申请可以通过各个服务分别绑定的代理程序直接获取各个服务的调用日志，简化了获取调用日志的方式，且绑定的代理程序具有普适性，具有无业务浸入、易部署的优点。
Description
技术领域
本申请涉及信息处理领域，特别涉及一种根因事件的确定方法、装置及存储介质。
背景技术
目前，应用云化部署已经成为业界趋势。应用云化部署是指在数据中心中采用分布式架构托管应用，使得一个应用通过多个服务的交互来实现，这种应用称为分布式应用，多个分布式应用的服务构成的系统称为分布式应用系统。服务是指分布式应用包括的一个功能模块，不同的服务具有不同的业务逻辑。托管分布式应用的数据中心可以包括多个网络设备和一个管理设备，每个网络设备根据分布式应用的部署能够运行至少一个服务，管理设备用于对该多个网络设备中运行的服务进行管理。实际应用中，为了对每个服务的状态进行监控，当每个服务的服务质量下降时，将会向管理设备上报通知事件。由于分布式应用的一个业务通常由多个服务参与，当其中一个服务出现故障时，将导致其他关联服务也产生通知事件，因此对于分布式应用系统产生的大量通知事件来说，需要从中确定根因事件，以便快速定位故障。根因事件是指故障导致的多个通知事件中引起其他衍生事件的通知事件。
相关技术中，提供了一种根因事件的确定方法，包括：在分布式应用系统包括的网络设备的操作系统中安装诸如脚本的拦截采集装置，通过拦截采集装置拦截操作系统层的调用信息，从拦截的调用信息中筛选出分布式应用系统的各个服务之间的调用信息，根据各个服务之间的调用信息，确定分布式应用系统的应用拓扑，该应用拓扑用于指示分布式应用系统中各个服务之间的调用关系。然后根据该应用拓扑和人工设置的事件关联规则，从该分布式应用系统在一个时间段内产生的多个通知事件中确定根因事件，该事件关联规则用于指示该分布式应用系统产生的通知事件之间的关联关系。
由于从操作系统层拦截的调用信息不仅包括分布式应用系统的服务之间的调用信息，还包括诸如管理面维护操作的调用信息等的冗余信息，因此在拦截调用信息之后，还需要从拦截的调用信息中过滤出冗余信息，且过滤方法繁琐复杂，需要结合分布式应用和维护操作的具体实施方式来实现，因此无法灵活适用于应用云化部署下的应用变更，实施成本高且效率较低。
发明内容
为了解决相关技术中存在的对拦截的调用信息需要进行过滤且过滤方法繁琐复杂，实施成本高且效率较低的问题，本申请提供了一种根因事件的确定方法、装置及存储介质。所述技术方案如下：
第一方面，提供了一种根因事件的确定方法，所述方法包括：
通过分布式应用系统中参与调用的多个服务分别绑定的代理程序，在所述多个服务的字节码中分别插入指定拦截代码，所述多个服务绑定的代理程序相同，且每个代理程序是通过软件开发工具包的Instrumentation功能与对应服务进行绑定；
通过所述多个服务分别绑定的代理程序，根据所述多个服务的字节码中插入的所述指定拦截代码，分别获取所述多个服务的调用日志；
根据获取的调用日志确定所述分布式应用系统的应用拓扑，所述应用拓扑用于指示所述多个服务之间的调用关系；
根据所述应用拓扑和存储的所述分布式应用系统的事件关联规则，从指定通知事件集合中确定根因事件，所述分布式应用系统的事件关联规则用于指示所述分布式应用系统产生的通知事件之间的关联关系，所述指定通知事件集合是指所述分布式应用系统在第一预设时间段内产生的通知事件的集合。
其中，该分布式应用系统中的每个服务均绑定有代理程序，代理程序能够直接获取对应服务的调用日志，且每个服务绑定的代理程序均相同。由于可以根据各个服务分别绑定的代理程序，直接获取各个服务的调用日志，因此避免了从操作系统层拦截调用信息时对调用信息的过滤操作，简化了获取调用日志的方式，实现了轻量级调用日志采集，而且各个服务绑定的代理程序均相同即具有普适性，在部署时无需考虑各个服务的具体业务逻辑，具有无业务浸入、易部署的优点。
在具体实现中，所述指定拦截代码为非功能性打印语句；
所述通过分布式应用系统中参与调用的多个服务分别绑定的代理程序，在所述多个服务的字节码中分别插入指定拦截代码，包括：
通过所述多个服务分别绑定的代理程序，在所述多个服务的网络通讯包中分别插入所述非功能打印语句；
所述通过所述多个服务分别绑定的代理程序，根据所述多个服务的字节码中插入的所述指定拦截代码，分别获取所述多个服务的调用日志，包括：
通过所述多个服务分别绑定的代理程序，根据在所述多个服务的网络通讯包中插入的所述非功能打印语句，分别获取所述多个服务的网络通讯包中的指定类和指定方法，所述指定类是指用于进行通讯的类，所述指定方法包括发起通讯方法、接收通讯方法、读方法和写方法；
根据从所述多个服务的网络通讯包中获取的指定类和指定方法，确定所述多个服务的调用日志。
其中，网络通讯包是指对应服务的字节码中用于与其他服务进行通讯时所使用的网络包，能够反映对应服务的调用操作，具体可以为java.nio或java.net网络通讯包。
其中，发起通讯方法和接收通讯方法能够指示对应服务与其他服务之间的通讯操作即调用操作，且发起通讯方法是指包括connect字段的方法，能够指示对应服务是发起调用的客户端，接收通讯方法是指包括accept字段的方法，能够指示对应服务是被调用的服务端，从而能够根据获取的方法确定此次调用的调用主体和调用方向。
其中，读方法和写方法能够指示在各个服务之间的通讯链接建立之后，各个已建立的通讯链路是否还存活，即是否还有消息传输，这种拦截读方法和写方法的操作属于一种检测心跳的机制，以便根据新传输的消息及时更新已建立的调用链路的调用时间戳。
本申请实施例中，可以通过代理程序在对应服务的网络通讯包中插入非功能打印语句来获取网络通讯包所使用的指定类和指定方法，通过获取的指定类和指定方法确定调用日志。由于插入的拦截代码为非功能打印语句，因此能够避免对服务具体业务功能的影响。
在具体实现中，所述根据获取的调用日志确定所述分布式应用系统的应用拓扑，包括：
根据获取的调用日志确定所述多个服务之间的调用主体和调用方向；
根据所述多个服务之间的调用主体和调用方向，确定所述多个服务之间的调用关系；
确定所述多个服务中每个服务所在的集群(cluster)，所述集群用于指示属于同一软件包的服务；
根据每个服务所在的集群，将所述多个服务之间的调用关系转换为集群之间的调用关系；
根据所述集群之间的调用关系，确定所述分布式应用系统的应用拓扑。
本申请实施例中，通过将多个服务之间的调用关系转换为集群之间的调用关系，根据集群之间的调用关系确定分布式应用系统的应用拓扑，能够使得应用拓扑更加直观和清晰。
在具体实现中，所述根据所述应用拓扑和存储的所述分布式应用系统的事件关联规则，从指定通知事件集合中确定根因事件之前，还包括：
获取所述分布式应用系统产生的多个历史通知事件；
根据所述多个历史通知事件，通过频繁模式挖掘算法确定所述分布式应用系统的事件关联规则。
本申请实施例中，通过采用频繁模式挖掘算法对多个历史通知事件进行频繁模式挖掘，能够通过对历史通知事件的数据挖掘自动学习生成该分布式应用系统的事件关联规则，避免了人工配置事件关联规则时对领域知识的积累，灵活性和准确性较高。
在具体实现中，所述根据所述多个历史通知事件，通过频繁模式挖掘算法确定所述分布式应用系统的事件关联规则，包括：
对所述多个历史通知事件进行预处理；
采用所述频繁模式挖掘算法，从预处理后的所述多个历史通知事件中确定多个频繁项集，频繁项集是指支持度大于或等于预设支持度阈值的项集，所述项集是指在第二预设时间段内产生的历史通知事件的集合，所述支持度用于指示对应项集中包括的通知事件同时发生的概率；
根据所述多个频繁项集和所述多个频繁项集的置信度，从所述多个频繁项集中确定多个关联事件集合，所述置信度用于指示对应频繁项集包括的通知事件相互关联的程度；
将所述多个关联事件集合确定为所述分布式应用系统的事件关联规则。
在具体实现中，所述对所述多个历史通知事件进行预处理，包括：
将所述多个历史通知事件中同一服务在同一第三预设时间段内产生的类型相同的通知事件合并为一个历史通知事件，并将合并后的历史通知事件的时间戳设置为所述类型相同的通知事件的时间戳中最早的时间戳，时间戳用于指示对应历史通知事件的生成时间；
和/或，
从所述多个历史通知事件中删除背景通知事件，所述背景通知事件是指在所述多个历史通知事件中发生概率大于预设概率阈值且与其他通知事件没有逻辑关系的通知事件。
本申请实施例中，通过对多个历史通知事件进行预处理，能够从该多个历史通知事件中清理掉影响事件关联规则挖掘的通知事件，以提高确定事件关联规则的准确度。
在具体实现中，所述根据所述应用拓扑和存储的所述分布式应用系统的事件关联规则，从指定通知事件集合中确定根因事件，包括：
获取所述分布式应用系统的部署信息，所述部署信息包括服务与集群的对应关系以及集群与解决方案(project)的对应关系，所述解决方案用于指示属于同一业务的集群；
根据所述部署信息，对所述指定通知事件集合包括的多个通知事件进行聚合；
根据所述应用拓扑和存储的所述分布式应用系统的事件关联规则，从聚合后的所述多个通知事件中确定所述根因事件。
在具体实现中，所述根据所述部署信息，对所述指定通知事件集合包括的多个通知事件进行聚合，包括：
根据所述多个通知事件中每个通知事件的来源服务，以及所述部署信息包括的所述服务与集群的对应关系，对所述多个通知事件进行聚合，得到至少一个集群对应的通知事件；
根据所述部署信息包括的所述集群与解决方案的对应关系，对所述至少一个集群对应的通知事件进行聚合，得到至少一个解决方案对应的通知事件；
所述根据所述应用拓扑和存储的所述分布式应用系统的事件关联规则，从聚合后的所述多个通知事件中确定所述根因事件，包括：
从所述应用拓扑中确定所述至少一个解决方案的集群调用拓扑；
从所述分布式应用系统的事件关联规则中确定所述至少一个解决方案的事件关联规则；
根据各个解决方案的集群调用拓扑和各个解决方案的事件关联规则，从各个解决方案对应的通知事件中确定所述根因事件。
在具体实现中，所述根据各个解决方案的集群调用拓扑和各个解决方案的事件关联规则，从各个解决方案对应的通知事件中确定所述根因事件，包括：
根据指定解决方案对应的通知事件的时间戳和预设长度的时间窗口，对所述指定解决方案对应的通知事件进行分组，得到至少一个时间窗口对应的通知事件，所述指定解决方案为所述至少一个解决方案中的任一解决方案；
将指定时间窗口对应的通知事件，按照所述指定解决方案的事件关联规则进行分组，得到至少一个关联事件组，所述指定时间窗口为所述至少一个时间窗口中的任一时间窗口；
根据各个关联事件组中每个通知事件的来源服务，确定每个通知事件的优先级；
将各个关联事件组中优先级最高的通知事件，确定为各个关联事件组的根因事件。
在具体实现中，所述根据各个关联事件组中每个通知事件的来源服务，确定每个通知事件的优先级，包括：
根据所述指定解决方案的集群调用拓扑，确定各个关联事件组中每个通知事件的来源服务所在集群的拓扑优先级；
将各个关联事件组中每个通知事件的来源服务所在集群的拓扑优先级，确定为各个关联事件组中每个通知事件的优先级。
第二方面，提供了一种根因事件的确定装置，所述根因事件的确定装置具有实现上述第一方面中根因事件的确定方法行为的功能。所述根因事件的确定装置包括至少一个模块，该至少一个模块用于实现上述第一方面所提供的根因事件的确定方法。
第三方面，提供了一种根因事件的确定装置，所述根因事件的确定装置的结构中包括处理器和存储器，所述存储器用于存储支持根因事件的确定装置执行上述第一方面所提供的根因事件的确定方法的程序，以及存储用于实现上述第一方面所提供的根因事件的确定方法所涉及的数据。所述处理器被配置为用于执行所述存储器中存储的程序。所述存储设备的操作装置还可以包括通信总线，该通信总线用于该处理器与存储器之间建立连接。
第四方面，提供了一种计算机可读存储介质，所述计算机可读存储介质中存储有指令，当其在计算机上运行时，使得计算机执行上述第一方面所述的根因事件的确定方法。
第五方面，提供了一种包含指令的计算机程序产品，当其在计算机上运行时，使得计算机执行上述第一方面所述的根因事件的确定方法。
上述第二方面、第三方面、第四方面和第五方面所获得的技术效果与第一方面中对应的技术手段获得的技术效果近似，在这里不再赘述。
本申请提供的技术方案带来的有益效果是：
本申请中，可以通过分布式应用系统中参与调用的多个服务分别绑定的相同的代理程序，在多个服务的字节码中分别插入指定拦截代码，并根据在该多个服务的字节码中插入的指定拦截代码，通过绑定的代理程序分别获取该多个服务的调用日志，以便根据获取的调用日志确定该分布式应用系统的应用拓扑，根据该应用拓扑和存储的事件关联规则从多个通知事件中确定根因事件。由于可以根据各个服务分别绑定的代理程序，直接获取各个服务的调用日志，因此避免了从操作系统层拦截调用信息时对调用信息的过滤操作，简化了获取调用日志的方式，实现了轻量级调用日志采集，而且各个服务绑定的代理程序均相同即具有普适性，在部署时无需考虑各个服务的具体业务逻辑，具有无业务浸入、易部署的优点。
附图说明
图1A是本申请实施例提供的一种根因事件的确定系统100的架构图；
图1B是本申请实施例提供的另一种根因事件的确定系统100的架构图；
图1C是本申请实施例提供的一种管理设备20的结构示意图；
图1D是本申请实施例提供的一种根因事件的确定方法的流程图；
图1E是本申请实施例提供的一种时间窗口和滑动步长的示意图；
图2是本申请实施例提供的一种根因事件的确定装置的结构示意图。
具体实施方式
为使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请实施方式作进一步地详细描述。
在对本申请实施例进行详细介绍之前，首先对本申请实施例涉及的名词进行解释。
通知事件
通知事件是指在根据计算机和网络的应用系统中，用于标识错误、警告、故障等应用系统状态或状态变更的通知消息体。
根因事件
根因事件是指在某一类应用系统故障导致的多个通知事件中，引起其它衍生事件的一个通知事件。
应用拓扑
应用拓扑用于指示分布式应用系统中各个服务之间的调用关系，具体可以为用于描述分布式应用系统中各个服务之间的调用关系或者各个集群之间的调用关系的图谱。
频繁模式(Frequent Pattern)挖掘算法
频繁模式挖掘算法并不是一个具体的算法，而是指一系列挖掘算法，该类算法的主要目的是从大量数据中找出频繁出现的模式。频繁模式挖掘算法中最经典的算法是Apriori算法(一种频繁模式挖掘算法，后人对其进行效率上的改进，进一步提出了升级频繁模式挖掘(Frequent Pattern Growth，FP-growth)算法。
关联事件
关联事件是分布式应用系统中产生的有内在关系的通知事件，关联事件之间可能是依赖关系、调用关系等等。由于关联事件之间有某种内在关系，所以往往会同时出现。本申请中，关联事件可以为通过频繁模式挖掘算法从大量历史通知事件中挖掘出的具有关联关系的通知事件集合。
其次，对本申请实施例的系统架构进行介绍。
图1A是本申请实施例提供的一种根因事件的确定系统100的架构图，如图1所示，该系统100包括分布式应用系统10和管理设备20。
其中，分布式应用系统10包括多个服务11，这多个服务11可以是一个或多个分布式应用所包括的服务，且各个服务11之间可以根据业务需求相互调用，管理设备20用于对该分布式应用系统10中的多个服务11进行管理。
分布式应用系统10中的每个服务11均绑定有代理程序12，且各个服务11所绑定的代理程序12均相同。代理程序12用于获取对应服务11的调用日志，是预先通过软件开发工具包的Instrumentation功能与对应服务11进行绑定。实际应用中，代理程序12可以在对应服务11的字节码中插入拦截代码，并通过插入的拦截代码获取对应服务11的调用日志。
管理设备20用于通过分布式应用系统10中参与调用的多个服务11分别绑定的代理程序，在该多个服务11的字节码中分别插入指定拦截代码，通过该多个服务11分别绑定的代理程序，根据该多个服务11的字节码中插入的指定拦截代码，分别获取该多个服务11的调用日志；根据获取的调用日志确定该分布式应用系统10的应用拓扑，该应用拓扑用于指示该多个服务11之间的调用关系；根据该应用拓扑和存储的分布式应用系统10的事件关联规则，从指定通知事件集合中确定根因事件，该分布式应用系统10的事件关联规则用于指示该分布式应用系统10产生的通知事件之间的关联关系，该指定通知事件集合是指该分布式应用系统在第一预设时间段内产生的通知事件的集合。
进一步地，管理设备20还可以用于获取该分布式应用系统10产生的多个历史通知事件，并可以根据该多个历史通知事件，通过频繁模式挖掘算法确定该分布式应用系统10的事件关联规则。
需要说明的是，该系统100可以为数据中心，该数据中心可以包括多个网络设备和1个管理设备。图1A中的多个服务11可以根据分布式应用的部署运行在该多个网络设备中，每个网络设备能够运行至少一个服务11。实际应用中，每个网络设备可以根据安装的虚拟机运行至少一个服务11，且每个网络设备可以安装1个或多个虚拟机，每个虚拟机能够运行1个或多个服务11。接下来将以每个虚拟机运行1个服务11为例，对该系统100进行介绍。
图1B是本申请实施例提供的另一种根因事件的确定系统100的架构图，如图1B所示，该系统100包括分布式应用系统10和管理设备20。
其中，分布式应用系统10包括多个虚拟机(Virtual Machine，VM)13，每个VM13用于运行一个服务11以及与该服务11绑定的代理程序12。代理程序12用于获取对应服务11的调用日志，并可以将获取调用日志存储在本地磁盘中，以便虚拟机13将存储的调用日志发送给管理设备20。
其中，管理设备20可以包括拓扑服务(Topology Service)模块21、事件关联规则分析(Event Correlation Analysis)模块22、根因事件分析(Root Event Analysis)模块23和入口服务(Expert Service)模块24。拓扑服务模块21用于根据分布式应用系统10中参与调用的多个服务11分别绑定的代理程序，获取多个服务11的调用日志，并根据获取的调用日志确定该分布式应用系统10的调用拓扑。事件关联规则分析模块22用于根据该分布式应用系统10产生的多个历史通知事件，通过频繁模式挖掘算法确定该分布式应用系统10的事件关联规则。根因事件分析模块23用于根据应用拓扑和存储的该分布式应用系统10的事件关联规则，从指定通知事件集合中确定根因事件。入口服务模块24是一个接口装置，用于当该分布式应用系统10是新部署的应用系统、不存在历史通知事件时，辅助人工配置事件关联规制，并将人工配置的事件关联规制输入到管理设备20中。
进一步地，参见图1B，该系统100还可以包括平台即服务(Platform as aService，PAAS)30，用于进行分布式应用系统10的部署、启动和停止等。具体地，该PAAS还可以将分布式应用系统10的部署信息发送给管理设备20，以便根因事件分析模块23根据应用拓扑、存储的该分布式应用系统10的事件关联规则和部署信息，从指定通知事件集合中确定根因事件。其中，部署信息可以包括各个服务的属性信息、服务的端口号、服务所在的主机信息、服务的服务标识、逻辑分组、软件版本或软件开发工具包(Software DevelopmentKit，SDK)版本等。
进一步地，该管理设备20还可以包括性能服务模块和事件服务模块(图1B未示出)，性能服务模块用于获取该多个服务11的性能指标，根据各个服务11的性能指标生成各个服务的通知事件，并将生成的通知事件输入给事件服务模块。另外，性能服务模块还用于对该多个服务11的性能指标的存储、展示和查询。事件服务模块用于接收、存储或查询该多个服务11的通知事件。
接下来将结合图1A或图1B对本申请实施例涉及的管理设备20的结构进行介绍。
图1C是本申请实施例提供的一种管理设备20的结构示意图，参见图1C，该管理设备20主要包括有发射器210、接收器220、存储器230、处理器240以及通信总线250。本领域技术人员可以理解，图1C中示出的管理设备20的结构并不构成对管理设备20的限定，实际应用中，管理设备20可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置，本申请实施例对此不做限定。
其中，该发射器210和接收器220用于与其他设备进行通信，比如可以通过接收器220接收各个服务上报的调用日志和通知事件。该存储器230可以用于存储数据，比如可以用于存储分布式应用系统的应用拓扑和事件关联规则，并且，该存储器230也可以用于存储用于执行本申请实施例提供的根因事件的确定方法的一个或多个运行程序和/或模块。
其中，该处理器240是管理设备20的控制中心，该处理器240可以是一个通用中央处理器(Central Processing Unit，CPU)，微处理器，特定应用集成电路(Application-Specific Integrated Circuit，ASIC)，或一个或多个用于控制本申请实施例方案程序执行的集成电路。该处理器240可以通过运行或执行存储在存储器230内的软件程序和/或模块，以及调用存储在存储器230内的数据，来实现下文实施例所提供的根因事件的确定方法。
其中，该通信总线250可包括通路，在上述处理器240和存储器230之间传送信息。
接下来将对本申请实施例提供的一种根因事件的确定方法进行详细说明。
图1D是本申请实施例提供的一种根因事件的确定方法的流程图，该方法可以应用于上述图1A、图1B或图1C所述的管理设备中，如图1D所示，该方法包括如下步骤：
步骤101：通过分布式应用系统中参与调用的多个服务分别绑定的代理程序，在该多个服务的字节码中分别插入指定拦截代码。
需要说明的是，本申请实施例中，该分布式应用系统中的每个服务均绑定有代理程序，代理程序用于在对应服务运行的过程中动态获取对应服务的调用日志。而且，该分布式应用系统中各个服务绑定的代理程序均相同，即该代理程序具有普适性，无需根据各个服务的具体业务逻辑进行针对性的部署，具有无业务浸入和易部署的优点。
实际应用中，每个服务的代理程序可以通过软件开发工具包(SoftwareDevelopment Kit，SDK)的Instrumentation功能与对应服务进行绑定。利用SDK的Instrumentation功能，开发人员可以构建一个独立于应用程序的代理程序，用来对对应服务进行监控。Instrumentation功能的原理是在应用运行时动态新增非功能字节码，实现应用动态数据的获取，如日志、时间、事务或性能数据的动态生成。
以该分布式应用系统中的应用为Java应用为例，每个服务的代理程序可以通过Java SDK提供的Instrumentation功能与对应服务进行绑定。例如，开发者可以利用JavaSDK提供的java.lang.instrumentation做动态的代码Instrumentation的能力，构建一个独立于对应服务的代理程序Java Agent，用来对对应服务或对应虚拟机进行监控。
本申请实施例中，代理程序可以在对应服务的字节码中动态插入拦截应用调用的业务逻辑，而无需根据对应服务的具体业务进行插入，实现了调用日志的无业务浸入采集。具体地，代理程序可以在对应服务的字节码中插入指定拦截代码，以通过插入指定拦截代码拦截对应服务的调用日志。
其中，字节码是指一种包含执行程序、由一序列op代码/数据对组成的二进制文件。字节码是一种中间码，它比机器码更抽象。
其中，该指定拦截代码为非功能字节码，能够避免对服务具体业务功能的影响。例如，该指定拦截代码可以为非功能性打印语句，可以通过在对应服务运行过程中，动态打印字节码中的关键信息的方式，来获取对应服务的调用日志。
具体地，当该指定拦截代码为非功能性打印语句时，通过分布式应用系统中参与调用的多个服务分别绑定的代理程序，在该多个服务的字节码中分别插入指定拦截代码包括：通过该多个服务分别绑定的代理程序，在该多个服务的网络通讯包中分别插入非功能打印语句。例如，代理程序可以在对应服务的网络通讯包的类和方法中插入非功能打印语句，以通过插入的非功能打印语句获取网络通讯包所使用的类和方法。
其中，网络通讯包是指对应服务的字节码中用于与其他服务进行通讯时所使用的网络包，能够反映对应服务与其他服务之间的调用操作。以该服务为Java应用的服务为例，该网络通讯包可以为java.nio或java.net网络通讯包。
步骤102：通过该多个服务分别绑定的代理程序，根据该多个服务的字节码中插入的该指定拦截代码，分别获取该多个服务的调用日志。
具体的，当代理程序通过在对应服务的网络通讯包中插入非功能打印语句来获取调用日志时，通过该多个服务分别绑定的代理程序，根据该多个服务的字节码中插入的该指定拦截代码，分别获取该多个服务的调用日志包括：通过该多个服务分别绑定的代理程序，根据在该多个服务的网络通讯包中插入的非功能打印语句，分别获取该多个服务的网络通讯包中的指定类和指定方法(method)，该指定类是指用于进行通讯的类，该指定方法包括发起通讯方法、接收通讯方法、读(read)方法和写(write)方法；根据从该多个服务的网络通讯包中获取的指定类和指定方法，确定该多个服务的调用日志。
其中，发起通讯方法和接收通讯方法能够指示对应服务与其他服务之间的通讯操作即调用操作，且发起通讯方法是指包括connect字段的方法，能够指示对应服务是发起调用的客户端，接收通讯方法是指包括accept字段的方法，能够指示对应服务是被调用的服务端，从而能够根据获取的方法确定此次调用的调用主体和调用方向。
其中，读方法和写方法能够指示在各个服务之间的通讯链接建立之后，各个已建立的通讯链路是否还存活，即是否还有消息传输，这种拦截读方法和写方法的操作属于一种检测心跳的机制，以便根据新传输的消息及时更新已建立的调用链路的调用时间戳。
具体地，对于各服务之间的通讯采用短链接的场景，即每次与其他服务进行通讯都需要建立握手的场景中，可以根据在网络通讯包中插入的非功能打印语句，拦截指定类的发起通讯方法和接收通讯方法。
对于短链接的场景，java.nio网络通讯包括中的类和方法包括：
sun.nio.ch.SocketChannelImpl.finishConnect
sun.nio.ch.ServerSocketChannelImpl.accept
其中，SocketChannelImpl和ServerSocketChannelImpl属于指定类，finishConnect为通讯发起方法，用于指示对应服务为通讯发起方即客户端，accept为通讯接收方法，用于指示对应服务为通讯接收方即服务端。
java.net网络通讯包括中的类和方法包括：
java.net.ServerSocket.accept
java.net.Socket.connect
其中，ServerSocket和Socket属于指定类，accept为通讯接收方法，用于指示对应服务为通讯接收方，connect为通讯发起方法，用于指示对应服务为通讯发起方。
对于各服务之间的通讯采用长链接的场景，即对应服务与其他服务一旦握手成功并成功建立通讯链接之后，将不再有链接动作，后续的消息传输可以重用已建立的通讯链接，且后续消息在通讯链路的传输会经过读方法和写方法的场景，可以根据在网络通讯包中插入的非功能打印语句，拦截指定类的发起通讯方法、接收通讯方法、读方法和写方法。
对于长链接的场景，java.nio网络通讯包括中的类和方法还包括：
sun.nio.ch.SocketChannelImpl.read
sun.nio.ch.SocketChannelImpl.write
对于长链接的场景，java.net网络通讯包括中的类和方法还包括：
Java.net.Socket.read
Java.net.Socket.write
需要说明的是，根据从该多个服务的网络通讯包中获取的指定类和指定方法确定的调用日志可以包括时间戳、获取的指定方法、客户端的IP地址和端口号、服务端的IP地址和端口号。其中，时间戳用于指示调用日志的生成时间，指定方法用于指示对应服务是客户端还是服务端。进一步地，调用日志还可以包括服务标识，该服务标识用于唯一标识对应服务。
例如，调用日志的格式可以为：
Timestamp|srcDN|srcPort|srcIP|destIP|destport|method
其中，Timestamp为时间戳，srcDN为服务标识，srcPort为客户端端口号，srcPort为客户端IP地址，destIP为服务端IP地址，destport为服务端端口号，method为拦截的方法，能够指示该调用日志是从哪个方法中拦截得到。
示例的，按照上述调用日志的格式，该多个服务中某个服务的调用日志可以为：
2017-03-31 16:02:07|a21da5d153a4a9626425e|10.33.219.109|32165|10.33.203.105|1998|sun.nio.ch.SocketChannelImpl.finishConnect。
实际应用中，可以在代理程序中配置拦截的类及其方法。
进一步地，每个服务的代理程序从对应服务的字节码中拦截到调用日志之后，可以先将拦截到的调用日志存储在本地，以便对应服务所在的虚拟机获取本地存储的调用日志并发送给管理设备。具体地，对应服务所在的虚拟机可以通过安装的发送程序，获取本地存储的调用日志，并将获取的调用日志发送给管理设备。
进一步地，代理程序还可以具有调用日志的流控和去重功能。代理程序从对应服务的字节码中拦截到调用日志之后，还可以先对拦截到的调用日志进行去重处理，然后再将去重处理后的调用日志存储在本地。具体地，代理程序可以先将拦截到调用日志缓存在预设长度的队列中，该队列可以将指定字段相同的调用日志合并为一个调用日志并输出。其中，该指定字段可以包括服务标识、服务端IP地址和服务端端口号，或者该指定字段包括客户端IP地址、服务端IP地址和服务端端口号。
进一步地，考虑到经过read方法和write方法的消息较多，特别是大访问量的分布式应用，所以还可以仅对通过read方法和write方法拦截的调用日志进行去重处理，以减小数据传输量和管理设备的计算量。
步骤103：根据获取的调用日志确定该分布式应用系统的应用拓扑，该应用拓扑用于指示该多个服务之间的调用关系。
具体地，根据获取的调用日志确定该分布式应用系统的应用拓扑可以包括以下两种方式：
第一种实现方式：根据获取的调用日志确定该多个服务之间的调用主体和调用方向；根据该多个服务之间的调用主体和调用方向，确定该多个服务之间的调用关系；根据该多个服务之间的调用关系，确定该分布式应用系统的应用拓扑。其中，该分布式应用的调用拓扑用于描述服务之间的调用关系。
例如，可以根据该多个服务之间的调用主体和调用方向，确定该多个服务之间的调用关系图谱，将该多个服务之间的调用关系图谱作为该分布式应用系统的应用拓扑。
第二种实现方式：根据获取的调用日志确定该多个服务之间的调用主体和调用方向；根据该多个服务之间的调用主体和调用方向，确定该多个服务之间的调用关系；确定该多个服务中每个服务所在的集群，该集群用于指示属于同一软件包的服务；根据每个服务所在的集群，将该多个服务之间的调用关系转换为集群之间的调用关系；根据该集群之间的调用关系，确定该分布式应用系统的应用拓扑。其中，该分布式应用系统的应用拓扑用于描述包括服务的集群之间的调用关系。
例如，可以根据集群之间的调用关系，画出集群之间的调用关系图谱，将该集群之间的调用关系图谱作为该分布式应用系统的应用拓扑。
其中，可以根据存储的部署信息，确定该多个服务中每个服务所在的集群，该部署信息可以包括服务与集群的对应关系，即每个服务属于哪个集群。实际应用中，该部署信息可以从上述图1B所述的PAAS中获取得到。
步骤104：根据该应用拓扑和存储的该分布式应用系统的事件关联规则，从指定通知事件集合中确定根因事件。
其中，该分布式应用系统的事件关联规则可以预先根据该分布式应用系统产生的多个历史通知事件，通过频繁模式挖掘算法确定得到，也可以由人工配置。
实际应用中，当该分布式应用系统存在历史通知事件或者存在的历史通知事件的数量大于或等于预设阈值时，可以根据该分布式应用系统产生的多个历史通知事件，通过频繁模式挖掘算法确定该分布式应用系统的事件关联规则，并将该分布式应用系统的事件关联规则存储在本地；当该分布式应用系统为新部署的应用系统、不存在历史通知事件，或者当该分布式应用系统存在的历史通知事件的数量小于预设阈值时，可以通过人工配置该分布式应用系统的事件关联规则。
具体地，在步骤103之前，可以采用以下两种方式确定分布式应用系统的事件关联规则：
第一种实现方式：获取该分布式应用系统产生的多个历史通知事件；根据该多个历史通知事件，通过频繁模式挖掘算法确定该分布式应用系统的事件关联规则。
其中，根据该多个历史通知事件，通过频繁模式挖掘算法确定该分布式应用系统的事件关联规则可以包括如下几个步骤：
1)对该多个历史通知事件进行预处理。
预处理是指从该多个历史通知事件中清理掉影响事件关联规则挖掘的通知事件，以提高确定事件关联规则的准确度。
本申请实施例中，可以采用对历史通知事件进行合并或删除背景事件的方式，对该多个历史通知事件进行预处理。具体地，可以将该多个历史通知事件中同一服务在同一第三预设时间段内产生的类型相同的通知事件合并为一个历史通知事件，并将合并后的历史通知事件的时间戳设置为该类型相同的通知事件的时间戳中最早的时间戳，时间戳用于指示对应历史通知事件的生成时间；和/或，从该多个历史通知事件中删除背景通知事件，该背景通知事件是指在该多个历史通知事件中发生概率大于预设概率阈值且与其他通知事件没有逻辑关系的通知事件。
其中，该第三预设时间段可以预先设置得到，例如可以由技术人员预先设置。示例的，该第三预设时间段可以为1min、2min等。
2)采用该频繁模式挖掘算法，从预处理后的该多个历史通知事件中确定多个频繁项集。
其中，频繁项集是指支持度大于或等于预设支持度阈值的项集，项集是指在第二预设时间段内产生的历史通知事件的集合。其中，支持度用于指示对应项集中包括的通知事件同时发生的概率。例如，对于二项集A->B，该二项集的支持度可以用support(A->B)表示，且suppor(A->B)＝P(AB)，用于指示通知事件A和通知事件B同时发生的概率。
其中，该频繁模式挖掘算法可以包括Apriori算法、对Apriori算法进行优化得到的FP-growth算法、WINEMPI算法(一种频繁模式挖掘算法)或MINEPI算法(一种频繁模式挖掘算法)等。实际应用中，可以根据不同的情况应用不同的频繁模式挖掘算法。
具体地，对于预处理后的多个历史通知事件，可以先基于该多个历史通知事件的时间戳，按照时间窗口和滑动步长，对该多个历史通知事件进行分组，得到多个时间窗口对应的历史通知事件集合，并将该多个时间窗口对应的历史通知事件集合确定为多个项集。然后该多个项集中支持度大于或等于预设支持度阈值的项集确定为频繁项集。
其中，每个历史通知事件的时间戳用于指示对应历史通知事件的发生时间，每个时间窗口的长度等于该第二预设时长，该第二预设时长和该滑动步长可以预先设置，例如可以由技术人员根据需要预先设置。示例的，该第二预设时长可以为2min，该滑动步长可以为1min等。实际应用中，可以采用WINEMPI算或MINEPI算法对该多个历史通知事件进行分组。
例如，以该第二预设时长为2min，该滑动步长为1min为例，参见图1E，可以先以该多个历史通知事件中时间戳最早的历史通知事件的时间戳为起点，按照时间轴截取2min的时间窗口，得到第一时间窗口，并从该多个历史通知事件中选择时间戳在该第一时间窗口内的历史通知事件，将选择的历史通知事件确定为该第一时间窗口对应的历史通知事件集合，并将该第一时间窗口对应的历史通知事件集合确定为一个项集。然后将该第一时间窗口按照时间轴向后滑动1min，即以该第一时间窗口的起点之后的1min为起点，截取2min的时间窗口，得到第二时间窗口，并从该多个历史通知事件中选择时间戳在该第二时间窗口内的历史通知事件，将选择的历史通知事件确定为该第二时间窗口对应的历史通知事件集合，并将该第二时间窗口对应的历史通知事件集合确定为下一个项集。之后，重复将当前时间窗口按照滑动步长向后滑动，得到下一个时间窗口，并将下一个时间窗口对应的历史通知事件集合确定为下一个项集的方式，从该多个历史通知事件中确定多个项集。
实际应用中，可以通过迭代的方式找出该多个项集中的所有频繁项集。具体地，可以先从多个项集中选择1项集，并从选择的1项集中确定频繁1项集，然后基于频繁1项集选择包括频繁1项集2项集，并从选择的2项集中确定频繁2项集，然后按照这种根据频繁N-1项集确定频繁N项集的方式迭代执行，直至找出该多个项集中的所有频繁项集。其中N为正整数，N项集是指包括N个历史通知事件的集合。
进一步地，本申请实施例中，还可以将支持度大于或等于预设支持度阈值，且置信度大于或等于预设置信度阈值的项集，确定为频繁项集。其中，置信度用于指示对应频繁项集包括的通知事件相互关联的程度。例如，对于二项集A->B，该二项集的置信度可以用confidence(A->B)表示，且confidence(A->B)＝P(B|A)＝P(AB)/P(A)，用于指示通知事件A发生的基础上发生通知事件B的概率。
将该多个历史通知数据输入频繁模式挖掘算法模型，通过该频繁模式挖掘算法模型即可得到多个频繁项集。其中，频繁模式挖掘算法模型为采用频繁模式挖掘算法的模型，具体可以为大数据分析平台等。实际应用中，频繁项集的格式可以为{A，B}->{C}，用于指示通知事件A、B发生时，通知事件C也会发生。
3)根据该多个频繁项集和该多个频繁项集的置信度，从该多个频繁项集中确定多个关联事件集合，该置信度用于指示对应频繁项集包括的通知事件相互关联的程度。
具体地，根据该多个频繁项集的置信度可以从该多个频繁项集中确定所包括的各个通知事件相互关联的频繁项集，并将确定的频繁项集所包括的多个通知事件组成的集合确定为关联事件集合。
实际应用中，步骤3)用于对频繁模式挖掘算法挖掘得到的频繁项集进行进一步整理。频繁模式挖掘算法挖掘得到的频繁项集是按照先验概率的方式展示的，例如频繁项集{A}->{C}的置信度表示P(C|A)，即通知事件A出现时通知事件C出现的概率。但是由于P(C|A)＝1并不意味着P(A|C)＝1，所以要确定事件A和事件C之间的关联关系，需要P(C|A)＝1且P(A|C)＝1，即需要{A}->{C}和{C}->{A}同时存在。
其中，在对频繁项集进行进一步整理时，整理规则包括：如果有规则{A}->{C}且{C}->{A}，则A、C是关联事件，输出关联事件集合{A、C}；或者，如果有规则{A,B}->{C}且有{C}->{A}，则A、C是关联事件，输出关联事件集合{A、C}。
4)将该多个关联事件集合确定为该分布式应用系统的事件关联规则。
第一种实现方式中，分布式应用系统的事件关联规则能够通过对历史通知事件的数据挖掘自动学习生成，灵活性和准确性较高。
第二种实现方式：获取人工配置的分布式应用系统的事件关联规则。
其中，人工配置的该分布式应用系统的事件关联规则可以通过预先设置的接口装置获取得到，例如可以通过上述图1B中的入口服务模块24获取得到。实际应用中，该分布式应用系统的事件关联规则通常由领域专家制定。
但是，人工配置的事件关联规则需要领域专家的根据业务领域知识，结合业务场景梳理出各个通知事件的影响来制定，这主要依赖领域专家对领域知识的积累，因此制定的事件关联规则的准确性和普适性均有限制。
具体地，根据该应用拓扑和存储的该分布式应用系统的事件关联规则，从指定通知事件集合中确定根因事件包括以下两种实现方式：
第一种实现方式，按照该指定通知事件集合包括的多个通知事件的时间戳和预设长度的时间窗口，对该多个通知事件进行分组，得到至少一个时间窗口对应的通知事件；将指定时间窗口对应的通知事件，按照该分布式应用系统的事件关联规则进行分组，得到至少一个关联事件组，该指定时间窗口为该至少一个时间窗口中的任一时间窗口；根据各个关联事件组中每个通知事件的来源服务和该应用拓扑，确定每个通知事件的优先级；将各个关联事件组中优先级最高的通知事件，确定为各个关联事件组的根因事件。
具体地，可以基于该多个通知事件的时间戳，按照时间窗口和滑动步长，对该多个通知事件进行分组，得到至少一个时间窗口对应的通知事件。实际应用中，可以将该预设长度的时间窗口作为一个箱体，每隔一个滑动步长对最新的箱体中的通知事件进行一次计算，分析确定根因事件。其中，时间窗口为预设长度的时间窗口，该预设长度和滑动步长可以由技术人员预先设置得到。例如，该预设长度可以为10min，该滑动步长可以为10s等。
然后对于每个时间窗口对应的通知事件，均可以按照该分布式应用系统的事件关联规则进行分组，得到至少一个关联事件组，并分析确定每个关联事件组中的根因事件。例如，当分布式应用系统的事件关联规则中包括关联事件集合{A，B，C，D}时，则可以将指定时间窗口对应的通知事件包括的通知事件A，B，C，D分成一组，得到一个关联事件组；对于其他关联事件集合也可以执行同样的操作。
其中，每个通知事件的优先级可以根据每个通知事件的来源服务在该应用拓扑中的调用位置确定得到，且通知事件的来源服务在该应用拓扑中的调用位置越深，该通知事件的优先级越高。例如，当某个关联事件组包括A、B、C和D这4个通知事件，这4个通知事件的来源服务分别为服务1、服务2、服务3和服务4，且根据该应用拓扑确定这4个服务之间的调用关系为服务1调用服务2、服务2调用服务3、服务3调用服务4时，则可以确定通知事件D的优先级最高，通知事件A的优先级最低，并可以将通知事件D确定为该关联事件组的根因事件。
第二种实现方式：根据该应用拓扑、存储的该分布式应用系统的事件关联规则和部署信息，从指定通知事件集合中确定根因事件。
具体地，根据该应用拓扑、存储的该分布式应用系统的事件关联规则和部署信息，从指定通知事件集合中确定根因事件可以包括如下几个步骤：
步骤3031：获取该分布式应用系统的部署信息，该部署信息包括服务与集群的对应关系以及集群与解决方案的对应关系，该解决方案用于指示属于同一业务的集群。
实际应用中，该部署信息可以从上述图1B所述的PAAS中获取得到，并可以将从PAAS获取到的部署信息存储在管理设备的对象服务(Object service)模块中，后续可以直接从对象服务模块中获取需要的部署信息。
步骤3032：根据该部署信息，对该指定通知事件集合包括的多个通知事件进行聚合。
具体地，可以根据该多个通知事件中每个通知事件的来源服务，以及该部署信息包括的该服务与集群的对应关系，对该多个通知事件进行聚合，得到至少一个集群对应的通知事件，然后根据该部署信息包括的该集群与解决方案的对应关系，对该至少一个集群对应的通知事件进行聚合，得到至少一个解决方案对应的通知事件。
步骤3033：根据该应用拓扑和存储的该分布式应用系统的事件关联规则，从聚合后的该多个通知事件中确定该根因事件。
具体地，可以从该应用拓扑中确定该至少一个解决方案的集群调用拓扑；从该分布式应用系统的事件关联规则中确定该至少一个解决方案的事件关联规则；根据各个解决方案的集群调用拓扑和各个解决方案的事件关联规则，从各个解决方案对应的通知事件中确定该根因事件。
其中，根据各个解决方案的集群调用拓扑和各个解决方案的事件关联规则，从各个解决方案对应的通知事件中确定该根因事件可以包括如下步骤：
1)根据指定解决方案对应的通知事件的时间戳和预设长度的时间窗口，对该指定解决方案对应的通知事件进行分组，得到至少一个时间窗口对应的通知事件，该指定解决方案为该至少一个解决方案中的任一解决方案。
具体地，可以基于该多个通知事件的时间戳，按照时间窗口和滑动步长，对该指定解决方案对应的通知事件进行分组，得到至少一个时间窗口对应的通知事件。
2)将指定时间窗口对应的通知事件，按照该指定解决方案的事件关联规则进行分组，得到至少一个关联事件组，该指定时间窗口为该至少一个时间窗口中的任一时间窗口。
也即是，可以从该分布式应用系统的事件关联规则中确定属于该指定解决方案的事件关联规则，并按照该指定解决方案的事件关联规则，对该指定时间窗口对应的通知事件进行分组，从而得到至少一个关联事件组。
3)根据各个关联事件组中每个通知事件的来源服务，确定每个通知事件的优先级。
具体地，可以根据该指定解决方案的集群调用拓扑，确定各个关联事件组中每个通知事件的来源服务所在集群的拓扑优先级；将各个关联事件组中每个通知事件的来源服务所在集群的拓扑优先级，确定为各个关联事件组中每个通知事件的优先级。
其中，某个通知事件的来源服务所在集群的拓扑优先级可以根据该集群在该集群调用拓扑中的位置确定，且该集群在该集群调用拓扑中的调用位置越深，该集群的优先级越高。
例如，当某个关联事件组包括A、B、C和D这4个通知事件，这4个通知事件的来源服务分别所在的集群分别为集群1、集群2、集群3和集群4，且根据该集群调用拓扑确定这4个集群之间的调用关系为集群1调用集群2、集群2调用集群3、集群3调用集群4时，则可以确定集群4的优先级最高，集群1的优先级最低，进而可以确定通知事件D的优先级最高，通知事件A的优先级最低。
4)将各个关联事件组中优先级最高的通知事件，确定为各个关联事件组的根因事件。
本申请实施例中，可以通过分布式应用系统中参与调用的多个服务分别绑定的相同的代理程序，在多个服务的字节码中分别插入指定拦截代码，并根据在该多个服务的字节码中插入的指定拦截代码，通过绑定的代理程序分别获取该多个服务的调用日志，以便根据获取的调用日志确定该分布式应用系统的应用拓扑，根据该应用拓扑和存储的事件关联规则从多个通知事件中确定根因事件。由于可以根据各个服务分别绑定的代理程序，直接获取各个服务的调用日志，因此避免了从操作系统层拦截调用信息时对调用信息的过滤操作，简化了获取调用日志的方式，实现了轻量级调用日志采集，而且各个服务绑定的代理程序均相同即具有普适性，在部署时无需考虑各个服务的具体业务逻辑，具有无业务浸入、易部署的优点。
图2是本申请实施例提供的一种根因事件的确定装置的结构示意图，如图2所示，该装置包括插入模块201、第一获取模块202、第一确定模块203和第二确定模块204。
插入模块201，用于执行上述图1D该实施例中步骤101执行的操作；
第一获取模块202，用于执行上述图1D该实施例中步骤102执行的操作；
第一确定模块203，用于执行上述图1D该实施例中步骤103执行的操作；
第二确定模块204，用于执行上述图1D该实施例中步骤104执行的操作。
可选地，该指定拦截代码为非功能性打印语句；
该插入模块201具体用于：
通过该多个服务分别绑定的代理程序，在该多个服务的网络通讯包中分别插入该非功能打印语句；
该第一获取模块202具体用于：
通过该多个服务分别绑定的代理程序，根据在该多个服务的网络通讯包中插入的该非功能打印语句，分别获取该多个服务的网络通讯包中的指定类和指定装置，该指定类是指用于进行通讯的类，该指定装置包括发起通讯装置、接收通讯装置、读装置和写装置；
根据从该多个服务的网络通讯包中获取的指定类和指定装置，确定该多个服务的调用日志。
可选地，该第一确定模块203具体用于执行上述图1D该实施例中步骤103中的第二种实现方式。
可选地，该装置还包括：
第二获取模块，用于获取该分布式应用系统产生的多个历史通知事件；
第三确定模块，用于根据该多个历史通知事件，通过频繁模式挖掘算法确定该分布式应用系统的事件关联规则。
可选地，该第三确定模块包括：
预处理单元，用于对该多个历史通知事件进行预处理；
第一确定单元，用于采用该频繁模式挖掘算法，从预处理后的该多个历史通知事件中确定多个频繁项集，频繁项集是指支持度大于或等于预设支持度阈值的项集，该项集是指在第二预设时间段内产生的历史通知事件的集合，该支持度用于指示对应项集中包括的通知事件同时发生的概率；
第二确定单元，用于根据该多个频繁项集和该多个频繁项集的置信度，从该多个频繁项集中确定多个关联事件集合，该置信度用于指示对应频繁项集包括的通知事件相互关联的程度；
第三确定单元，用于将该多个关联事件集合确定为该分布式应用系统的事件关联规则。
可选地，该预处理单元具体用于：
将该多个历史通知事件中同一服务在同一第三预设时间段内产生的类型相同的通知事件合并为一个历史通知事件，并将合并后的历史通知事件的时间戳设置为该类型相同的通知事件的时间戳中最早的时间戳，时间戳用于指示对应历史通知事件的生成时间；
和/或，
从该多个历史通知事件中删除背景通知事件，该背景通知事件是指在该多个历史通知事件中发生概率大于预设概率阈值且与其他通知事件没有逻辑关系的通知事件。
可选地，该第二确定模块204包括：
获取单元，用于执行图1D该实施例中步骤3031执行的操作；
聚合单元，用于执行图1D该实施例中步骤3032执行的操作；
第四确定单元，用于执行图1D该实施例中步骤3033执行的操作。
可选地，该聚合单元具体用于：
根据该多个通知事件中每个通知事件的来源服务，以及该部署信息包括的该服务与集群的对应关系，对该多个通知事件进行聚合，得到至少一个集群对应的通知事件；
根据该部署信息包括的该集群与解决方案的对应关系，对该至少一个集群对应的通知事件进行聚合，得到至少一个解决方案对应的通知事件；
该第四确定单元具体用于：
从该应用拓扑中确定该至少一个解决方案的集群调用拓扑；
从该分布式应用系统的事件关联规则中确定该至少一个解决方案的事件关联规则；
根据各个解决方案的集群调用拓扑和各个解决方案的事件关联规则，从各个解决方案对应的通知事件中确定该根因事件。
可选地，该第四确定单元具体用于：
根据指定解决方案对应的通知事件的时间戳和预设长度的时间窗口，对该指定解决方案对应的通知事件进行分组，得到至少一个时间窗口对应的通知事件，该指定解决方案为该至少一个解决方案中的任一解决方案；
将指定时间窗口对应的通知事件，按照该指定解决方案的事件关联规则进行分组，得到至少一个关联事件组，该指定时间窗口为该至少一个时间窗口中的任一时间窗口；
根据各个关联事件组中每个通知事件的来源服务，确定每个通知事件的优先级；
将各个关联事件组中优先级最高的通知事件，确定为各个关联事件组的根因事件。
可选地，该第四确定单元具体用于：
根据该指定解决方案的集群调用拓扑，确定各个关联事件组中每个通知事件的来源服务所在集群的拓扑优先级；
将各个关联事件组中每个通知事件的来源服务所在集群的拓扑优先级，确定为各个关联事件组中每个通知事件的优先级。
本申请实施例中，可以通过分布式应用系统中参与调用的多个服务分别绑定的相同的代理程序，在多个服务的字节码中分别插入指定拦截代码，并根据在该多个服务的字节码中插入的指定拦截代码，通过绑定的代理程序分别获取该多个服务的调用日志，以便根据获取的调用日志确定该分布式应用系统的应用拓扑，根据该应用拓扑和存储的事件关联规则从多个通知事件中确定根因事件。由于可以根据各个服务分别绑定的代理程序，直接获取各个服务的调用日志，因此避免了从操作系统层拦截调用信息时对调用信息的过滤操作，简化了获取调用日志的方式，实现了轻量级调用日志采集，而且各个服务绑定的代理程序均相同即具有普适性，在部署时无需考虑各个服务的具体业务逻辑，具有无业务浸入、易部署的优点。
需要说明的是：上述实施例提供的根因事件的确定装置在确定根因事件时，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将装置的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。另外，上述实施例提供的根因事件的确定装置与根因事件的确定方法实施例属于同一构思，其具体实现过程详见方法实施例，这里不再赘述。
在另一实施例中，还提供了一种计算机可读存储介质，该计算机可读存储介质中存储有指令，当其在计算机上运行时，使得计算机执行上述图1D实施例所述的根因事件的确定方法。
在另一实施例中，还提供了一种包含指令的计算机程序产品，当其在计算机上运行时，使得计算机执行上述图1D实施例所述的根因事件的确定方法。
在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意结合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。该计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行该计算机指令时，全部或部分地产生按照本申请实施例该的流程或功能。该计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。该计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，该计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如：同轴电缆、光纤、数据用户线(DigitalSubscriber Line，DSL))或无线(例如：红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。该计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。该可用介质可以是磁性介质(例如：软盘、硬盘、磁带)、光介质(例如：数字通用光盘(DigitalVersatile Disc，DVD))、或者半导体介质(例如：固态硬盘(Solid State Disk，SSD))等。
本领域普通技术人员可以理解实现上述实施例的全部或部分步骤可以通过硬件来完成，也可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，上述提到的存储介质可以是只读存储器，磁盘或光盘等。
以上所述为本申请提供的实施例，并不用以限制本申请，凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。
Claims (22)
1.一种根由事件的确定方法，其特征在于，所述方法包括：
通过分布式应用系统中参与调用的多个服务分别绑定的代理程序，在所述多个服务的字节码中分别插入指定拦截代码，所述多个服务绑定的代理程序相同，且每个代理程序是通过软件开发工具包的Instrumentation功能与对应服务进行绑定；
通过所述多个服务分别绑定的代理程序，根据所述多个服务的字节码中插入的所述指定拦截代码，分别获取所述多个服务的调用日志；
根据获取的调用日志确定所述分布式应用系统的应用拓扑，所述应用拓扑用于指示所述多个服务之间的调用关系；
根据所述应用拓扑和存储的所述分布式应用系统的事件关联规则，从指定通知事件集合中确定根因事件，所述分布式应用系统的事件关联规则用于指示所述分布式应用系统产生的通知事件之间的关联关系，所述指定通知事件集合是指所述分布式应用系统在第一预设时间段内产生的通知事件的集合。
2.如权利要求1所述的方法，其特征在于，所述指定拦截代码为非功能性打印语句；
所述通过分布式应用系统中参与调用的多个服务分别绑定的代理程序，在所述多个服务的字节码中分别插入指定拦截代码，包括：
通过所述多个服务分别绑定的代理程序，在所述多个服务的网络通讯包中分别插入所述非功能打印语句；
所述通过所述多个服务分别绑定的代理程序，根据所述多个服务的字节码中插入的所述指定拦截代码，分别获取所述多个服务的调用日志，包括：
通过所述多个服务分别绑定的代理程序，根据在所述多个服务的网络通讯包中插入的所述非功能打印语句，分别获取所述多个服务的网络通讯包中的指定类和指定方法，所述指定类是指用于进行通讯的类，所述指定方法包括发起通讯方法、接收通讯方法、读方法和写方法；
根据从所述多个服务的网络通讯包中获取的指定类和指定方法，确定所述多个服务的调用日志。
3.如权利要求1或2所述的方法，其特征在于，所述根据获取的调用日志确定所述分布式应用系统的应用拓扑，包括：
根据获取的调用日志确定所述多个服务之间的调用主体和调用方向；
根据所述多个服务之间的调用主体和调用方向，确定所述多个服务之间的调用关系；
确定所述多个服务中每个服务所在的集群，所述集群用于指示属于同一软件包的服务；
根据每个服务所在的集群，将所述多个服务之间的调用关系转换为集群之间的调用关系；
根据所述集群之间的调用关系，确定所述分布式应用系统的应用拓扑。
4.如权利要求1-3任一所述的方法，其特征在于，所述根据所述应用拓扑和存储的所述分布式应用系统的事件关联规则，从指定通知事件集合中确定根因事件之前，还包括：
获取所述分布式应用系统产生的多个历史通知事件；
根据所述多个历史通知事件，通过频繁模式挖掘算法确定所述分布式应用系统的事件关联规则。
5.如权利要求4所述的方法，其特征在于，所述根据所述多个历史通知事件，通过频繁模式挖掘算法确定所述分布式应用系统的事件关联规则，包括：
对所述多个历史通知事件进行预处理；
采用所述频繁模式挖掘算法，从预处理后的所述多个历史通知事件中确定多个频繁项集，频繁项集是指支持度大于或等于预设支持度阈值的项集，所述项集是指在第二预设时间段内产生的历史通知事件的集合，所述支持度用于指示对应项集中包括的通知事件同时发生的概率；
根据所述多个频繁项集和所述多个频繁项集的置信度，从所述多个频繁项集中确定多个关联事件集合，所述置信度用于指示对应频繁项集包括的通知事件相互关联的程度；
将所述多个关联事件集合确定为所述分布式应用系统的事件关联规则。
6.如权利要求5所述的方法，其特征在于，所述对所述多个历史通知事件进行预处理，包括：
将所述多个历史通知事件中同一服务在同一第三预设时间段内产生的类型相同的通知事件合并为一个历史通知事件，并将合并后的历史通知事件的时间戳设置为所述类型相同的通知事件的时间戳中最早的时间戳，时间戳用于指示对应历史通知事件的生成时间；
和/或，
从所述多个历史通知事件中删除背景通知事件，所述背景通知事件是指在所述多个历史通知事件中发生概率大于预设概率阈值且与其他通知事件没有逻辑关系的通知事件。
7.如权利要求1-6任一所述的方法，其特征在于，所述根据所述应用拓扑和存储的所述分布式应用系统的事件关联规则，从指定通知事件集合中确定根因事件，包括：
获取所述分布式应用系统的部署信息，所述部署信息包括服务与集群的对应关系以及集群与解决方案的对应关系，所述解决方案用于指示属于同一业务的集群；
根据所述部署信息，对所述指定通知事件集合包括的多个通知事件进行聚合；
根据所述应用拓扑和存储的所述分布式应用系统的事件关联规则，从聚合后的所述多个通知事件中确定所述根因事件。
8.如权利要求7所述的方法，其特征在于，所述根据所述部署信息，对所述指定通知事件集合包括的多个通知事件进行聚合，包括：
根据所述多个通知事件中每个通知事件的来源服务，以及所述部署信息包括的所述服务与集群的对应关系，对所述多个通知事件进行聚合，得到至少一个集群对应的通知事件；
根据所述部署信息包括的所述集群与解决方案的对应关系，对所述至少一个集群对应的通知事件进行聚合，得到至少一个解决方案对应的通知事件；
所述根据所述应用拓扑和存储的所述分布式应用系统的事件关联规则，从聚合后的所述多个通知事件中确定所述根因事件，包括：
从所述应用拓扑中确定所述至少一个解决方案的集群调用拓扑；
从所述分布式应用系统的事件关联规则中确定所述至少一个解决方案的事件关联规则；
根据各个解决方案的集群调用拓扑和各个解决方案的事件关联规则，从各个解决方案对应的通知事件中确定所述根因事件。
9.如权利要求8所述的方法，其特征在于，所述根据各个解决方案的集群调用拓扑和各个解决方案的事件关联规则，从各个解决方案对应的通知事件中确定所述根因事件，包括：
根据指定解决方案对应的通知事件的时间戳和预设长度的时间窗口，对所述指定解决方案对应的通知事件进行分组，得到至少一个时间窗口对应的通知事件，所述指定解决方案为所述至少一个解决方案中的任一解决方案；
将指定时间窗口对应的通知事件，按照所述指定解决方案的事件关联规则进行分组，得到至少一个关联事件组，所述指定时间窗口为所述至少一个时间窗口中的任一时间窗口；
根据各个关联事件组中每个通知事件的来源服务，确定每个通知事件的优先级；
将各个关联事件组中优先级最高的通知事件，确定为各个关联事件组的根因事件。
10.如权利要求9所述的方法，其特征在于，所述根据各个关联事件组中每个通知事件的来源服务，确定每个通知事件的优先级，包括：
根据所述指定解决方案的集群调用拓扑，确定各个关联事件组中每个通知事件的来源服务所在集群的拓扑优先级；
将各个关联事件组中每个通知事件的来源服务所在集群的拓扑优先级，确定为各个关联事件组中每个通知事件的优先级。
11.一种根由事件的确定装置，其特征在于，所述装置包括：
插入模块，用于通过分布式应用系统中参与调用的多个服务分别绑定的代理程序，在所述多个服务的字节码中分别插入指定拦截代码，所述多个服务绑定的代理程序相同，且每个代理程序是通过软件开发工具包的Instrumentation功能与对应服务进行绑定；
第一获取模块，用于通过所述多个服务分别绑定的代理程序，根据所述多个服务的字节码中插入的所述指定拦截代码，分别获取所述多个服务的调用日志；
第一确定模块，用于根据获取的调用日志确定所述分布式应用系统的应用拓扑，所述应用拓扑用于指示所述多个服务之间的调用关系；
第二确定模块，用于根据所述应用拓扑和存储的所述分布式应用系统的事件关联规则，从指定通知事件集合中确定根因事件，所述分布式应用系统的事件关联规则用于指示所述分布式应用系统产生的通知事件之间的关联关系，所述指定通知事件集合是指所述分布式应用系统在第一预设时间段内产生的通知事件的集合。
12.如权利要求11所述的装置，其特征在于，所述指定拦截代码为非功能性打印语句；
所述插入模块具体用于：
通过所述多个服务分别绑定的代理程序，在所述多个服务的网络通讯包中分别插入所述非功能打印语句；
所述第一获取模块具体用于：
通过所述多个服务分别绑定的代理程序，根据在所述多个服务的网络通讯包中插入的所述非功能打印语句，分别获取所述多个服务的网络通讯包中的指定类和指定装置，所述指定类是指用于进行通讯的类，所述指定装置包括发起通讯装置、接收通讯装置、读装置和写装置；
根据从所述多个服务的网络通讯包中获取的指定类和指定装置，确定所述多个服务的调用日志。
13.如权利要求11或12所述的装置，其特征在于，所述第一确定模块具体用于：
根据获取的调用日志确定所述多个服务之间的调用主体和调用方向；
根据所述多个服务之间的调用主体和调用方向，确定所述多个服务之间的调用关系；
确定所述多个服务中每个服务所在的集群，所述集群用于指示属于同一软件包的服务；
根据每个服务所在的集群，将所述多个服务之间的调用关系转换为集群之间的调用关系；
根据所述集群之间的调用关系，确定所述分布式应用系统的应用拓扑。
14.如权利要求11-13任一所述的装置，其特征在于，所述装置还包括：
第二获取模块，用于获取所述分布式应用系统产生的多个历史通知事件；
第三确定模块，用于根据所述多个历史通知事件，通过频繁模式挖掘算法确定所述分布式应用系统的事件关联规则。
15.如权利要求14所述的装置，其特征在于，所述第三确定模块包括：
预处理单元，用于对所述多个历史通知事件进行预处理；
第一确定单元，用于采用所述频繁模式挖掘算法，从预处理后的所述多个历史通知事件中确定多个频繁项集，频繁项集是指支持度大于或等于预设支持度阈值的项集，所述项集是指在第二预设时间段内产生的历史通知事件的集合，所述支持度用于指示对应项集中包括的通知事件同时发生的概率；
第二确定单元，用于根据所述多个频繁项集和所述多个频繁项集的置信度，从所述多个频繁项集中确定多个关联事件集合，所述置信度用于指示对应频繁项集包括的通知事件相互关联的程度；
第三确定单元，用于将所述多个关联事件集合确定为所述分布式应用系统的事件关联规则。
16.如权利要求15所述的装置，其特征在于，所述预处理单元具体用于：
将所述多个历史通知事件中同一服务在同一第三预设时间段内产生的类型相同的通知事件合并为一个历史通知事件，并将合并后的历史通知事件的时间戳设置为所述类型相同的通知事件的时间戳中最早的时间戳，时间戳用于指示对应历史通知事件的生成时间；
和/或，
从所述多个历史通知事件中删除背景通知事件，所述背景通知事件是指在所述多个历史通知事件中发生概率大于预设概率阈值且与其他通知事件没有逻辑关系的通知事件。
17.如权利要求11-16任一所述的装置，其特征在于，所述第二确定模块包括：
获取单元，用于获取所述分布式应用系统的部署信息，所述部署信息包括服务与集群的对应关系以及集群与解决方案的对应关系，所述解决方案用于指示属于同一业务的集群；
聚合单元，用于根据所述部署信息，对所述指定通知事件集合包括的多个通知事件进行聚合；
第四确定单元，用于根据所述应用拓扑和存储的所述分布式应用系统的事件关联规则，从聚合后的所述多个通知事件中确定所述根因事件。
18.如权利要求17所述的装置，其特征在于，所述聚合单元具体用于：
根据所述多个通知事件中每个通知事件的来源服务，以及所述部署信息包括的所述服务与集群的对应关系，对所述多个通知事件进行聚合，得到至少一个集群对应的通知事件；
根据所述部署信息包括的所述集群与解决方案的对应关系，对所述至少一个集群对应的通知事件进行聚合，得到至少一个解决方案对应的通知事件；
所述第四确定单元具体用于：
从所述应用拓扑中确定所述至少一个解决方案的集群调用拓扑；
从所述分布式应用系统的事件关联规则中确定所述至少一个解决方案的事件关联规则；
根据各个解决方案的集群调用拓扑和各个解决方案的事件关联规则，从各个解决方案对应的通知事件中确定所述根因事件。
19.如权利要求18所述的装置，其特征在于，所述第四确定单元具体用于：
根据指定解决方案对应的通知事件的时间戳和预设长度的时间窗口，对所述指定解决方案对应的通知事件进行分组，得到至少一个时间窗口对应的通知事件，所述指定解决方案为所述至少一个解决方案中的任一解决方案；
将指定时间窗口对应的通知事件，按照所述指定解决方案的事件关联规则进行分组，得到至少一个关联事件组，所述指定时间窗口为所述至少一个时间窗口中的任一时间窗口；
根据各个关联事件组中每个通知事件的来源服务，确定每个通知事件的优先级；
将各个关联事件组中优先级最高的通知事件，确定为各个关联事件组的根因事件。
20.如权利要求19所述的装置，其特征在于，所述第四确定单元具体用于：
根据所述指定解决方案的集群调用拓扑，确定各个关联事件组中每个通知事件的来源服务所在集群的拓扑优先级；
将各个关联事件组中每个通知事件的来源服务所在集群的拓扑优先级，确定为各个关联事件组中每个通知事件的优先级。
21.一种根因事件的确定装置，包括存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，其特征在于，所述处理器被配置为执行权利要求1-10所述的任一项方法的步骤。
22.一种计算机可读存储介质，所述计算机可读存储介质中存储有指令，其特征在于，当其在计算机上运行时，使得计算机执行如权利要求1-10任一项所述的方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201711299205.4A CN109905436A (zh) | 2017-12-08 | 2017-12-08 | 根因事件的确定方法、装置及存储介质 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201711299205.4A CN109905436A (zh) | 2017-12-08 | 2017-12-08 | 根因事件的确定方法、装置及存储介质 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN109905436A true CN109905436A (zh) | 2019-06-18 |
Family
ID=66940867
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201711299205.4A Pending CN109905436A (zh) | 2017-12-08 | 2017-12-08 | 根因事件的确定方法、装置及存储介质 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN109905436A (zh) |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2021135479A1 (zh) * | 2019-12-30 | 2021-07-08 | 华为技术有限公司 | 提示信息处理方法、装置和存储介质 |
| CN113360722A (zh) * | 2021-06-25 | 2021-09-07 | 杭州优云软件有限公司 | 一种基于多维数据图谱的故障根因定位方法及系统 |
| CN114064344A (zh) * | 2022-01-18 | 2022-02-18 | 苏州浪潮智能科技有限公司 | 一种根因定位的方法、装置以及介质 |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20150052441A1 (en) * | 2013-07-30 | 2015-02-19 | Draios Inc. | System, method, and graphical user interface for application topology mapping in hosted computing environments |
| US20160105350A1 (en) * | 2014-10-10 | 2016-04-14 | Dynatrace Llc | Method And System For Real-time Modeling Of Communication, Virtualization And Transaction Execution Related Topological Aspects Of Monitored Software Applications And Hardware Entities |
| CN106489251A (zh) * | 2015-12-21 | 2017-03-08 | 华为技术有限公司 | 应用拓扑关系发现的方法、装置和系统 |
| US20170075749A1 (en) * | 2015-09-14 | 2017-03-16 | Dynatrace Llc | Method And System For Real-Time Causality And Root Cause Determination Of Transaction And Infrastructure Related Events Provided By Multiple, Heterogeneous Agents |
-
2017
- 2017-12-08 CN CN201711299205.4A patent/CN109905436A/zh active Pending
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20150052441A1 (en) * | 2013-07-30 | 2015-02-19 | Draios Inc. | System, method, and graphical user interface for application topology mapping in hosted computing environments |
| US20160105350A1 (en) * | 2014-10-10 | 2016-04-14 | Dynatrace Llc | Method And System For Real-time Modeling Of Communication, Virtualization And Transaction Execution Related Topological Aspects Of Monitored Software Applications And Hardware Entities |
| US20170075749A1 (en) * | 2015-09-14 | 2017-03-16 | Dynatrace Llc | Method And System For Real-Time Causality And Root Cause Determination Of Transaction And Infrastructure Related Events Provided By Multiple, Heterogeneous Agents |
| CN106489251A (zh) * | 2015-12-21 | 2017-03-08 | 华为技术有限公司 | 应用拓扑关系发现的方法、装置和系统 |
Cited By (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2021135479A1 (zh) * | 2019-12-30 | 2021-07-08 | 华为技术有限公司 | 提示信息处理方法、装置和存储介质 |
| CN113132128A (zh) * | 2019-12-30 | 2021-07-16 | 北京华为数字技术有限公司 | 提示信息处理方法、装置和存储介质 |
| CN113132128B (zh) * | 2019-12-30 | 2022-07-19 | 北京华为数字技术有限公司 | 提示信息处理方法、装置和存储介质 |
| CN113360722A (zh) * | 2021-06-25 | 2021-09-07 | 杭州优云软件有限公司 | 一种基于多维数据图谱的故障根因定位方法及系统 |
| CN113360722B (zh) * | 2021-06-25 | 2022-08-09 | 杭州优云软件有限公司 | 一种基于多维数据图谱的故障根因定位方法及系统 |
| CN114064344A (zh) * | 2022-01-18 | 2022-02-18 | 苏州浪潮智能科技有限公司 | 一种根因定位的方法、装置以及介质 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US10528454B1 (en) | Intelligent automation of computer software testing log aggregation, analysis, and error remediation | |
| US20200073640A1 (en) | System and method for generating an application structure for an application in a computerized organization | |
| US7099879B2 (en) | Real-time monitoring of service performance through the use of relational database calculation clusters | |
| AU2013221760B2 (en) | Providing configurable workflow capabilities | |
| US8819701B2 (en) | Cloud computing monitoring and management system | |
| JP2018185808A (ja) | ブロックチェーンに基づくスマート契約をテストする装置及び方法 | |
| CN108132830A (zh) | 一种任务调度方法、装置及系统 | |
| US20030212778A1 (en) | UML representation of parameter calculation expressions for service monitoring | |
| EP4086771B1 (en) | Method and system for the on-demand generation of graph-like models out of multidimensional observation data | |
| CN109905436A (zh) | 根因事件的确定方法、装置及存储介质 | |
| CN110532322B (zh) | 运维交互方法、系统、计算机可读存储介质及设备 | |
| WO2016005898A1 (en) | Method for processing data quality exceptions in data processing system | |
| CN103257852B (zh) | 一种分布式应用系统的开发环境搭建的方法和装置 | |
| US10775751B2 (en) | Automatic generation of regular expression based on log line data | |
| CN112688802B (zh) | 一种基于api网关的高效能交换中间件 | |
| CN108073582A (zh) | 一种计算框架选择方法和装置 | |
| CN109614241A (zh) | 基于Yarn队列实现多集群多租户资源隔离的方法及系统 | |
| CN113672452A (zh) | 一种数据采集任务的运行监控方法、系统 | |
| CN109714214A (zh) | 一种服务器异常的处理方法及管理设备 | |
| Omori et al. | Comparing concept drift detection with process mining tools | |
| US20230409710A1 (en) | Allow list of container images based on deployment configuration at a container orchestration service | |
| CN109324892B (zh) | 分布式管理方法、分布式管理系统及装置 | |
| CN115543345A (zh) | 一种针对电力时序数据的分布式计算系统及其实现方法 | |
| WO2023096731A1 (en) | Detect anomalous container deployment at a container orchestration service | |
| CN115794438A (zh) | 数据处理方法、装置、设备和存储介质 |
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 | ||
| TA01 | Transfer of patent application right | ||
| TA01 | Transfer of patent application right |
Effective date of registration: 20200211 Address after: 518129 Bantian HUAWEI headquarters office building, Longgang District, Guangdong, Shenzhen Applicant after: HUAWEI TECHNOLOGIES Co.,Ltd. Address before: 210000 HUAWEI Nanjing base, 101 software Avenue, Yuhuatai District, Jiangsu, Nanjing Applicant before: Huawei Technologies Co.,Ltd. |
|
| AD01 | Patent right deemed abandoned | ||
| AD01 | Patent right deemed abandoned |
Effective date of abandoning: 20210604 |