CN113312202B - 基于组件的故障处理逻辑生成方法、装置、设备和介质 - Google Patents

Abstract

本申请涉及一种基于组件的故障处理逻辑生成方法、装置、设备和介质。所述方法包括：接收故障处理逻辑生成请求，并基于所述故障处理逻辑生成请求获取预先生成的组件；接收针对所述组件的操作指令，并根据所述操作指令将所选择的组件进行连接；当所述组件需要输入控制参数时，则锁定所述组件的连接操作，并输出控制参数输入提示，并接收所输入的控制参数后，释放所述组件的连接操作；当所述组件连接完成后，则将所连接完成的组件发送至后端，以使得所述后端根据连接完成的组件生成故障处理逻辑，所述故障处理逻辑用于发送至控制端，以使得所述控制端根据所述故障处理逻辑控制对应的主机执行所述故障处理逻辑。采用本方法能够灵活生成故障处理逻辑。

Description

基于组件的故障处理逻辑生成方法、装置、设备和介质

技术领域

本申请涉及运维技术领域，特别是涉及一种基于组件的故障处理逻辑生成方法、装置、设备和介质。

背景技术

随着人工智能技术的发展，出现了智能运维技术，该智能运维技术超项运维自动化和智能化方向发展。其中，自动化对IT运维的影响，已经不仅仅是人与设备之间的关系，已经发展到了面向客户服务驱动IT运维决策的层面，IT运维团队的构成，也从各级技术人员占大多数发展到业务人员甚至用户占大多数的局面。

然而，传统技术中自动化运维需要单独编写对应的脚本，然后进行调试后才能使用，这样导致脚本需要修改的时候，需要重新查看脚本，并充分理解脚本逻辑后才能进行调整，耗费大量的时间。

发明内容

基于此，有必要针对上述技术问题，提供一种能够灵活生成故障处理逻辑的基于组件的故障处理逻辑生成方法、装置、设备和介质。

一种基于组件的故障处理逻辑生成方法，应用于前端，所述方法包括：

接收故障处理逻辑生成请求，并基于所述故障处理逻辑生成请求获取预先生成的组件；

接收针对所述组件的操作指令，并根据所述操作指令将所选择的组件进行连接；

当所述组件需要输入控制参数时，则锁定所述组件的连接操作，并输出控制参数输入提示，并接收所输入的控制参数后，释放所述组件的连接操作；

当所述组件连接完成后，则将所连接完成的组件发送至后端，以使得所述后端根据连接完成的组件生成故障处理逻辑，所述故障处理逻辑用于发送至控制端，以使得所述控制端根据所述故障处理逻辑控制对应的主机执行所述故障处理逻辑。

在其中一个实施例中，所述组件包括开始组件、结束组件、判断组件、作业组件、子流程组件、并行组件、合并组件和控制组件中的至少一个；

所述作业组件用于调用所述控制端的接口，传递故障处理逻辑，并指示所述控制端将所述故障处理逻辑分发给对应的主机执行；

所述子流程组件用于调用已存储的故障处理逻辑。

一种故障处理方法，所述故障处理方法采用上述的基于组件的故障处理逻辑生成方法所生成的故障处理逻辑，应用于控制端，所述故障处理方法包括：

接收故障处理请求，所述故障处理请求携带有故障处理标识；

根据所述故障处理标识查询对应的故障处理信息，并基于所述故障处理信息判断是否进行熔断；

当基于所述故障处理信息判定不需要进行熔断时，则控制主机基于所述故障处理逻辑执行对应的信息检测；

若所述信息检测存在故障，则基于所述故障处理逻辑执行对应的故障自愈处理步骤。

在其中一个实施例中，所述基于所述故障处理信息判断是否进行熔断，包括：

判断预设时间段中所述故障处理请求的次数是否超过预设次数，或者

判断所述故障处理请求所对应的用户权限是否正确，或者

判断所述故障处理请求对应的故障处理逻辑、应用以及主机所属业务属主是否一致。

在其中一个实施例中，所述控制主机基于所述故障处理逻辑执行对应的信息检测，包括：

基于所述故障处理逻辑执行对应的信息检测，并基于所述故障处理逻辑中的三元运算符判断所述故障处理逻辑中的分支流向，以确定下一信息检测的流程，直至所述故障处理逻辑执行完成。

在其中一个实施例中，所述控制主机基于所述故障处理逻辑执行对应的信息检测之前，还包括：

根据所述故障处理信息调用预设接口获取对应的主机。

一种告警处理方法，所述告警处理方法包括：

接收监控系统发送的告警信息；

通过预设告警规则对所述告警信息进行清洗得到需要自动处理的待处理告警信息；

将所述告警信息分配至对应的控制端，以使得所述控制端根据上述任一实施例中的故障处理方法对所述告警信息对应的故障进行处理。

在其中一个实施例中，所述通过预设告警规则对所述告警信息进行清洗得到需要自动处理的待处理告警信息，包括：

基于屏蔽策略判断所述告警信息是否为预设系统的告警信息，以对所述告警信息进行清洗得到需要自动处理的待处理告警信息；和/或

基于收敛策略根据处理时间间隔对所述告警信息进行清洗得到需要自动处理的待处理告警信息。

一种基于组件的故障处理逻辑生成装置，应用于前端，所述基于组件的故障处理逻辑生成装置包括：

第一接收模块，用于接收故障处理逻辑生成请求，并基于所述故障处理逻辑生成请求获取预先生成的组件；

第二接收模块，用于接收针对所述组件的操作指令，并根据所述操作指令将所选择的组件进行连接；

组件操作模块，用于当所述组件需要输入控制参数时，则锁定所述组件的连接操作，并输出控制参数输入提示，并接收所输入的控制参数后，释放所述组件的连接操作；

逻辑生成模块，用于当所述组件连接完成后，则将所连接完成的组件发送至后端，以使得所述后端根据连接完成的组件生成故障处理逻辑，所述故障处理逻辑用于发送至控制端，以使得所述控制端根据所述故障处理逻辑控制对应的主机执行所述故障处理逻辑。

一种计算机设备，包括存储器和处理器，所述存储器存储有计算机程序，所述处理器执行所述计算机程序时实现上述任一实施例中所述的方法的步骤。

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

上述基于组件的故障处理逻辑生成方法、装置、设备和介质，通过前端交互式设计，编制故障处理逻辑，后端实现控制层逻辑，提供接口服务，并调用位于应用主机上的客户端，实现远程流程化控制，进而进行故障自动化处理，且由于前端是基于组件的交互式设计，因此在修改的时候，则仅需要调整组件即可，不需要耗费大量的时间，灵活修改。

附图说明

图1为一个实施例中基于组件的故障处理逻辑生成方法的应用环境图；

图2为一个实施例中基于组件的故障处理逻辑生成方法的流程示意图；

图3为一个实施例中故障处理方法的流程示意图；

图4为一个实施例中的故障处理逻辑的示意图；

图5为一个实施例中告警处理方法的流程示意图；

图6为一个实施例中告警处理方法的多端处理流程图；

图7为另一个实施例中的告警处理方法的流程图；

图8为一个实施例中基于组件的故障处理逻辑生成装置的结构框图；

图9为一个实施例中故障处理装置的结构框图；

图10为一个实施例中告警处理装置的结构框图；

图11为一个实施例中计算机设备的内部结构图。

具体实施方式

为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行进一步详细说明。应当理解，此处描述的具体实施例仅仅用以解释本申请，并不用于限定本申请。

本申请提供的基于组件的故障处理逻辑生成方法，可以应用于如图1所示的应用环境中。其中前端102通过网络与后端104通信，后端104通过网络与控制端106通信，控制端106通过网络与主机108相通信。其中前端102接收故障处理逻辑生成请求，并基于故障处理逻辑生成请求获取预先生成的组件；接收针对组件的操作指令，并根据操作指令将所选择的组件进行连接；当组件需要输入控制参数时，则锁定组件的连接操作，并输出控制参数输入提示，并接收所输入的控制参数后，释放组件的连接操作；当组件连接完成后，则将所连接完成的组件发送至后端104，这样后端104根据连接完成的组件生成故障处理逻辑，故障处理逻辑用于发送至控制端106，以使得控制端106根据故障处理逻辑控制对应的主机108执行故障处理逻辑。其中，前端102可以但不限于是各种个人计算机、笔记本电脑、智能手机、平板电脑和便携式可穿戴设备，后端104、控制端106以及主机108可以用独立的服务器或者是多个服务器组成的服务器集群来实现。

在一个实施例中，如图2所示，提供了一种基于组件的故障处理逻辑生成方法，以该方法应用于图1中的前端为例进行说明，包括以下步骤：

S202：接收故障处理逻辑生成请求，并基于故障处理逻辑生成请求获取预先生成的组件。

首先故障处理逻辑是指用于对故障进行处理的控制流程，其可以检测主机是否存在故障，并基于控制流程对主机中存在的故障进行治愈。

组件包括开始组件、结束组件、判断组件、作业组件、子流程组件、并行组件、合并组件和控制组件中的至少一个，该些组件在前端页面可以进行拖拽，以供用户进行调整，从而生成对应的故障处理逻辑。

其中，开始组件、结束组件作为故障处理逻辑开始、结束的标识，前端通过标识符实现；判断组件通过前端if判断实现，if可以出现任意多次，else可以出现0次或1次；作业组件调用控制端的标准接口，传递需要执行的命令、脚本等，由控制端分发给主机执行，主机将执行结果返回控制端、后端控制逻辑层；子流程组件为调用已保存的其他控制流程；并行组件产生多个分支，并行执行；合并组件所有执行任务的分支，全部汇聚后才能进入后续流程；控制组件可以进行忽略错误，暂停、跳过、重试等操作。

通过组件拖拽的方式，绘制流程。判断组件需要手动添加if判断条件，作业组件需要手动录入作业脚本，合并组件要求所有并行分支同时返回后才可以到达下一个组件。

S204：接收针对组件的操作指令，并根据操作指令将所选择的组件进行连接。

具体地，组件的操作指令是指输入的用于拖拽组件，以确定组件的位置以及修改组件中的参数的指令，前端根据操作指令将所选择的组件与已经处理完成的组件进行连接，从而形成故障处理逻辑。

S206：当组件需要输入控制参数时，则锁定组件的连接操作，并输出控制参数输入提示，并接收所输入的控制参数后，释放组件的连接操作。

具体地，控制参数是指该组件需要对应的参数，以实现流程流向的判断，例如判断组件的if判断条件，作业组件的作业脚本等，再未输入至对应的控制参数之前，锁定连接操作，待用户输入了控制参数后，确定了流程走向，则释放连接操作，以确定故障处理逻辑的走向。

S208：当组件连接完成后，则将所连接完成的组件发送至后端，以使得后端根据连接完成的组件生成故障处理逻辑，故障处理逻辑用于发送至控制端，以使得控制端根据故障处理逻辑控制对应的主机执行故障处理逻辑。

具体地，后端工程师完成后端的主要业务逻辑，给前端提供接口和数据，接收前端传来的脚本、文件及执行用户、变量等参数，并调用控制端接口，通过控制端将任务分发给主机。主机任务执行结果及标准输出回传给控制端，并通过控制端返回给后端，最终返回给前端。前端将执行时的标准输出显示给用户，将结果传给判断组件，确定流程走向。

其中，Master，即控制端与agent，即主机之间使用了Zeromq的通讯与数据传输方式。控制端将作业发送给主机时使用zeromq的pub/sub套接字实现，所有传输的数据都会进行加密处理，只有主机成员才能解密发布的消息。主机将数据回传给控制端时使用zeromq的req/rep套接字实现，此接口主要用于作业结果及作业执行时的标准输出的回传。

上述实施例中，在主机安装agent，实现与控制端的master通讯，通过master在agent端远程执行命令。在浏览器上，通过组件拖拽、脚本编写及逻辑配置，编制故障处理逻辑，制定故障自动处理策略。

上述基于组件的故障处理逻辑生成方法，通过前端交互式设计，编制故障处理逻辑，后端实现控制层逻辑，提供接口服务，并调用位于应用主机上的客户端，实现远程流程化控制，进而进行故障自动化处理，且由于前端是基于组件的交互式设计，因此在修改的时候，则仅需要调整组件即可，不需要耗费大量的时间，灵活修改。

此外，无需在服务器上步骤脚本，流程通用，差异化信息在应用zho配置管理中心进行配置与管理，使用流程控制进行故障处理，比较灵活，易于调整；降低服务器上的资源消耗，无需定时巡检应用是否正常。

在一个实施例中，如图3所示，提供了一种故障处理方法，故障处理方法采用上述任一实施例中的基于组件的故障处理逻辑生成方法所生成的故障处理逻辑，以该方法应用于图1中的控制端为例进行说明，包括以下步骤：

S302：接收故障处理请求，故障处理请求携带有故障处理标识。

具体地，故障处理请求可以是业务员发送的，或者是系统自动生成的。故障处理标识是则是用于指示所需要处理的故障或者是所需要检测的应用的标识，其具有唯一性。

S304：根据故障处理标识查询对应的故障处理信息，并基于故障处理信息判断是否进行熔断。

具体地，熔断是判断指定时间段内是否触发次数超过限制，执行用户是否越权，业务属主是否一致等，若触发熔断，发送通知，流程结束。其中这里的熔断是为了避免流程执行次数过多，越权是通过熔断里的脚本执行是否成功来判断是否越权及业务属主是否一致。

具体地，熔断可以包括：判断预设时间段中故障处理请求的次数是否超过预设次数，或者判断故障处理请求所对应的用户权限是否正确，或者判断故障处理请求对应的故障处理逻辑、应用以及主机所属业务属主是否一致。

也就是说熔断主要可以包括以下触发项：次数限制：指定时间段内触发次数是否超过设定值，这样可以避免多次触发，使得系统出现问题，例如避免因主机故障、网络异常等原因导致应用层面的故障自动处理重复执行。业务属主是否一致：必须保证流程、应用、主机所属业务属主一致，这样可以避免因配置错误导致流程意外触发等。是否越权：指定的用户是否具有应用启停权限，是否具有脚本执行权限，相关路径权限等，这样可以避免越权操作。

S306：当基于故障处理信息判定不需要进行熔断时，则控制主机基于故障处理逻辑执行对应的信息检测。

具体地，信息检测可以包括但不限于主机资源检测、端口检测以及应用检测等。

具体地，请参照图4所示，图4为一个实施例中的故障处理逻辑的示意图，在该实施例中，首先进行熔断检测，若是触发熔断，则直接发送通知，流程结束。

若没有触发宋端，则进行后续的信息检测，如图4所示，其中包括主机资源检测、端口检测以及应用检测。包括主机资源检测，检查主机磁盘使用率是否超过95%，inodes值是否为100%，若超过阈值，发送通知，流程结束。

若是主机资源检测通过，则继续端口检测，检测告警端口的端口状态，down状态，直接进入下一步启动进程；up状态进入下一步应用检测。

在端口检测为up状态，则继续进行应用检测，使用告警端口对应的应用检测脚本检测应用是否正常，若应用异常则进入下一步，强制结束应用进程。若应用正常，则发送通知，流程结束。在结束应用进程中，使用告警端口对应的启动脚本停止进程。然后启动进程，使用告警端口对应的启动脚本启动进程。这样再次检测告警端口是否恢复正常。若正常，进行应用健康检测，若异常，发送通知。若端口检测正常，则再次检测告警端口对应的应用是否恢复正常。若异常，发送通知。这样最后还需要添加一次处理记录，以便于下次熔断进行判断。

S308：若信息检测存在故障，则基于故障处理逻辑执行对应的故障自愈处理步骤。

具体地，结合图4所示，其中在端口检测的状态为端口down时，即存在故障时，则启动进程，即重新启动端口，以实现故障自愈。在应用检测异常时，先结束进程，然后启动进程，以实现故障自愈。

上述实施例中，提供了多实例应用故障的自动分析、自动处理方案，解决复杂场景下，多实例故障自愈困难的问题，且降低服务器上的资源消耗，无需定时巡检应用是否正常。

在其中一个实施例中，控制主机基于故障处理逻辑执行对应的信息检测，包括：基于故障处理逻辑执行对应的信息检测，并基于故障处理逻辑中的三元运算符判断故障处理逻辑中的分支流向，以确定下一信息检测的流程，直至故障处理逻辑执行完成。

具体地，整个流程的处理过程控制，每一步均需要远程执行命令并获取执行结果，并通过对执行结果判断，确定分支流向。远程执行命令通过调用master端接口向agent下发任务，并通过agent返回执行结果。分支流向判断通过三元运算符进行判断。三元运算符是软件编程中的一个固定格式，表达式为：操作数1

操作数2：操作数3，其中操作数1为bool类型，操作数2和操作数3为分支，若操作数1判定结果为真，则返回操作数2，若判定结果为假，则返回操作数3。参见图4所示，端口检测生产一个运行结果${_result}，该结果变量为bool类型，若${_result} == false则判定为端口down状态，上图中走端口down分支，直接发送通知；若${_result} == true，则判定为端口up状态，上图中走端口up分支，进行应用检测。

在其中一个实施例中，控制主机基于故障处理逻辑执行对应的信息检测之前，还包括：根据故障处理信息调用预设接口获取对应的主机。

具体地，控制端，根据流程传入的参数IP，调用CMDB接口，传入IP参数，获取本IP绑定的主机所在的网络区域、主机类型等；从应用配置管理中心获取本IP所属应用，并获取多实例的应用信息，返回结果为一个json文件，格式为：

{

“port1”:

{

“port_check”: “port check command”,

“stop”: “application start command or start scripts”,

“start”: “application start command or start scripts”

},

“port2”:

{

“port_check”: “port check command”,

“stop”: “application start command or start scripts”,

“start”: “application start command or start scripts”

},

...

}

其中，port1、port2为应用启动后监听的端口，”port check command”为检测端口是否启动的命令，”application start/stop command or start scripts”为应用的启动、停止命令或脚本。

在本实施例中，结合图4，对本实施例进行详细的介绍，首先控制端在接收到故障处理请求后，则先根据故障信息进行熔断检测，若是熔断检测通过，则继续获取应用信息，在获取成功后，则进行主机资源检测、端口检测以及应用检测等。且在端口检测出现故障时，则启动进程，以实现对端口自愈，应用检测出现问题，则先结束端口进程，然后重新启动后，再次进行端口检测和应用检测。

这样降低服务器上的资源消耗，无需定时巡检应用是否正常。

在一个实施例中，如图5所示，提供了一种告警处理方法，以该方法应用于图1中的后端或者是另外的告警中心为例进行说明，包括以下步骤：

S502：接收监控系统发送的告警信息。

具体地，监控系统包括各种监控系统，其用于监控各个主机的状态等，并根据主机状态判断是否生成告警信息，若是生成告警信息，则将告警信息发送至告警中心。企业级监控种类繁多，覆盖面全，定位精准，一般采用统一的告警出口。各类监控系统将产生的告警统一推送至告警中心。

S504：通过预设告警规则对告警信息进行清洗得到需要自动处理的待处理告警信息。

具体地，对预设告警规则是预先设置的，其目的是为了识别出需要自动处理的待处理告警信息。具体地通过预设告警规则对告警信息进行清洗得到需要自动处理的待处理告警信息，包括：基于屏蔽策略判断告警信息是否为预设系统的告警信息，以对告警信息进行清洗得到需要自动处理的待处理告警信息；和/或基于收敛策略根据处理时间间隔对告警信息进行清洗得到需要自动处理的待处理告警信息。

其中，告警中心统一展示各类告警，进行告警收敛、分派，配置自动处理规则等。

S506：将告警信息分配至对应的控制端，以使得控制端根据上述任一实施例中的故障处理方法对告警信息对应的故障进行处理。

具体地，告警中心将告警信息分配至对应的控制端，自动化运维平台收取需要处理的告警信息，并通过CMDB获取主机及应用信息，如用户、IP地址、网络区域、应用部署路径、日志路径以及启停命令等。通过配置的控制流程，按照步骤调用作业中心进行作业，并根据返回的作业结果控制流程走向，如图6所示，CMDB包含主机管理、应用系统管理、用户管理、网络设备管理等。自动化运维平台从CMDB获取需要的配置信息。按照控制流程，依照步骤调用作业中心进行作业。作业中心可以调用主机执行命令，并将结果返回。可以是shell命令、python、perl脚本等。主机应用服务器，安装有作业中心的agent，可以通过作业中心远程在主机上执行命令。主机将命令或脚本的执行结果返回作业中心。作业中心本次作业的结果返回给自动化运维平台，自动化运维平台将本次告警自动处理的结果返回告警中心。告警中心更新告警状态。

上述告警信息处理方法，实现监控、告警中心、故障自愈、CMDB、作业平台等的协同工作，自动处理告警信息。

结合图7所示，图7为另一个实施例中的告警处理方法的流程图，告警中心接收到监控系统发送的告警信息后，首先对告警信息的格式进行处理，以对告警信息进行清洗，对于格式不符合要求的告警信息进行删除，然后通过预设告警规则对告警信息进行清洗，可供匹配的指标有以下几种：告警源、告警指标、告警名称、告警内容、告警级别、告警IP、告警名称。以上指标可以进行“或”和“与”的任意匹配，单个指标可以使用“包含”、“等于”、“正则”三种方式进行匹配，匹配成功后会根据设置的流程进行告警自动处理。其中在对上述指标进行匹配的时候，主要涉及到屏蔽策略匹配和收敛策略匹配，其中屏蔽策略可以是与系统相关的，例如设置一段时间内仅处理部分系统的告警信息，收敛策略则是由于告警信息通常是持续发送的，因此仅需要对其中一个进行处理即可，从而设置时间间隔，在一定时间间隔中仅处理第一个告警信息。

在对告警信息清洗完成后，则将告警信息与预设的处理策略匹配，若是需要自动处理，则将告警信息分配至对应的控制端，从而按照上述故障处理方法对告警信息对应的故障进行处理，并在处理成功后，切换告警状态。同样地，若是需要人工处理，则根据分配策略匹配对应的人，然后进行手工处理，若是根据分配策略未匹配到对应的人，则可以根据告警所属系统的组织架构进行匹配，以确定将告警信息分配给特定的人。

此外，在整个告警信息处理的过程中，每个步骤都需要提供统一的接口，并且从源头开始要打上唯一标识，整个过程中改标识均需要进行传递下去，直至返回最初的环节。所有接口除了传递每个环节运行所需的参数，还需要传递一些必要的标识信息，该标识信息可以包括：transaction id为唯一的事务id，由第一个环节生成；alarm id为告警id；system name为告警对应的应用名称；IP address为告警对应的ip地址；alarm source为告警源。

监控系统需要提供更新监控状态的接口；告警中心需要提供接收告警的接口，更新告警状态的接口；自动化运维平台需要提供接收告警的接口，调用标准流程的接口，接收作业中心返回的作业结果和作业输出及报错信息的接口；作业中心需要提供接收作业的接口，接收主机命令运行结果的接口；主机需要提供接收作业的接口；CMDB需要提供的各种主机信息接口、应用信息接口等。

上述实施例中实现监控、告警中心、故障自愈、CMDB、作业平台等的协同工作。

应该理解的是，虽然上述流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，这些步骤可以以其它的顺序执行。而且，上述流程图中的至少一部分步骤可以包括多个步骤或者多个阶段，这些步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，这些步骤或者阶段的执行顺序也不必然是依次进行，而是可以与其它步骤或者其它步骤中的步骤或者阶段的至少一部分轮流或者交替地执行。

在一个实施例中，如图8所示，提供了一种基于组件的故障处理逻辑生成装置，包括：第一接收模块120、第二接收模块140、组件操作模块160和逻辑生成模块180，其中：

第一接收模块120，用于接收故障处理逻辑生成请求，并基于故障处理逻辑生成请求获取预先生成的组件；

第二接收模块140，用于接收针对组件的操作指令，并根据操作指令将所选择的组件进行连接；

组件操作模块160，用于当组件需要输入控制参数时，则锁定组件的连接操作，并输出控制参数输入提示，并接收所输入的控制参数后，释放组件的连接操作；

逻辑生成模块180，用于当组件连接完成后，则将所连接完成的组件发送至后端，以使得后端根据连接完成的组件生成故障处理逻辑，故障处理逻辑用于发送至控制端，以使得控制端根据故障处理逻辑控制对应的主机执行故障处理逻辑。

在其中一个实施例中，组件包括开始组件、结束组件、判断组件、作业组件、子流程组件、并行组件、合并组件和控制组件中的至少一个；

作业组件用于调用控制端的接口，传递故障处理逻辑，并指示控制端将故障处理逻辑分发给对应的主机执行；

子流程组件用于调用已存储的故障处理逻辑。

在一个实施例中，如图9所示，提供了一种故障处理装置，故障处理装置采用上述的基于组件的故障处理逻辑生成装置所生成的故障处理逻辑，应用于控制端，包括：第三接收模块220、熔断判断模块240、信息检测模块260和自愈处理模块280，其中：

第三接收模块220，用于接收故障处理请求，故障处理请求携带有故障处理标识；

熔断判断模块240，用于根据故障处理标识查询对应的故障处理信息，并基于故障处理信息判断是否进行熔断；

信息检测模块260，用于当基于故障处理信息判定不需要进行熔断时，则控制主机基于故障处理逻辑执行对应的信息检测；

自愈处理模块280，用于若信息检测存在故障，则基于故障处理逻辑执行对应的故障自愈处理步骤。

在其中一个实施例中，上述熔断判断模块240还用于判断预设时间段中故障处理请求的次数是否超过预设次数，或者判断故障处理请求所对应的用户权限是否正确，或者判断故障处理请求对应的故障处理逻辑、应用以及主机所属业务属主是否一致。

在其中一个实施例中，上述信息检测模块260还用于基于故障处理逻辑执行对应的信息检测，并基于故障处理逻辑中的三元运算符判断故障处理逻辑中的分支流向，以确定下一信息检测的流程，直至故障处理逻辑执行完成。

在其中一个实施例中，上述故障处理装置还包括：

主机获取模块，用于根据故障处理信息调用预设接口获取对应的主机。

在一个实施例中，如图10所示，提供了一种告警处理装置，包括：第四接收模块320、清洗模块340和告警处理模块360，其中：

第四接收模块320，用于接收监控系统发送的告警信息；

清洗模块340，用于通过预设告警规则对告警信息进行清洗得到需要自动处理的待处理告警信息；

告警处理模块360，用于将告警信息分配至对应的控制端，以使得控制端根据上述任意一实施例中的故障处理装置对告警信息对应的故障进行处理。

在其中一个实施例中，上述清洗模块340包括：

屏蔽策略清洗单元，用于基于屏蔽策略判断告警信息是否为预设系统的告警信息，以对告警信息进行清洗得到需要自动处理的待处理告警信息；和/或

收敛策略清洗单元，用于基于收敛策略根据处理时间间隔对告警信息进行清洗得到需要自动处理的待处理告警信息。

关于基于组件的故障处理逻辑生成装置、故障处理装置以及告警装置的具体限定可以参见上文中对于基于组件的故障处理逻辑生成方法、故障处理方法以及告警方法的限定，在此不再赘述。上述基于组件的故障处理逻辑生成装置、故障处理装置以及告警装置中的各个模块可全部或部分通过软件、硬件及其组合来实现。上述各模块可以硬件形式内嵌于或独立于计算机设备中的处理器中，也可以以软件形式存储于计算机设备中的存储器中，以便于处理器调用执行以上各个模块对应的操作。

在一个实施例中，提供了一种计算机设备，该计算机设备可以是服务器，其内部结构图可以如图11所示。该计算机设备包括通过系统总线连接的处理器、存储器和网络接口。其中，该计算机设备的处理器用于提供计算和控制能力。该计算机设备的存储器包括非易失性存储介质、内存储器。该非易失性存储介质存储有操作系统、计算机程序和数据库。该内存储器为非易失性存储介质中的操作系统和计算机程序的运行提供环境。该计算机设备的网络接口用于与外部的终端通过网络连接通信。该计算机程序被处理器执行时以实现一种基于组件的故障处理逻辑生成方法、故障处理方法以及告警方法。

本领域技术人员可以理解，图11中示出的结构，仅仅是与本申请方案相关的部分结构的框图，并不构成对本申请方案所应用于其上的计算机设备的限定，具体的计算机设备可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。

在一个实施例中，提供了一种计算机设备，包括存储器和处理器，存储器中存储有计算机程序，该处理器执行计算机程序时实现以下步骤：接收故障处理逻辑生成请求，并基于故障处理逻辑生成请求获取预先生成的组件；接收针对组件的操作指令，并根据操作指令将所选择的组件进行连接；当组件需要输入控制参数时，则锁定组件的连接操作，并输出控制参数输入提示，并接收所输入的控制参数后，释放组件的连接操作；当组件连接完成后，则将所连接完成的组件发送至后端，以使得后端根据连接完成的组件生成故障处理逻辑，故障处理逻辑用于发送至控制端，以使得控制端根据故障处理逻辑控制对应的主机执行故障处理逻辑。

在一个实施例中，处理器执行计算机程序时所涉及的组件包括开始组件、结束组件、判断组件、作业组件、子流程组件、并行组件、合并组件和控制组件中的至少一个；作业组件用于调用控制端的接口，传递故障处理逻辑，并指示控制端将故障处理逻辑分发给对应的主机执行；子流程组件用于调用已存储的故障处理逻辑。

在一个实施例中，提供了一种计算机设备，包括存储器和处理器，存储器中存储有计算机程序，该处理器执行计算机程序时实现以下步骤：接收故障处理请求，故障处理请求携带有故障处理标识；根据故障处理标识查询对应的故障处理信息，并基于故障处理信息判断是否进行熔断；当基于故障处理信息判定不需要进行熔断时，则控制主机基于故障处理逻辑执行对应的信息检测；若信息检测存在故障，则基于故障处理逻辑执行对应的故障自愈处理步骤。

在一个实施例中，处理器执行计算机程序时所实现的基于故障处理信息判断是否进行熔断，包括：判断预设时间段中故障处理请求的次数是否超过预设次数，或者判断故障处理请求所对应的用户权限是否正确，或者判断故障处理请求对应的故障处理逻辑、应用以及主机所属业务属主是否一致。

在一个实施例中，处理器执行计算机程序时所实现的控制主机基于故障处理逻辑执行对应的信息检测，包括：基于故障处理逻辑执行对应的信息检测，并基于故障处理逻辑中的三元运算符判断故障处理逻辑中的分支流向，以确定下一信息检测的流程，直至故障处理逻辑执行完成。

在一个实施例中，处理器执行计算机程序时所实现的控制主机基于故障处理逻辑执行对应的信息检测之前，还包括：根据故障处理信息调用预设接口获取对应的主机。

在一个实施例中，提供了一种计算机设备，包括存储器和处理器，存储器中存储有计算机程序，该处理器执行计算机程序时实现以下步骤：接收监控系统发送的告警信息；通过预设告警规则对告警信息进行清洗得到需要自动处理的待处理告警信息；将告警信息分配至对应的控制端，以使得控制端根据上述任一实施例中的故障处理方法对告警信息对应的故障进行处理。

在一个实施例中，处理器执行计算机程序时所实现的通过预设告警规则对告警信息进行清洗得到需要自动处理的待处理告警信息，包括：基于屏蔽策略判断告警信息是否为预设系统的告警信息，以对告警信息进行清洗得到需要自动处理的待处理告警信息；和/或基于收敛策略根据处理时间间隔对告警信息进行清洗得到需要自动处理的待处理告警信息。

在一个实施例中，提供了一种计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器执行时实现以下步骤：接收故障处理逻辑生成请求，并基于故障处理逻辑生成请求获取预先生成的组件；接收针对组件的操作指令，并根据操作指令将所选择的组件进行连接；当组件需要输入控制参数时，则锁定组件的连接操作，并输出控制参数输入提示，并接收所输入的控制参数后，释放组件的连接操作；当组件连接完成后，则将所连接完成的组件发送至后端，以使得后端根据连接完成的组件生成故障处理逻辑，故障处理逻辑用于发送至控制端，以使得控制端根据故障处理逻辑控制对应的主机执行故障处理逻辑。

在一个实施例中，计算机程序被处理器执行时所涉及的组件包括开始组件、结束组件、判断组件、作业组件、子流程组件、并行组件、合并组件和控制组件中的至少一个；作业组件用于调用控制端的接口，传递故障处理逻辑，并指示控制端将故障处理逻辑分发给对应的主机执行；子流程组件用于调用已存储的故障处理逻辑。

在一个实施例中，提供了一种计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器执行时实现以下步骤：接收故障处理请求，故障处理请求携带有故障处理标识；根据故障处理标识查询对应的故障处理信息，并基于故障处理信息判断是否进行熔断；当基于故障处理信息判定不需要进行熔断时，则控制主机基于故障处理逻辑执行对应的信息检测；若信息检测存在故障，则基于故障处理逻辑执行对应的故障自愈处理步骤。

在一个实施例中，计算机程序被处理器执行时所实现的基于故障处理信息判断是否进行熔断，包括：判断预设时间段中故障处理请求的次数是否超过预设次数，或者判断故障处理请求所对应的用户权限是否正确，或者判断故障处理请求对应的故障处理逻辑、应用以及主机所属业务属主是否一致。

在一个实施例中，计算机程序被处理器执行时所实现的控制主机基于故障处理逻辑执行对应的信息检测，包括：基于故障处理逻辑执行对应的信息检测，并基于故障处理逻辑中的三元运算符判断故障处理逻辑中的分支流向，以确定下一信息检测的流程，直至故障处理逻辑执行完成。

在一个实施例中，计算机程序被处理器执行时所实现的控制主机基于故障处理逻辑执行对应的信息检测之前，还包括：根据故障处理信息调用预设接口获取对应的主机。

在一个实施例中，提供了一种计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器执行时实现以下步骤：接收监控系统发送的告警信息；通过预设告警规则对告警信息进行清洗得到需要自动处理的待处理告警信息；将告警信息分配至对应的控制端，以使得控制端根据上述任一实施例中的故障处理方法对告警信息对应的故障进行处理。

在一个实施例中，计算机程序被处理器执行时所实现的通过预设告警规则对告警信息进行清洗得到需要自动处理的待处理告警信息，包括：基于屏蔽策略判断告警信息是否为预设系统的告警信息，以对告警信息进行清洗得到需要自动处理的待处理告警信息；和/或基于收敛策略根据处理时间间隔对告警信息进行清洗得到需要自动处理的待处理告警信息。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一非易失性计算机可读取存储介质中，该计算机程序在执行时，可包括如上述各方法的实施例的流程。其中，本申请所提供的各实施例中所使用的对存储器、存储、数据库或其它介质的任何引用，均可包括非易失性和易失性存储器中的至少一种。非易失性存储器可包括只读存储器（Read-Only Memory，ROM）、磁带、软盘、闪存或光存储器等。易失性存储器可包括随机存取存储器（Random Access Memory，RAM）或外部高速缓冲存储器。作为说明而非局限，RAM可以是多种形式，比如静态随机存取存储器（Static Random Access Memory，SRAM）或动态随机存取存储器（Dynamic Random Access Memory，DRAM）等。

以上实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。

以上所述实施例仅表达了本申请的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本申请构思的前提下，还可以做出若干变形和改进，这些都属于本申请的保护范围。因此，本申请专利的保护范围应以所附权利要求为准。

Claims (10)

1.一种故障处理方法，其特征在于，所述故障处理方法应用于控制端，所述故障处理方法包括：

控制端接收故障处理请求，所述故障处理请求携带有故障处理标识，所述故障处理标识是用于指示需要处理的故障的标识；

控制端根据所述故障处理标识查询对应的故障处理信息，并基于所述故障处理信息判断是否进行熔断；

控制端当基于所述故障处理信息判定不需要进行熔断时，则根据流程传入的参数IP，调用CMDB接口，传入IP参数，获取本IP绑定的主机所在的网络区域、主机类型，从应用配置管理中心获取本IP所属应用，控制主机基于故障处理逻辑对对应的应用执行对应的信息检测，以使得前端接收故障处理逻辑生成请求，并基于所述故障处理逻辑生成请求获取预先生成的组件；前端接收针对所述组件的操作指令，并根据所述操作指令将所选择的组件进行连接；当所述组件需要输入控制参数时，则前端锁定所述组件的连接操作，并输出控制参数输入提示，并接收所输入的控制参数后，释放所述组件的连接操作；当所述组件连接完成后，则前端将所连接完成的组件发送至后端，以使得所述后端根据连接完成的组件生成故障处理逻辑，所述故障处理逻辑用于发送至控制端，以使得所述控制端根据所述故障处理逻辑控制对应的主机执行所述故障处理逻辑，所述信息检测依次包括主机资源检测、端口检测以及应用检测；

若所述信息检测存在故障，则控制端基于所述故障处理逻辑执行对应的故障自愈处理步骤，所述故障自愈处理步骤为重启端口。

2.根据权利要求1所述的故障处理方法，其特征在于，所述控制端基于所述故障处理信息判断是否进行熔断，包括：

控制端判断预设时间段中所述故障处理请求的次数是否超过预设次数，或者

控制端判断所述故障处理请求所对应的用户权限是否正确，或者

控制端判断所述故障处理请求对应的故障处理逻辑、应用以及主机所属业务属主是否一致。

3.根据权利要求1所述的故障处理方法，其特征在于，所述控制端控制主机基于所述故障处理逻辑执行对应的信息检测，包括：

控制端基于所述故障处理逻辑执行对应的信息检测，并基于所述故障处理逻辑中的三元运算符判断所述故障处理逻辑中的分支流向，以确定下一信息检测的流程，直至所述故障处理逻辑执行完成。

4.根据权利要求1所述的故障处理方法，其特征在于，所述组件包括开始组件、结束组件、判断组件、作业组件、子流程组件、并行组件、合并组件和控制组件中的至少一个；

所述作业组件用于调用所述控制端的接口，传递故障处理逻辑，并指示所述控制端将所述故障处理逻辑分发给对应的主机执行；

所述子流程组件用于调用已存储的故障处理逻辑。

5.一种告警处理方法，其特征在于，所述告警处理方法包括：

接收监控系统发送的告警信息；

通过预设告警规则对所述告警信息进行清洗得到需要自动处理的待处理告警信息；

将所述告警信息分配至对应的控制端，以使得所述控制端根据权利要求1至4任意一项中的故障处理方法对所述告警信息对应的故障进行处理。

6.根据权利要求5所述的方法，其特征在于，所述通过预设告警规则对所述告警信息进行清洗得到需要自动处理的待处理告警信息，包括：

基于屏蔽策略判断所述告警信息是否为预设系统的告警信息，以对所述告警信息进行清洗得到需要自动处理的待处理告警信息；和/或

基于收敛策略根据处理时间间隔对所述告警信息进行清洗得到需要自动处理的待处理告警信息。

7.一种故障处理装置，其特征在于，所述故障处理装置应用于控制端，所述故障处理装置包括：

第三接收模块，用于接收故障处理请求，所述故障处理请求携带有故障处理标识，所述故障处理标识是用于指示需要处理的故障的标识；

熔断判断模块，用于根据所述故障处理标识查询对应的故障处理信息，并基于所述故障处理信息判断是否进行熔断；

信息检测模块，用于当基于所述故障处理信息判定不需要进行熔断时，则根据流程传入的参数IP，调用CMDB接口，传入IP参数，获取本IP绑定的主机所在的网络区域、主机类型，从应用配置管理中心获取本IP所属应用，控制主机基于故障处理逻辑对对应的应用执行对应的信息检测，以使得前端接收故障处理逻辑生成请求，并基于所述故障处理逻辑生成请求获取预先生成的组件；前端接收针对所述组件的操作指令，并根据所述操作指令将所选择的组件进行连接；当所述组件需要输入控制参数时，则前端锁定所述组件的连接操作，并输出控制参数输入提示，并接收所输入的控制参数后，释放所述组件的连接操作；当所述组件连接完成后，则前端将所连接完成的组件发送至后端，以使得所述后端根据连接完成的组件生成故障处理逻辑，所述故障处理逻辑用于发送至控制端，以使得所述控制端根据所述故障处理逻辑控制对应的主机执行所述故障处理逻辑，所述信息检测依次包括主机资源检测、端口检测以及应用检测；

自愈处理模块，用于若所述信息检测存在故障，则基于所述故障处理逻辑执行对应的故障自愈处理步骤，所述故障自愈处理步骤为重启端口。

8.一种告警处理装置，其特征在于，所述告警处理装置包括：

第四接收模块，用于接收监控系统发送的告警信息；

清洗模块，用于通过预设告警规则对所述告警信息进行清洗得到需要自动处理的待处理告警信息；

告警处理模块，用于将所述告警信息分配至对应的控制端，以使得所述控制端根据权利要求7中的故障处理装置对所述告警信息对应的故障进行处理。

9.一种计算机设备，包括存储器和处理器，所述存储器存储有计算机程序，其特征在于，所述处理器执行所述计算机程序时实现权利要求1至4或5至6中任一项所述的方法的步骤。

10.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现权利要求1至4或5至6中任一项所述的方法的步骤。

Images