故障处理方法、引擎、插件化探针、设备及可读存储介质与流程

本申请涉及计算机技术领域，特别是涉及故障处理方法、排障引擎、插件化探针、设备及可读存储介质。

背景技术：

随着网络技术的不断发展，远程控制/管理越来越普遍。对于故障处理而已，远程控制技术可以大大降低故障处理成本，也可提升故障处理效率。

但是，目前已有的远程故障处理技术中所对应的规则排障引擎仍然存在以下排障形式单一、规则固定且规则需提前定义好，排障过程中只能扫描已有经验项，无法批量解决多个终端的已知问题，一旦需引入新排障规则经验，则需要打对排障引擎进行补丁或升级等。即，已有的排障引擎存在不灵活的问题。

综上所述，如何有效地提升排障引擎的灵活性等问题，是目前本领域技术人员急需解决的技术问题。

技术实现要素：

本申请的目的是提供一种故障处理方法、排障引擎、插件化探针、设备及可读存储介质，通过插件化探针实现与被管理终端之间的通信，可以向被管理终端发送故障处理脚本，且被管理终端可以利用插件化指针执行故障处理脚本，并反馈故障处理，可提升排障引擎的灵活性。

为解决上述技术问题，本申请提供如下技术方案：

一方面，本申请提供了第一种故障处理方法，包括：

从多个被管理终端中确定出发生故障的目标终端及故障类型；

获取与所述故障类型对应的故障处理脚本；

将所述故障处理脚本发送至所述目标终端中的插件化探针；

接收所述插件化探针执行所述故障处理脚本后发送的故障处理结果。

在本申请中的一种具体实施方式中，所述插件化探针是集成了运行时环境、支持执行插件化类型的脚本的程序，所述插件化类型的脚本包括lua脚本、python脚本、ruby脚本、shell脚本、perl脚本中的一种或多种的组合，所述程序包括代理程序、应用程序、进程或者服务。

在本申请中的一种具体实施方式中，若所述插件化类型的脚本为lua脚本，则所述插件化探针无需预先配置脚本运行环境。

在本申请中的一种具体实施方式中，若所述插件化类型的脚本为所述python脚本、所述ruby脚本、所述shell脚本或所述perl脚本，则所述插件化探针需要预先配置脚本运行环境。

在本申请中的一种具体实施方式中，所述被管理终端包括虚拟机和物理机中的至少一种。

在本申请中的一种具体实施方式中，所述获取与所述故障类型对应的故障处理脚本，包括：

从规则脚本库中找出与所述故障类型对应的所述故障处理脚本。

在本申请中的一种具体实施方式中，若所述插件化类型的脚本包括lua脚本，相应地，所述获取与所述故障类型对应的故障处理脚本，包括：

从所述规则脚本库中，找出与所述故障类型对应的目标lua脚本，并将所述目标lua脚本确定为所述故障处理脚本；

在未找到所述目标lua脚本的情况下，找出非lua语言中与所述故障类型对应的故障处理脚本。

在本申请中的一种具体实施方式中，接收所述插件化探针执行所述故障处理脚本后发送的故障处理结果，包括：

若所述故障处理脚本非所述目标lua脚本，则接收所述插件化探针在运行时环境下执行所述故障处理脚本后发送的故障处理结果。

在本申请中的一种具体实施方式中，所述从多个被管理终端中确定出发生故障的目标终端及故障类型，包括：

向多个所述被管理终端中的所述插件化探针发送故障检测脚本；

接收所述插件化探针执行所述故障检测脚本后发送的故障检测结果；

利用所述故障检测结果，从多个所述被管理终端中，确定出发生故障的所述目标终端及所述故障类型。

在本申请中的一种具体实施方式中，所述从多个被管理终端中确定出发生故障的目标终端及故障类型，包括：

接收故障反馈信息；

利用所述故障反馈信息，从多个所述被管理终端中确定出所述目标终端和所述故障类型。

在本申请中的一种具体实施方式中，所述从多个被管理终端中确定出发生故障的目标终端及故障类型，包括：

接收各个被管理终端中的所述插件化探针定期反馈的运行状态数据；

利用所述运行状态数据，从多个所述被管理终端中确定出所述目标终端和所述故障类型。

在本申请中的一种具体实施方式中，在接收所述插件化探针执行所述故障处理脚本后发送的故障处理结果之后，还包括：

若所述故障处理结果对应故障处理失败，则从规则脚本库中重新找出与所述故障类型对应的故障处理脚本，并发送给所述插件化探针。

在本申请中的一种具体实施方式中，还包括：

在规则脚本库中未找出与所述故障类型对应的所述故障处理脚本的情况下，输出无对应处理脚本的提示信息；

获取新故障处理脚本，并将所述新故障处理脚本发送给所述插件化探针；

接收所述插件化探针执行所述新故障处理脚本后发送的处理结果；

若所述处理结果对应成功解决故障，则将所述新故障处理脚本确定为所述故障类型对应的故障处理脚本并存入所述规则脚本库中。

另一方面，本申请提供了第二种故障处理方法，包括：

在目标终端发生故障后，所述目标终端中的插件化探针接收排障引擎发送的故障处理脚本；所述故障处理脚本为所述排障引擎从多个被管理终端中确定出发生故障的所述目标终端及故障类型后，所获取的与所述故障类型对应的故障处理脚本；

执行所述故障处理脚本；

向所述排障引擎反馈故障处理结果。

在本申请中的一种具体实施方式中，所述插件化探针是集成了运行时环境、支持执行插件化类型的脚本的程序，所述插件化类型的脚本包括lua脚本、python脚本、ruby脚本、shell脚本、perl脚本中的一种或多种的组合，所述程序包括代理程序、应用程序、进程或者服务。

在本申请中的一种具体实施方式中，若所述插件化类型的脚本为lua脚本，则所述插件化探针无需预先配置脚本运行环境。

在本申请中的一种具体实施方式中，若所述插件化类型的脚本为所述python脚本、所述ruby脚本、所述shell脚本或所述perl脚本，则所述插件化探针需要预先配置脚本运行环境。

在本申请中的一种具体实施方式中，还包括：

定期获取所述目标终端的运行状态数据；

将所述运行状态数据发送给所述排障引擎。

在本申请中的一种具体实施方式中，还包括：

接收所述排障引擎发送的故障检测脚本；

执行所述故障检测脚本，得到故障检测结果；

将所述故障检测结果发送给所述排障引擎。

另一方面，本申请提供了一种排障引擎，包括：

故障确定模块，用于从多个被管理终端中确定出发生故障的目标终端及故障类型；

脚本获取模块，用于获取与所述故障类型对应的故障处理脚本；

脚本发送模块，用于将所述故障处理脚本发送至所述目标终端中的插件化探针；

结果接收模块，用于接收所述插件化探针执行所述故障处理脚本后发送的故障处理结果。

另一方面，本申请提供了一种插件化探针，包括：

脚本接收模块，用于在目标终端发生故障后，接收排障引擎发送的故障处理脚本；所述故障处理脚本为所述排障引擎从多个被管理终端中确定出发生故障的所述目标终端及故障类型后，所获取的与所述故障类型对应的故障处理脚本；

脚本执行模块，用于执行所述故障处理脚本；

结果反馈模块，用于向所述排障引擎反馈故障处理结果。

另一方面，本申请提供了第一种电子设备，包括：

存储器，用于存储计算机程序；

处理器，用于执行所述计算机程序时实现上述第一种故障处理方法的步骤。

另一方面，本申请提供了第二种电子设备，包括：

存储器，用于存储计算机程序；

处理器，用于执行所述计算机程序时实现上述第二种故障处理方法的步骤。

另一方面，本申请提供了一种可读存储介质，所述可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现上述第一种故障处理方法或第一种故障处理方法的步骤。

应用本申请实施例所提供的方法，从多个被管理终端中确定出发生故障的目标终端及故障类型；获取与故障类型对应的故障处理脚本；将故障处理脚本发送至目标终端中的插件化探针；接收插件化探针执行故障处理脚本后发送的故障处理结果。

在本方法中，利用目标终端中的插件化探针便可实现故障处理脚本的接收与执行，并得到故障处理结果。由于处理目标终端的故障是利用故障处理脚本进行，因而，可根据不同的故障类型设置对应的故障处理脚本，可灵活应对多种故障类型，并且目标终端中的探针为插件化探针，能够使得探针支持插件化脚本。即当有新型故障产生后，通过增加新型故障对应的故障处理脚本，即可对应解决新型故障，而无需对排障引擎或者探针进行打补丁或升级。具体的，插件化探针位于被管理终端，即处理各个目标终端的故障时，在各个目标终端接收到故障处理脚本的情况下，自行执行并处理故障，因此，排障引擎可以批量向多个目标终端发送故障处理脚本，可实现批量处理故障。由此可见，本方法应用于排障引擎中，能够有效提升排障引擎的灵活性，能够灵活应对不同的排障需求。

相应地，本申请实施例还提供了与上述故障处理方法相对应的另一种故障处理方法，排障引擎、插件化探针、设备和可读存储介质，具有上述技术效果，在此不再赘述。

附图说明

为了更清楚地说明本申请实施例或相关技术中的技术方案，下面将对实施例或相关技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本申请实施例中一种故障处理方法的实施流程图；

图2为本申请实施例中另一种故障处理方法的实施流程图；

图3为本申请实施例中一种排障引擎的结构示意图；

图4为本申请实施例中一种插件化探针的结构示意图；

图5为本申请实施例中一种故障处理方法的实施示意图；

图6为本申请实施例中一种电子设备的结构示意图；

图7为本申请实施例中一种电子设备的具体结构示意图；

图8为本申请实施例中一种故障处理具体应用实施示意图。

具体实施方式

为了使本技术领域的人员更好地理解本申请方案，下面结合附图和具体实施方式对本申请作进一步的详细说明。显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

本申请提供了一种故障处理方法，该方法可应用于排障引擎中。具体的，请参考图1，图1为本申请实施例中一种故障处理方法的流程图，该方法包括以下步骤：

s101、从多个被管理终端中确定出发生故障的目标终端及故障类型。

其中，被管理终端可以为虚拟机，也可以为物理机。多个被管理终端可以同时为虚拟机，也可以同时为物理机，也可以为混合模式，如一部分为虚拟机，一部分为物理机。

具体的，被管理终端可以具体为桌面云场景下的虚拟机，公有云场景下的物理机，以及pc场景下的pc；当然被管理终端还可以为服务器等需要被远程故障处理的终端。

例如，被管理终端可以具体为客户机(guest)，如vdi或hci(human-computerinteraction，人机交互)对应的虚拟机。其中，vdi(virtualdesktopinfrastructure)：虚拟桌面基础架构，基于服务器虚拟化诞生出的一种技术，其将所有桌面pc所需的操作系统软件、应用程序软件、用户数据全部存放到后台服务器中，通过专门的管理系统赋予给特定用户，用户通过专用的网络传输协议连接到后端服务器分配的桌面资源，连接后，用户可在连接本地终端上直接使用后台运行的桌面系统，使用体验基本与物理pc一致。

在本实施例中，从被管理终端中确定出的目标终端的数量可以为1个也可以为多个，各个目标终端的故障类型可以相同，也可以各不相同，一个目标终端可以仅对于一种故障类型，也可以对应多种故障类型。

具体的，在本实施例中确定出发生故障的目标终端及故障类型的方式，包括但不限于以下两种方式：

方式1：通过被管理终端的用户反馈故障的方式，确定出发生故障的目标终端以及故障类型。具体的实现过程，包括：

步骤一、接收故障反馈信息；

步骤二、利用故障反馈信息，从多个被管理终端中确定出目标终端和故障类型。

为便于说明，下面将上述两个步骤结合起来进行说明。

接收被管理终端的用户发送的故障反馈信息，然后将该被管理终端确定为发生故障的目标终端，并基于故障反馈信息确定故障类型。当然，用户反馈故障信息之后，还可进一步对该被管理终端进行故障检测，以核实是否发生故障，及确定具体的故障类型。

方式2：通过向被管理终端进行故障检测的方式，确定出发生故障的目标终端以及故障类型。具体的实现过程，包括：

步骤一、向多个被管理终端中的插件化探针发送故障检测脚本；

步骤二、接收插件化探针执行故障检测脚本后发送的故障检测结果；

步骤三、利用故障检测结果，从多个被管理终端中确定出发生故障的目标终端及故障类型。

为便于说明，下面将上述三个步骤结合起来进行说明。

其中，故障检测脚本可以具体为采用lua语言编写的能够检测故障的脚本，当然也可以为其他编程语言编写的能够检测故障的脚本。其中，lua是一个简洁、轻量、可扩展的程序设计语言，其设计目的是为了嵌入应用程序中，从而为应用程序提供灵活的扩展和定制功能。lua由标准c编写而成，几乎在所有操作系统和平台上都可以编译，运行，它还有一个同时进行的jit项目，提供在特定平台上的即时编译功能。需要注意的是，探针由于集成了lua脚本的运行时环境，因而插件化探针在执行由lua语言编写的脚本时，可无需设置运行时环境。对于故障检测脚本的具体逻辑可具体参见相关故障检测流程，在此不再一一赘述。

排障引擎向被管理终端的插件化探针发送故障件脚本后，被管理终端中的插件化探针便可自动执行该挂载检测脚本，并在执行后，向排障引擎发送故障检测结果。

方式3：通过接收排障引擎定期反馈的运行状态数据的方式，确定出发生故障的目标终端以及故障类型。具体的实现过程，包括：

步骤一、接收各个被管理终端中的插件化探针定期反馈的运行状态数据；

步骤二、利用运行状态数据，从多个被管理终端中确定出目标终端和故障类型。

为便于说明，下面将上述两个步骤结合起来进行说明。

即，插件化探针主动定期搜集虚拟机(即其所在的被管理终端)运行状态数据。该运行状态数据对应运行的相关数据，如运行状态，参数变化，日志等。插件化探针将运行状态数据上传给排障引擎供分析，排障引擎基于这些信息分析/核实是否发生故障，以及故障类型。具体的，对于排障引擎如何确定故障以及故障类型可具体参照相关故障检测算法，在此不再一一赘述。

排障引擎接收到故障检测结果之后，便可基于该故障检测结果从管理终端中确定出发生故障的目标终端以及故障类型。在本实施例中，对故障类型的具体数量和种类不做限定。

s102、获取与故障类型对应的故障处理脚本。

在本实施例中，可预先针对不同类型的故障设置对应的故障处理规则/方案，采用编程语言将其表示，即预先定义和设置好不同故障类型对应的故障处理脚本。例如，对于cpu持续占用超过90％可能会引起虚拟机卡顿，则可对应设置一条卡顿故障对应的故障处理脚本，该故障处理脚本被执行时，可减少cpu占用。

需要注意的是，对于同一故障类型，可以设置多种不同的故障处理脚本。如此，便可从预先定义好的故障处理脚本中直接查询获得与该故障类型对应的故障处理脚本。

当然，还可在确定出故障类型之后，通过接收排障人员上传的故障处理脚本的方式从而获得与故障类型对应的故障处理脚本。

还可以向第三应用或设备发送故障处理脚本获取请求，进而接收第三方应用或设备反馈的故障处理脚本。即，在本实施例中，对于故障处理脚本的具体获取方式并不做限定，即仅需故障处理脚本与故障类型相对应即可。例如，该故障处理脚本可以为已知的专家经验，并固化为

lua脚本，可被排障引擎调度和下发。

s103、将故障处理脚本发送至目标终端中的插件化探针。

其中插件化探针是集成了运行时环境、支持执行插件化类型的脚本的程序，插件化类型的脚本包括lua脚本、python脚本、ruby脚本、shell脚本、perl脚本中的一种或多种的组合，程序包括代理程序、应用程序、进程或者服务。

需要注意的是，若插件化类型的脚本为lua脚本，则插件化探针无需预先配置脚本运行环境。若插件化类型的脚本为python脚本、ruby脚本、shell脚本或perl脚本，则插件化探针需要预先配置脚本运行环境。

也就是说，本申请实施例中所描述的插件化探针，是一种部署在目标终端中的代理程序(agent)、运行在虚拟机中的应用程序、进程或服务等，可接收数据(如故障检测脚本、故障处理脚本)，执行脚本以及发送数据。在本实施例中，被管理终端上均有对应的插件化探针。

即，当插件化类型的脚本为lua脚本时，本申请中的插件化探针，是对现有探针做了改进，对探针布置了运行时环境，使得探针支持插件化脚本，从而可以在接收到来自排障引擎的相关脚本(如故障检测脚本、故障处理脚本)后，能够直接执行脚本，实现故障排查/处理的目的。该插件化探针集成运行时环境，可具体通过go语言(一种编程语言)的开发库，将运行时环境编译/集成到了探针内部。

排障引擎将故障处理脚本发送给目标终端中的插件化探针。也就是说，插件化探针实现目标终端与排障引擎之间的通信。

插件化探针接收到故障处理脚本之后，便可执行该故障处理脚本，从而对故障进行处理。

考虑到不同的编程语言对应的脚本执行需求不同，因而插件化探针在执行故障处理脚本时，也需对应按照相应的执行需求进行执行。例如，对于lua语言，在探针执行对应脚本则无需运行时环境(runtime环境)，而对于windows批处理脚本、linux脚本等需要运行时环境的语言而言，则需在目标终端提前设置好运行时环境。

插件化探针执行故障处理脚本之后，可将故障处理结果反馈给排障引擎。

s104、接收插件化探针执行故障处理脚本后发送的故障处理结果。

其中，故障处理结果可以具体包括故障问题、故障处理方案、故障是否成功解决。

在得到故障处理结果之后，排障引擎可直接将其在可视化界面进行展示，当然还可对故障处理结果进行统计分析(如统计故障处理成功率，故障处理次数等)，将统计分析结果在可视化界面进行显示。优选地，为便于管理，还可在排障引擎中设置一个告警子引擎，提供排障结果的接收，问题、警告、解决方案的警告显示。当然，在目标终端也可设置一个告警子引擎，以便直接在目标终端上输出告警信息。

举例说明：假设进程virus.exe是一个不断复制的病毒进程，虚拟机(一种具体的目标终端)会因为其消耗资源的不断上涨而卡慢，严重影响业务运行。此时，可以通过定义的一条删除进程的脚本规则，通过post请求，批量下发给所有虚拟机，插件化探针会调用这个脚本，将病毒进行删除或者进程停止。从而间接该病毒进程造成的业务运行故障。

应用本申请实施例所提供的方法，从多个被管理终端中确定出发生故障的目标终端及故障类型；获取与故障类型对应的故障处理脚本；将故障处理脚本发送至目标终端中的插件化探针；接收插件化探针执行故障处理脚本后发送的故障处理结果。

在本方法中，利用目标终端中的插件化探针便可实现故障处理脚本的接收与执行，并得到故障处理结果。由于处理目标终端的故障是利用故障处理脚本进行，因而，可根据不同的故障类型设置对应的故障处理脚本，可灵活应对多种故障类型，并且目标终端中的探针为插件化探针，能够使得探针支持插件化脚本。即当有新型故障产生后，仅通过增加新型故障对应的故障处理脚本，即可对应解决新型故障，而无需对排障引擎或者探针进行打补丁或升级。具体的，插件化探针位于被管理终端，即处理各个目标终端的故障时，在各个目标终端接收到故障处理脚本的情况下，自行执行并处理故障，因此，排障引擎可以批量向多个目标终端发送故障处理脚本，可实现批量处理故障。由此可见，本方法应用于排障引擎中，能够有效提升排障引擎的灵活性，能够灵活应对不同的排障需求。

需要说明的是，基于上述实施例，本申请实施例还提供了相应的改进方案。在优选/改进实施例中涉及与上述实施例中相同步骤或相应步骤之间可相互参考，相应的有益效果也可相互参照，在本文的优选/改进实施例中不再一一赘述。

在本申请的一种具体实施方式中，上述步骤s102获取与故障类型对应的故障处理脚本，可具体包括：从规则脚本库中找出与故障类型对应的故障处理脚本。也就是说，可预先设置规则脚本库，在规则脚本库中预先存储不同故障类型所对应的故障处理脚本。如此，在确定出目标终端的故障类型之后，便可直接从规则脚本库中查询/检索到与该故障类型对应的故障处理脚本。

进一步地，考虑到lua语言对应的脚本不需要运行时环境便可执行，因此在规则脚本库中寻找对应的故障处理脚本时，可优先查找lua语言的故障处理脚本。若插件化类型的脚本包括lua脚本，具体实现过程，包括：

步骤一、从规则脚本库中，找出与故障类型对应的目标lua脚本，并将目标lua脚本确定为故障处理脚本；

步骤二、在未找到目标lua脚本的情况下，找出非lua语言中与故障类型对应的故障处理脚本。

需要注意的是，采用何种编程语言来编写故障处理脚本，对故障处理效果的差异性在本实施例中可不需关注。也就是说，优先选用lua语言编写的故障处理脚本，仅因其执行时不需要运行时环境。

即，在规则脚本库中，可采用不同的语言来编写同一个故障解决方案对应的故障处理脚本。在确定出故障类型之后，便可基于该故障类型从规则脚本库中先寻找lua语言编写的，且与该故障类型对应的故障处理脚本。若在规则脚本库中未找到lua语言对应的故障处理脚本，可再从规则脚本库中寻找非lua语言，但其与该故障类型对应的故障处理脚本，如windows批处理脚本或linux脚本。

相应地，插件化探针在执行故障处理脚本时，也分情况而对应不同的执行情况。具体的，若故障处理脚本为lua语言，则插件化探针直接执行该故障处理脚本即可；若故障处理脚本非lua语言(即非目标lua脚本)，则插件化探针执行该挂载处理脚本需在对应的运行时环境下执行该故障处理脚本。也就是说上述步骤s104接收插件化探针执行故障处理脚本后发送的故障处理结果，具体包括：若故障处理脚本非lua语言，则接收插件化探针在运行时环境下执行故障处理脚本后发送的故障处理结果。

在本申请的一种具体实施方式中，考虑到不同的被控制终端可能会因其个性化的特征，导致即便是同一个故障处理脚本，对应的故障处理效果也会有差异。因而，在本实施例中，可针对同一种故障类型，设置不同的故障处理脚本，以便在一个故障处理脚本执行后未能解决相关故障问题的情况下，还可继续执行该故障类型对应的其他故障处理脚本继续解决该故障问题，以提高排障成功率。具体的实现过程，即在执行上述步骤s104，在接收插件化探针执行故障处理脚本后发送的故障处理结果之后，若故障处理结果对应故障处理失败，则从规则脚本库中重新找出与故障类型对应的故障处理脚本，并发送给插件化探针。对于重新找出的与故障类型对应的故障处理脚本，将其发送给插件化探针之后，对应的处理流程可参照上述实施例的具体实现，在此不再一一赘述。

在本申请中的一种具体实施方式中，考虑到故障类型不可能全部已知，且已知故障的解决方式也可以进行优化或补充，因而提出对规则脚本库进行补充更新的方案。具体的实现过程，包括：

步骤一、在规则脚本库中未找出与故障类型对应的故障处理脚本的情况下，输出无对应处理脚本的提示信息；

步骤二、获取新故障处理脚本，并将新故障处理脚本发送给插件化探针；

步骤三、接收插件化探针执行新故障处理脚本后发送的处理结果；

步骤四、若处理结果对应成功解决故障，则将新故障处理脚本确定为故障类型对应的故障处理脚本并存入规则脚本库中。

为便于描述，下面将上述四个步骤结合起来进行说明。

当在规则脚本库中没有找到与故障类型对应的故障处理脚本的情况下，可对外输出无对应处理脚本的提示信息。排障人员在看见该提示信息的情况下，可针对该故障编写对应的新故障处理脚本，可通过上传等方式将其反馈给排障引擎。排障引擎便可得到该新故障处理脚本。

排障引擎得到新故障处理脚本之后，可将其发送给目标终端中的插件化探针。插件化探针接收到该新故障处理脚本之后，可参照上述实施例的描述，执行该新故障处理脚本，并反馈处理结果。

排障引擎在接收到处理结果之后，若该处理结果对应车管解决故障，可将该新故障处理脚本确定为故障类型对应的故障处理脚本，并将其保存到规则脚本库中。如此，在下一次目标终端或其他被管理终端出现同类型的故障时，便可利用该故障处理脚本进行故障处理。

即在本实施例中，在无需更新排障引擎，无需对排障引擎打补丁的情况下，仅通过增加新的故障处理脚本并进行执行处理，在成功解决故障的情况下，便可将新的故障处理脚本收纳进规则脚本库中，对规则脚本库进行更新扩充，以应对更多、更新的故障问题。

本申请还提供了一种与上述故障处理方法相对应的另一种故障处理方法，两种故障处理方法可相互参照。具体的，请参考图2，图2为本申请实施例所提供的另一种故障处理方法，该方法可应用于插件化探针中，该插件化探针可以为集成了运行时环境的探针，也可以为未集成运行时环境的探针。

具体的，插件化探针是集成了运行时环境、支持执行插件化类型的脚本的程序，插件化类型的脚本包括lua脚本、python脚本、ruby脚本、shell脚本、perl脚本中的一种或多种的组合，程序包括代理程序、应用程序、进程或者服务。若插件化类型的脚本为lua脚本，则插件化探针无需预先配置脚本运行环境。

若插件化类型的脚本为python脚本、ruby脚本、shell脚本或perl脚本，则插件化探针需要预先配置脚本运行环境。

下面以插件化探针，即对现有探针进行改进，预先对探针布置了运行时环境为例进行说明。即，在本实施例中，使得探针支持插件化脚本，从而可以在接收到来自排障引擎的相关脚本(如故障检测脚本、故障处理脚本)后，能够直接执行脚本，实现故障排查/处理的目的。具体的，该方法包括：

s201、在目标终端发生故障后，目标终端中的插件化探针接收排障引擎发送的故障处理脚本。

其中，故障处理脚本为排障引擎从多个被管理终端中确定出发生故障的目标终端及故障类型后，所获取的与故障类型对应的故障处理脚本。

s202、执行故障处理脚本。

其中，插件化探针集成了运行时环境，在无需要配置脚本运行环境的情况下，直接执行故障处理脚本。

本申请实施例中所描述的插件化探针，是一种部署在目标终端中的代理程序(agent)、运行在虚拟机中的应用程序、进程或服务等，可接收数据(如故障检测脚本、故障处理脚本)，执行脚本以及发送数据。在本实施例中，被管理终端上均有对应的插件化探针。

排障引擎将故障处理脚本发送给目标终端中的插件化探针。也就是说，插件化探针实现目标终端与排障引擎之间的通信。

插件化探针接收到故障处理脚本之后，便可执行该故障处理脚本，从而对故障进行处理。

s203、向排障引擎反馈故障处理结果。

在本方法中，利用目标终端中的插件化探针便可实现故障处理脚本的接收与执行，并得到故障处理结果。由于处理目标终端的故障是利用故障处理脚本进行，因而，可根据不同的故障类型设置对应的故障处理脚本，可灵活应对多种故障类型；且当有新型故障产生后，仅通过增加对应的故障处理脚本，即可对应解决新型故障，而无需对排障引擎进行打补丁或升级；插件化探针位于被管理终端，即处理各个目标终端的故障时，在各个目标终端接收到故障处理脚本的情况下，自行执行并处理故障，因此，排障引擎可以批量向多个目标终端发送故障处理脚本，可实现批量处理故障。由此可见，本方法应用于插件化探针中，能够有效提升排障引擎的灵活性，能够灵活应对不同的排障需求。

在本申请中的一种具体实施方式中，为便于排障引擎发现故障，还可执行以下步骤：

步骤一、定期获取目标终端的运行状态数据；

步骤二、将运行状态数据发送给排障引擎。

为便于说明，下面将上述两个步骤结合起来进行说明。

即，插件化探针主动定期搜集虚拟机(即其所在的被管理终端)运行状态数据。该运行状态数据对应运行的相关数据，如运行状态，参数变化，日志等。插件化探针将运行状态数据上传给排障引擎供分析，排障引擎基于这些信息分析/核实是否发生故障，以及故障类型。具体的，对于排障引擎如何确定故障以及故障类型可具体参照相关故障检测算法，在此不再一一赘述。

排障引擎接收到故障检测结果之后，便可基于该故障检测结果从管理终端中确定出发生故障的目标终端以及故障类型。在本实施例中，对故障类型的具体数量和种类不做限定。

在本申请中的一种具体实施方式中，为便于排障引擎发现故障，还可执行以下步骤：

步骤一、接收排障引擎发送的故障检测脚本；

步骤二、执行故障检测脚本，得到故障检测结果；

步骤三、将故障检测结果发送给排障引擎。

为便于说明，下面将上述三个步骤结合起来进行说明。

其中，故障检测脚本可以具体为采用lua语言编写的能够检测故障的脚本，当然也可以为其他编程语言编写的能够检测故障的脚本。其中，lua是一个简洁、轻量、可扩展的程序设计语言，其设计目的是为了嵌入应用程序中，从而为应用程序提供灵活的扩展和定制功能。lua由标准c编写而成，几乎在所有操作系统和平台上都可以编译，运行，它还可以提供在特定平台上的即时编译功能。需要注意的是，插件化探针由于集成了lua脚本的运行时环境，因而插件化探针接收到故障检测脚本后，在执行由lua语言编写的脚本时，可无需设置运行时环境。对于故障检测脚本的具体逻辑可具体参见相关故障检测流程，在此不再一一赘述。

插件化探针运行故障检测脚本后，便可得到故障检测结果，并发送给排障引擎。

相应于上面的方法实施例，本申请实施例还提供了一种排障引擎，下文描述的排障引擎与上文描述的故障处理方法可相互对应参照。

参见图3所示，该排障引擎包括以下模块：

故障确定模块101，用于从多个被管理终端中确定出发生故障的目标终端及故障类型；

脚本获取模块102，用于获取与故障类型对应的故障处理脚本；

脚本发送模块103，用于将故障处理脚本发送至目标终端中的插件化探针；

结果接收模块104，用于接收插件化探针执行故障处理脚本后发送的故障处理结果。

应用本申请实施例所提供的排障引擎，从多个被管理终端中确定出发生故障的目标终端及故障类型；获取与故障类型对应的故障处理脚本；将故障处理脚本发送至目标终端中的插件化探针；接收插件化探针执行故障处理脚本后发送的故障处理结果。

在本排障引擎中，利用目标终端中的插件化探针便可实现故障处理脚本的接收与执行，并得到故障处理结果。由于处理目标终端的故障是利用故障处理脚本进行，因而，可根据不同的故障类型设置对应的故障处理脚本，可灵活应对多种故障类型，并且目标终端中的探针为插件化探针，能够使得探针支持插件化脚本。即当有新型故障产生后，仅通过增加新型故障对应的故障处理脚本，即可对应解决新型故障，而无需对排障引擎或者探针进行打补丁或升级。具体的，插件化探针位于被管理终端，即处理各个目标终端的故障时，在各个目标终端接收到故障处理脚本的情况下，自行执行并处理故障，因此，排障引擎可以批量向多个目标终端发送故障处理脚本，可实现批量处理故障。由此可见，本排障引擎应用于排障引擎中，能够有效提升排障引擎的灵活性，能够灵活应对不同的排障需求。

在本申请的一种具体实施方式中，插件化探针是集成了运行时环境、支持执行插件化类型的脚本的程序，插件化类型的脚本包括lua脚本、python脚本、ruby脚本、shell脚本、perl脚本中的一种或多种的组合，程序包括代理程序、应用程序、进程或者服务。

在本申请的一种具体实施方式中，若插件化类型的脚本为lua脚本，则插件化探针无需预先配置脚本运行环境。

在本申请的一种具体实施方式中，若插件化类型的脚本为python脚本、ruby脚本、shell脚本或perl脚本，则插件化探针需要预先配置脚本运行环境。

在本申请的一种具体实施方式中，被管理终端包括虚拟机和物理机中的至少一种。

在本申请的一种具体实施方式中，脚本获取模块102，具体用于从规则脚本库中找出与故障类型对应的故障处理脚本。

在本申请的一种具体实施方式中，若插件化类型的脚本包括lua脚本，相应地，脚本获取模块102，具体用于从规则脚本库中，找出与故障类型对应的目标lua脚本，并将目标lua脚本确定为故障处理脚本；在未找到目标lua脚本的情况下，找出非lua语言中与故障类型对应的故障处理脚本。

在本申请的一种具体实施方式中，结果接收模块104，具体用于若故障处理脚本非目标lua脚本，则接收插件化探针在运行时环境下执行故障处理脚本后发送的故障处理结果。

在本申请的一种具体实施方式中，故障确定模块101，具体用于向被管理终端中的插件化探针发送故障检测脚本；接收插件化探针执行故障检测脚本后发送的故障检测结果；利用故障检测结果，从多个被管理终端中确定出发生故障的目标终端及故障类型。

在本申请的一种具体实施方式中，故障确定模块101，具体用于接收故障反馈信息；利用故障反馈信息，从多个被管理终端中确定出目标终端和故障类型。

在本申请的一种具体实施方式中，故障确定模块101，具体用于接收各个被管理终端中的插件化探针定期反馈的运行状态数据；利用运行状态数据，从多个被管理终端中确定出目标终端和故障类型。

在本申请的一种具体实施方式中，还包括：

重试模块，用于在接收插件化探针执行故障处理脚本后发送的故障处理结果之后，若故障处理结果对应故障处理失败，则从规则脚本库中重新找出与故障类型对应的故障处理脚本，并发送给插件化探针。

在本申请的一种具体实施方式中，还包括：

规则脚本库扩展模块，用于在规则脚本库中未找出与故障类型对应的故障处理脚本的情况下，输出无对应处理脚本的提示信息；获取新故障处理脚本，并将新故障处理脚本发送给插件化探针；接收插件化探针执行新故障处理脚本后发送的处理结果；若处理结果对应成功解决故障，则将新故障处理脚本确定为故障类型对应的故障处理脚本并存入规则脚本库中。

相应于上面的方法实施例，本申请实施例还提供了一种插件化探针，下文描述的插件化探针与上文描述的故障处理方法可相互对应参照。

请参考图4，该插件化探针包括：

脚本接收模块201，用于在目标终端发生故障后，接收排障引擎发送的故障处理脚本；故障处理脚本为排障引擎从多个被管理终端中确定出发生故障的目标终端及故障类型后，所获取的与故障类型对应的故障处理脚本；

脚本执行模块202，用于执行故障处理脚本；

结果反馈模块203，用于向排障引擎反馈故障处理结果。

在本插件化探针中，利用目标终端中的插件化探针便可实现故障处理脚本的接收与执行，并得到故障处理结果。由于处理目标终端的故障是利用故障处理脚本进行，因而，可根据不同的故障类型设置对应的故障处理脚本，可灵活应对多种故障类型；且当有新型故障产生后，仅通过增加对应的故障处理脚本，即可对应解决新型故障，而无需对排障引擎进行打补丁或升级；插件化探针位于被管理终端，即处理各个目标终端的故障时，在各个目标终端接收到故障处理脚本的情况下，自行执行并处理故障，因此，排障引擎可以批量向多个目标终端发送故障处理脚本，可实现批量处理故障。由此可见，本插件化探针应用于插件化探针中，能够有效提升排障引擎的灵活性，能够灵活应对不同的排障需求。

在本申请的一种具体实施方式中，插件化探针集成了运行时环境，在无需要配置脚本运行环境的情况下，直接执行故障处理脚本。

在本申请的一种具体实施方式中，还包括：

运行状态数据获取与反馈模块，用于定期获取目标终端的运行状态数据；将运行状态数据发送给排障引擎。

在本申请的一种具体实施方式中，还包括：

故障检测与反馈模块，用于接收排障引擎发送的故障检测脚本；执行故障检测脚本，得到故障检测结果；将故障检测结果发送给排障引擎。

为便于本领域技术人员更好地理解本申请所提供的技术方案，下面结合具体的应用场景为例，对本申请所提供的排障引擎和插件化探针，具体如何共同完成故障处理进行详细说明。

请参考图5，故障处理涉及以下内容：

1、初始化排障引擎和插件化探针。

其中，插件化探针，也就是安装在虚拟机里面的agent，确认待排查虚拟机安装上插件化探针即可。即，插件化探针则提供接收lua脚本和执行lua脚本的能力，主要对应排障的经验规则，如cpu持续占用超过90％可能会引起虚拟机卡顿等。

排障引擎即位于服务端的调度和分析引擎，主要负责规则脚本的管理、分发、收集以及结果展示。当然，排障引擎在被管理端也可以布置。

排障引擎则提供排障结果的接收能力，问题、警告、解决方案会在可视化界面中显示。当然，还可以单独设置告警引擎，以提供排障结果的接收能力，问题、警告、解决方案也可以单独在告警引擎中显示。

2、规则初始化。

预定义规则可以是已知的专家经验，这部分经验固化成lua脚本(程序，解决方案的具体处理方式，一个lua脚本对应一种技术问题，或，多个不同luau脚本对应同一个技术问题)，可随时被排障引擎调度和下发。

3、扫描故障虚拟机。

故障排查有3种方式：

方式1：一种是用户反馈虚拟机卡，管理员或运维人员被动的排查这台虚拟机的问题。

方式2：管理员直接全局检查哪些虚拟机可能有故障，提前预警或执行修复操作。

方式3：插件化探针自行检测所对应的虚拟机的运行状态数据并反馈给排障引擎，以确定故障。或，插件化探针执行排障引擎发送的故障检测脚本，得到故障检测结果并反馈给排障引擎。

其中，预定义的脚本会通过手动或自动的方式下发给待排查的虚拟机，并依次执行。一旦有问题，插件化探针会反馈给告警引擎。如果预定义脚本没有扫描到问题，而用户始终反馈有故障，那么可以通过排障专家的技术素养，通过下发新的故障处理脚本来解决这个问题。

即，排障引擎相当于一个平台，提供了处置问题的能力；而这些规则脚本(故障处理脚本)，则相当于一项一项的执行器，来确保虚拟机的故障排查过程。

4、上报和解决问题。

插件化探针实现了插件化脚本和告警引擎之间的联动。一旦预定义脚本或自定义脚本实现了问题的排查，则会将方案上报到排障引擎，排障引擎负责展示故障问题、解决方案，实现问题的收敛。

同时，有效的方案可以直接标记为模板，成为新增的预定义脚本。具体的实现过程可具体参照图8所示(其中，被管理端可以是安装有插件化探针的物理机，也可以是安装有插件化探针的虚拟机，管理端可以具体为服务器，也可以为由虚拟机运载的管理平台，在图8中仅绘制了服务器中的排障引擎与一个被管理端中的插件化探针的交互实现过程，服务器中的排障引擎与其他被管理端中的插件化探针的交互实现过程可参照该具体实现过程)，对于排障引擎和插件化探针的具体执行步骤可参照上述实施例中应用于排障引擎的故障处理方法，以及应用于插件化探针的拍照引擎的故障处理方法。

如此，在使用时间和应用范围增多的情况下，经验库会越来越强大，排障能力会越来越强。

批量排查虚拟机故障示例：假设进程virus.exe是一个不断复制的病毒进程，虚拟机会因为其消耗资源的不断上涨而卡慢，严重影响业务运行。此时，可以定义一条删除进程的脚本规则，通过post请求，批量下发给所有虚拟机，插件化探针会调用这个脚本，将病毒进行删除或者进程停止。由于插件化探针已经集成了runtime环境(运行时环境)，因此不需要配置脚本运行的环境。同理，linux虚拟机也一样适用。

另外，也可以将插件化脚本替换成windows批处理脚本或linuxshell(linux脚本)脚本，实现下发与运行。但这种实现方式，必须具备运行时环境(linuxshell对应的运行环境)。比如，检测虚拟机的总内存使用情况，对于linux和windows平台，批处理脚本和shell脚本对应2种不同的写法。

需要注意的是，图8仅作为用于理解本申请方案的示例，在具体实现中，各个被管理终端可以是运行在服务器或者集群中的虚拟机，插件化探针是布局在虚拟机中的软件程序、进程、服务等，排障引擎可以是运行在服务器或者集群中的管理模块或者管理平台，排障引擎可与各虚拟机进行通信。从物理形态上看，排障引擎和被管理终端可能运行在相同服务器，也可能在不同服务器，本申请不做限定。

相应于上面的方法实施例，本申请实施例还提供了两种电子设备，下文描述的电子设备与上文描述的两种故障处理方法可相互对应参照。

参见图6所示，两种电子设备的结构均包括：

存储器332，用于存储计算机程序；

处理器322，用于执行计算机程序时实现上述方法实施例的故障处理方法的步骤。

具体的，请参考图7，图7为本实施例提供的电子设备的具体结构示意图，该电子设备可因配置或性能不同而产生比较大的差异，可以包括一个或一个以上处理器(centralprocessingunits，cpu)322(例如，一个或一个以上处理器)和存储器332，存储器332存储有一个或一个以上的计算机应用程序342或数据344。其中，存储器332可以是短暂存储或持久存储。存储在存储器332的程序可以包括一个或一个以上模块(图示没标出)，每个模块可以包括对数据处理设备中的一系列指令操作。更进一步地，中央处理器322可以设置为与存储器332通信，在电子设备301上执行存储器332中的一系列指令操作。

电子设备301还可以包括一个或一个以上电源326，一个或一个以上有线或无线网络接口350，一个或一个以上输入输出接口358，和/或，一个或一个以上操作系统341。

上文所描述的故障处理方法中的步骤可以由电子设备的结构实现。

相应于上面的方法实施例，本申请实施例还提供了一种可读存储介质，下文描述的一种可读存储介质与上文描述的一种故障处理方法可相互对应参照。

一种可读存储介质，可读存储介质上存储有计算机程序，计算机程序被处理器执行时实现上述方法实施例的故障处理方法的步骤。

该可读存储介质具体可以为u盘、移动硬盘、只读存储器(read-onlymemory，rom)、随机存取存储器(randomaccessmemory，ram)、磁碟或者光盘等各种可存储程序代码的可读存储介质。

本领域技术人员还可以进一步意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。本领域技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。