CN115705259A - 故障处理方法、相关设备及存储介质 - Google Patents

Abstract

本申请公开了一种故障处理方法、相关设备及存储介质。其中，方法包括：客户端获取第一故障告警信息；第一故障告警信息表征对应的容器业务出现故障；在本地数据库查找与第一故障告警信息匹配的故障解决方案；当在本地数据库查找到与第一故障告警信息匹配的故障解决方案时，利用查找到的故障解决方案进行故障修复；当在本地数据库未查找到与第一故障告警信息匹配的故障解决方案时，向服务器上报第一故障告警信息；接收所述服务器下发的故障解决方案，并利用下发的故障解决方案进行故障修复。本申请提供的方案，针对故障告警信息，调用客户端或者服务器的资源来进行故障修复，如此，能够缓解大量故障告警上报造成的服务器的负担。

Description

故障处理方法、相关设备及存储介质

技术领域

本申请涉及云计算领域，尤其涉及一种故障处理方法、相关设备及存储介质。

背景技术

在传统的监控告警系统中，会对整个集群的业务配置及系统性能等指标进行实时监控。当监测到异常情况时，则立即触发故障告警。在这种情况下，包括容器业务场景在内的故障告警处理，存在大量告警同时上报而造成的服务器处理压力大的问题。

发明内容

为解决相关技术问题，本申请实施例提供一种故障处理方法、相关设备及存储介质。

本申请实施例的技术方案是这样实现的：

本申请实施例提供一种故障处理方法，应用于客户端，包括：

获取第一故障告警信息；所述第一故障告警信息表征对应的容器业务出现故障；

在本地数据库查找与所述第一故障告警信息匹配的故障解决方案；

当在本地数据库查找到与所述第一故障告警信息匹配的故障解决方案时，利用查找到的故障解决方案进行故障修复；当在本地数据库未查找到与所述第一故障告警信息匹配的故障解决方案时，向服务器上报所述第一故障告警信息；

接收所述服务器下发的故障解决方案，并利用所述下发的故障解决方案进行故障修复。

上述方法中，所述获取第一故障告警信息，包括：

将容器上报的第一故障告警信息存储至缓存池；

当根据所述第一故障告警信息中的告警时间确定调度所述第一故障告警信息对应的故障告警时，从所述缓存池中读取所述第一故障告警信息。

上述方法中，所述容器上报的第一故障告警信息中的告警等级为空，所述将容器上报的第一故障告警信息存储至缓存池，包括：

当确定所述容器上报的第一故障告警信息对应的故障告警的告警等级为第四等级时，利用确定的告警等级更新所述第一故障告警信息中的告警等级，并将更新后的第一故障告警信息存储至所述缓存池；或者，

当确定所述容器上报的第一故障告警信息对应的故障告警的告警等级不为第四等级时，直接将所述容器上报的第一故障告警信息存储至所述缓存池。

上述方法中，当所述第一故障告警信息中的告警等级为第四等级告警时，确定能够在本地数据库查找到与所述第一故障告警信息匹配的故障解决方案；所述第四等级告警表征进程级的故障；

当所述第一故障告警信息中的告警等级为第三等级告警时，在本地数据库查找与所述第一故障告警信息匹配的故障解决方案；所述第三等级告警表征应用级的故障；当在本地数据库未查找到与所述第一故障告警信息匹配的故障解决方案时，将所述第一故障告警信息中的告警等级由第三等级告警更新为第二等级告警，向所述服务器上报更新后的第一故障告警信息；所述第二等级告警表征所述容器所在节点故障或者资源导致的故障；其中，

当从所述缓存池中读取的第一故障告警信息中的告警等级为空时，将读取的第一故障告警信息中的告警等级更新为第三等级，并在本地数据库查找与更新后的第一故障告警信息匹配的故障解决方案。

本申请实施例还提供一种故障处理方法，应用于服务器，包括：

接收客户端上报的第一故障告警信息；所述第一故障告警信息表征对应的容器业务出现故障；

在所述服务器本地数据库查找与所述第一故障告警信息匹配的故障解决方案；所述客户端本地数据库未存储与所述第一故障告警信息匹配的故障解决方案；

在所述服务器本地数据库查找到与所述第一故障告警信息匹配的故障解决方案时，向所述客户端下发与所述第一故障告警信息匹配的故障解决方案。

上述方法中，所述第一故障告警信息中的告警等级为第二等级告警；所述第二等级告警表征所述容器所在节点故障或者资源导致的故障；

当所述第一故障告警信息中的业务类型不属于资源密集型时，在所述服务器本地数据库查找与所述第一故障告警信息匹配的故障解决方案；

在所述服务器本地数据库未查找到与所述第一故障告警信息匹配的故障解决方案时，更新所述第一故障告警信息中的告警等级为第一等级告警，上报更新的第一故障告警信息；所述第一等级告警表征当前无法处理的故障；

接收反馈的所述第一故障告警信息对应的故障解决方案，并下发所述第一故障告警信息对应的故障解决方案至所述客户端。

上述方法中，所述方法还包括：

将反馈的所述第一故障告警信息对应的故障解决方案存储至所述服务器本地数据库。

本申请实施例还提供一种客户端，包括：第一处理器和用于存储能够在处理器上运行的计算机程序的第一存储器，

其中，所述第一处理器用于运行所述计算机程序时，执行上述客户端侧任一方法的步骤。

本申请实施例还提供一种服务器，包括：第二处理器和用于存储能够在处理器上运行的计算机程序的第二存储器，

其中，所述第二处理器用于运行所述计算机程序时，执行上述服务器侧任一方法的步骤。

本申请实施例还提供一种存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现上述客户端侧任一项所述方法的步骤，或者实现服务器侧任一项所述方法的步骤。

本申请实施例提供的故障处理方法、相关设备及存储介质，客户端获取第一故障告警信息；所述第一故障告警信息表征对应的容器业务出现故障；在本地数据库查找与所述第一故障告警信息匹配的故障解决方案；当在本地数据库查找到与所述第一故障告警信息匹配的故障解决方案时，利用查找到的故障解决方案进行故障修复；当在本地数据库未查找到与所述第一故障告警信息匹配的故障解决方案时，向服务器上报所述第一故障告警信息；服务器接收到第一故障告警信息后，在本地数据库查找与所述第一故障告警信息匹配的故障解决方案，并在在本地数据库查找到与所述第一故障告警信息匹配的故障解决方案时，向所述客户端下发与所述第一故障告警信息匹配的故障解决方案；所述客户端接收到所述服务器下发的故障解决方案后，利用所述下发的故障解决方案进行故障修复。本申请实施例提供的技术方案，客户端获取到故障告警信息后，先根据故障告警信息在本地数据库查找对应的故障解决方案，利用查找到的故障解决方案进行故障修复；若无法在本地数据库查找到对应的故障解决方案，再上报至服务器，通过服务器下发的故障解决方案来进行故障修复。这样，便可以针对故障告警信息，通过调用客户端或者服务器的资源来进行故障修复，从而缓解了由服务器处理大量故障告警信息并进行故障修复而产生的处理压力，提高了故障告警处理的效率。

附图说明

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

图2为本申请实施例第二种故障处理的方法流程示意图；

图3为本申请实施例第三种故障处理的方法流程示意图。

图4为本申请应用实施例的多级故障处理系统架构图；

图5为本申请应用实施例中的本地故障告警采集模块架构图；

图6为本申请应用实施例的多级故障处理流程示意图；

图7为本申请实施例第一种故障处理装置结构示意图；

图8为本申请实施例第二种故障处理装置结构示意图；

图9为本申请实施例客户端结构示意图；

图10为本申请实施例服务器结构示意图；

图11为本申请实施例故障处理系统结构示意图。

具体实施方式

下面通过附图及具体实施例对本申请再做进一步详细的说明。

在传统的监控告警系统中，针对容器业务场景在内的故障告警处理时，出现故障后缺乏对故障告警的过滤过程，而是直接上报告警，或者，对于告警进行一定次数的压制，当告警次数达到设定阈值N次时会最终触发，进而上报故障告警。通过上述方式，在大量的故障告警出现并且上报时，容易增加服务器处理的压力，使得服务器无法及时处理故障告警，降低了故障告警处理的效率。

基于此，在本申请的各种实施例中，在客户端和服务器分别部署故障处理系统，针对不同的故障告警信息，调用客户端或者服务器的资源对故障告警信息对应的故障告警进行处理，有效地分散了大量故障告警上报对服务器造成的处理压力，进而缓解了服务器的负担，提高了故障告警处理的效率。

本申请实施例提供一种故障处理方法，应用于客户端，如图1所示，所述方法包括：

步骤101：获取第一故障告警信息；所述第一故障告警信息表征对应的容器业务出现故障；

步骤102：在本地数据库查找与所述第一故障告警信息匹配的故障解决方案；

步骤103：当在本地数据库查找到与所述第一故障告警信息匹配的故障解决方案时，利用查找到的故障解决方案进行故障修复；当在本地数据库未查找到与所述第一故障告警信息匹配的故障解决方案时，向服务器上报所述第一故障告警信息；

步骤104：接收所述服务器下发的故障解决方案，并利用所述下发的故障解决方案进行故障修复。

其中，实际应用时，当容器业务出现故障，容器向对应的客户端上报故障告警信息，容器上报的故障告警信息可以包括：告警具体内容、告警时间、告警来源节点通用唯一识别码(UUID，Universally Unique Identifier)、告警来源容器身份标识号(ID，IdentityDocument)、告警业务类型、告警窗口的监控数据等故障告警参数信息。这里，告警具体内容可以由用户在应用程序中自定义告警项内容，或者由操作系统(比如linux操作系统)中的报错模块进行封装，如；告警时间表征故障告警生成的时间信息；告警来源节点UUID表征与故障告警对应的节点的网络互连协议(IP，Internet Protocol)地址；告警来源容器ID表征与故障告警对应的容器信息；告警业务类型包括中央处理器(CPU，Central ProcessingUnit)密集型、内存密集型、输入输出(IO，Input/Output)密集型等类型；告警窗口的监控数据包括CPU使用率、内存使用率、IO使用率等信息。

实际应用时，可以在客户端内部署多个容器，也可以仅部署一个容器，本申请实施例对客户端内部署的容器的数量不作限定。客户端获取容器上报的故障告警信息可以是一个容器上报的故障告警信息，也可以是多个容器上报的故障告警信息。

其中，当客户端内部署多个容器时，可能同时上报多个故障告警信息，客户端需要配置缓存池来存储容器上报的故障告警信息，从而实现有序地对各故障告警信息的处理；这里，所述缓存池为一定大小的存储区域；其中，所述缓存池的大小可以根据预设故障告警信息的字节大小和故障告警信息的数量来设置；所述缓存池的个数可以设置为m；m表征为客户端当前所部署的容器的个数。

基于此，在一实施例中，步骤101的具体实现可以包括：

将容器上报的第一故障告警信息存储至缓存池；

当根据所述第一故障告警信息中的告警时间确定调度所述第一故障告警信息对应的故障告警时，从所述缓存池中读取所述第一故障告警信息。

这里，实际应用时，获取容器上报的第一故障告警信息后，客户端可以判断第一故障告警信息对应的故障告警的告警等级，以便确定调用客户端或者服务器的资源来对故障告警进行故障修复。

基于此，在一实施例中，所述容器上报的第一故障告警信息中的告警等级为空；

相应地，所述将容器上报的第一故障告警信息存储至缓存池，包括：

当确定所述容器上报的第一故障告警信息对应的故障告警的告警等级为第四等级时，利用确定的告警等级更新所述第一故障告警信息中的告警等级，并将更新后的第一故障告警信息存储至所述缓存池；或者，

当确定所述容器上报的第一故障告警信息对应的故障告警的告警等级不为第四等级时，直接将所述容器上报的第一故障告警信息存储至所述缓存池。

这里，所述告警等级表征故障告警的等级信息。

也就是说，当为故障告警设置了等级信息时，所述第一故障告警信息还包括告警等级。客户端获取容器上报的第一故障告警信息时，第一故障告警信息中的告警等级为空。在确定第一故障告警信息对应的故障告警的告警等级是否为第四等级告警的过程中，客户端先通过容器对应的守护进程(Daemon)来获取容器所有进程的运行情况。若发现存在至少一个进程未正常运行的情况，则判断第一故障告警信息对应的故障告警的告警等级为第四等级告警，即进程级的故障，同时，更新第一故障告警信息中的告警等级。示例性地，针对docker容器，客户端可以通过docker daemon来获取所有docker进程的运行情况。

当通过容器的守护进程判断容器的进程运行正常，则确定所述容器上报的第一故障告警信息对应的故障告警的告警等级不为第四等级，直接将所述容器上报的第一故障告警信息存储至所述缓存池。

实际应用时，若客户端在本地数据库中查找到与所述第一故障告警信息对应的故障解决方案，则利用查找到的故障解决方案进行故障修复。示例性地，客户端从本地数据库中查找到与所述第一故障告警信息对应的故障修复脚本，然后，利用故障修复脚本对第一故障告警信息对应的故障告警进行修复。

这里，从缓存池中读取第一故障告警信息后，当第一故障告警信息中的告警等级为第四等级告警时，客户端可以从本地数据库中获取对应的故障解决方案，如故障修复脚本。具体地，针对docker容器，客户端可以通过故障修复脚本将对应的docker进程重启，从而修复了进程级的故障。

也就是说，当所述第一故障告警信息中的告警等级为第四等级告警时，确定能够在本地数据库查找到与所述第一故障告警信息匹配的故障解决方案；所述第四等级告警表征进程级的故障。

当读取的第一故障告警信息中的告警等级为空时，设置读取的第一故障告警信息中的告警等级为第三等级告警，即应用级的故障，也就是说，将读取的第一故障告警信息中的告警等级更新为第三等级，然后在本地数据库查找与更新后的第一故障告警信息匹配的故障解决方案。此时，客户端可以根据第一故障告警信息中的告警来源的容器ID，将查找到的故障解决方案下发到第一故障告警信息对应的故障告警的容器，来进行第三等级故障的修复。

也就是说，当所述第一故障告警信息中的告警等级为第三等级告警时，在本地数据库查找与所述第一故障告警信息匹配的故障解决方案；所述第三等级告警表征应用级的故障。

若客户端无法在本地数据库中查找到与所述第一故障告警信息对应的故障解决方案，则将第一故障告警信息上报至服务器。然后，利用服务器下发的故障解决方案进行故障修复。示例性地，客户端可以接收服务器下发的与第一故障信息对应的故障修复脚本，利用故障修复脚本对第一故障告警信息对应的故障告警进行修复。

其中，当在本地数据库未查找到与所述第一故障告警信息匹配的故障解决方案时，将所述更新后的第一故障告警信息中的告警等级由第三等级告警更新为第二等级告警，向所述服务器上报更新后的第一故障告警信息；所述第二等级告警表征所述容器所在节点故障或者资源导致的故障。

实际应用时，所述客户端可以通过第一故障告警信息中的告警具体内容在本地数据库中查找匹配的故障告警信息，再依据查找到的故障告警信息确定对应的故障解决方案。

实际应用时，客户端将各容器上报的故障告警信息存储至缓存池后，可以根据故障告警信息中的告警时间来确定调度故障告警信息的先后顺序。示例性地，客户端通过故障告警信息中的告警时间确定告警生成时间最早的故障告警信息后，将该故障告警信息作为待调度的故障告警信息，然后从缓存池中读取待调度的故障告警信息，并将待调度的故障告警信息设置至客户端对应的告警队列中；其中，所述告警队列可以表征存储从缓存池中调度后插入的队列数据结构。

另外，客户端还可以利用故障告警信息中的告警来源容器ID从缓存池中读取相关联的故障告警信息。例如，客户端在缓存池中查找与第一故障告警信息中的告警来源容器ID相匹配的故障告警信息，即与第一故障告警信息相关联的故障告警信息，然后，再将查找到的故障告警信息设置至客户端对应的告警队列中，从而对第一故障告警信息和与第一故障告警信息相关联的故障告警信息一起进行故障告警修复。

这里，若没有容器上报故障告警信息，即客户端的缓存池为空时，表征客户端内的容器业务正常，无需进行故障处理操作。

实际应用时，由于客户端是根据缓存池中故障告警信息中的告警时间来确定故障修复的顺序，那么，在客户端从缓存池中读取第一故障告警信息后，需要将缓存池中存储的第一故障告警信息的记录删除，以便客户端根据除第一故障告警信息之外的故障告警信息中的告警时间来确定下一个待处理的故障告警信息。

基于此，在一实施例中，所述方法还可以包括：

读取所述第一故障告警信息后，从所述缓存池中删除所述第一故障告警信息。

实际应用时，在本地数据库中无法查找到对应的故障解决方案的情况下，所述客户端则将第一故障告警信息中的告警等级标记为第二等级告警，即容器所在节点故障或者资源导致的故障。然后，所述客户端将第一故障告警信息上报至服务器，以获取相应的故障解决方案。

相关技术中，对于较为复杂的业务系统，往往会存在大量服务器无法解决的故障告警。在这种情况下，就需要运维技术人员进行人工干预，来处理这些故障告警。这个过程中，需要运维技术人员具备丰富的运维经验，对于技术能力也有一定门槛与要求。同时，在日常运维过程中，业务系统经常会重复出现的类似的故障告警，这时，则要求不同运维交接人员之间能形成运维经验的及时传递，便于高效解决故障告警。如此，便增加了故障处理的人工培训成本。换句话说，目前故障响应及处理的自动化程度并不高，导致故障处理的人工成本和时间成本增加。

另一方面，针对Docker容器的业务系统，目前应用较多的kubernetes生态主要依赖于开源社区，由于较多组件不成熟，存在缺陷，使得故障告警的类型也较为纷杂，需要人工干预进行处理。运维技术人员在处理这些故障告警时，主要依赖于日常运维中知识的积累，而这些运维知识往往与环境、组件版本关联性较高，即通用性较差。因此，需要运维人员针对不同的故障告警，分别进行处理，这样会耗费大量的时间和精力，降低了故障处理的效率。

因此，为了提高故障告警处理的自动化程度，提高故障处理的效率，所述客户端接收到服务器下发的故障解决方案后，可以将下发的故障解决方案存储至本地数据库，使得客户端在获取到相同的故障告警时，可以直接通过本地数据库实现故障修复，无需人工干预。

基于此，在一实施例中，所述方法还可以包括：

将所述下发的故障解决方案存储至本地数据库。

通过将下发的故障解决方案存储至本地数据库，使得客户端系统具备一定的自学习能力，针对相同的故障告警无需用户进行重复处理，实现了一定程度的人工智能自动化响应及处理常见故障告警功能。同时，降低了故障修复的人工成本。

相应地，本申请实施例还提供了一种故障处理方法，应用于服务器，如图2所示，所述方法包括：

步骤201：接收客户端上报的第一故障告警信息；所述第一故障告警信息表征对应的容器业务出现故障；

步骤202：在所述服务器本地数据库查找与所述第一故障告警信息匹配的故障解决方案；所述客户端本地数据库未存储与所述第一故障告警信息匹配的故障解决方案；

步骤203：在所述服务器本地数据库查找到与所述第一故障告警信息匹配的故障解决方案时，向所述客户端下发与所述第一故障告警信息匹配的故障解决方案。

这里，服务器接收客户端上报的第一故障告警信息后，在服务器本地数据库中查找匹配的故障解决方案。然后，将查找到的故障解决方案下发至客户端，使得客户端可以利用下发的故障解决方案进行故障修复。

实际应用时，服务器在本地数据库查找与第一故障告警信息匹配的故障解决方案之前，还需要判断第一故障告警信息对应的故障告警的业务类型，以便服务器执行相应的故障处理操作。另外，对于服务器无法利用本地数据库确定匹配的故障解决方案的情况，则需要将第一故障告警信息上报，提示相关人员输入故障解决方案，以完成故障修复。

基于此，在一实施例中，所述方法还可以包括：

所述第一故障告警信息中的告警等级为第二等级告警；所述第二等级告警表征所述容器所在节点故障或者资源导致的故障；

当所述第一故障告警信息中的业务类型不属于资源密集型时，在所述服务器本地数据库查找与所述第一故障告警信息匹配的故障解决方案；

在所述服务器本地数据库未查找到与所述第一故障告警信息匹配的故障解决方案时，更新所述第一故障告警信息中的告警等级为第一等级告警，上报更新的第一故障告警信息；所述第一等级告警表征当前无法处理的故障；

接收反馈的所述第一故障告警信息对应的故障解决方案，并下发所述第一故障告警信息对应的故障解决方案至所述客户端。

这里，当第一故障告警信息中的告警等级为第二等级告警时，即容器所在节点故障或者由于资源瓶颈导致的故障，服务器对第一故障告警信息中的业务类型进行判断，当所述业务类型属于资源密集型时，则进行资源调度操作。示例性地，当业务类型为CPU密集型、内存密集型、IO密集型等类型时，则所述业务类型为资源密集型。具体地，服务器可以利用第一故障告警信息中的告警来源节点UUID，获取告警来源节点的信息。当根据告警来源的节点信息确定对应的容器资源使用率超过预设阈值时，则通过客户端为对应的容器分配更多的资源，如CPU资源、内存资源或者IO资源。当根据告警来源的节点信息确定对应的节点的资源使用率超过预设阈值时，则通过第一故障告警信息中的告警来源容器ID，将对应的容器调度至新的客户端，从而实现了对第一故障告警信息对应的故障告警的修复。

实际应用时，在第一故障告警信息对应的故障告警不属于资源密集型，且未在本地数据库查找到匹配的故障解决方案的情况下，服务器需要将第一故障功能告警信息的告警等级更新为第一等级告警，即当前无法处理的故障，然后，上报更新后的第一故障告警信息，使得技术人员可以进行人工处理。

相应地，服务器可以接收技术人员反馈的第一故障告警信息对应的故障解决方案，并将故障解决方案下发至客户端，以使客户端利用故障解决方案进行故障修复。

这里，在技术人员进行人工处理后，服务器还需要将反馈的故障解决方案存储至本地数据库中。这样，在服务器遇到相同的故障告警时，便可以通过本地数据库直接匹配到对应的故障解决方案，减少了人工干预过程，实现了一定程度的自动化响应及故障修复的功能。

基于此，在一实施例中，所述方法还包括：

将反馈的所述第一故障告警信息对应的故障解决方案存储至所述服务器本地数据库。

这里，将技术人员反馈的第一故障告警信息对应的故障解决方案存储至本地数据库后，客户端便可以根据第一故障告警信息中的故障告警信息在本地数据库查找匹配的故障解决方案，无需技术人员重复处理相同的故障。如此，不仅提高了故障修复的自动化程度，也减少了人工处理而导致的时间成本和人工成本。

本申请实施例还提供了一种故障处理方法，如图3所示，该方法包括：

步骤301：客户端获取第一故障告警信息；

其中，所述第一故障告警信息表征对应的容器业务出现故障；

步骤302：所述客户端在本地数据库查找与第一故障告警信息匹配的故障解决方案；

步骤303：所述客户端当在本地数据库查找到与第一故障告警信息匹配的故障解决方案时，利用查找到的故障解决方案进行故障修复；

步骤304：当在本地数据库未查找到与所述第一故障告警信息匹配的故障解决方案时，所述客户端向服务器上报第一故障告警信息；

步骤305：所述服务器接收客户端上报的第一故障告警信息后，在所述服务器本地数据库查找与所述第一故障告警匹配的故障解决方案；

其中，所述客户端本地数据库未存储与所述第一故障告警信息匹配的故障解决方案；

步骤306：所述服务器在所述服务器本地数据库查找到与所述第一故障告警信息匹配的故障解决方案时，向所述客户端下发与所述第一故障告警信息匹配的故障解决方案；

步骤307：所述客户端接收到所述服务器下发的故障解决方案后，利用所述下发的故障解决方案进行故障修复。

这里，需要说明的是：客户端和服务器的具体处理过程已在上文详述，这里不再赘述。

本申请实施例提供的故障处理方法，客户端获取第一故障告警信息后，在本地数据库查找与第一故障告警信息匹配的故障解决方案。若能够在本地数据库查找到匹配的故障解决方案，则利用查找到的故障解决方案对容器业务进行故障修复；若无法在本地数据库查找到匹配的故障解决方案，再将第一故障告警信息上报服务器，利用服务器下发的故障解决方案对容器业务故障修复。本申请实施例提供的技术方案，对于容器场景下的故障告警信息，先利用客户端本地数据库的资源查找对应的故障解决方案，在判断利用本地数据库的资源无法得到故障解决方案的情况下，再将故障告警信息上报至服务器，通过调度服务器的资源来获取故障解决方案，也就是说，客户端先判断是否可以在本地数据库查找到对应的故障解决方案，进而对故障告警信息对应的故障告警进行故障修复处理。若无法利用本地数据库查找到对应的故障解决方案，再将故障告警信息上报至服务器，通过服务器下发的故障解决方案进行故障修复。如此，可以有效改善由于大量故障告警直接上报服务器而导致的服务器压力大、无法及时处理故障告警的问题，从而可以有效缓解大量故障告警上报对服务器造成的压力，从而提高故障告警的处理效率。

下面结合应用实施例对本申请再做进一步详细的描述。

如图4所示，本应用实施例的故障处理系统框架采用客户端(Client)-服务器(Server)的结构，即C/S结构，包含n+2个节点。其中，n个节点为客户端侧的节点，运行正常容器业务，每个节点上都部署了本地故障告警采集上报模块及本地告警匹配处理模块。如图5所示，本地故障告警采集上报模块采集容器业务对应的故障告警信息，并将采集的故障告警信息发送至本地告警匹配处理模块。而本地告警匹配处理模块利用本地数据库资源查找与故障告警信息匹配的故障解决方案，并在无法查找到匹配的故障解决方案时，将故障告警信息上报至服务器的故障匹配识别模块。

服务器端可以配置2个节点，互为主备，以便一个服务器节点发生故障时，可以切换至另一个服务器节点来保障故障处理系统的正常运行。示例性地，当客户端向服务器上报故障告警信息，并在预设时间阈值内没有接收到服务器反馈的故障解决方案的情况下，则需要进行主备服务器的切换。服务器设置故障告警匹配处理中心，故障告警匹配处理中心具体可以包括：

故障匹配识别模块，用于利用故障修复知识库查找与故障告警信息匹配的故障解决方案；

故障修复知识库，用于存储故障告警信息对应的故障解决方案；

容器调度模块，用于对属于资源密集型的故障告警信息对应的故障告警进行资源调度处理；

人工干预模块，用于录入故障修复方案到故障修复知识库中。

实时本应用实施例的方案之前，需要将对应的代码打包、上传、部署至客户端和服务器。

对于针对容器业务的故障处理系统来说，如图6所示，当客户端获取到故障告警信息时，故障处理系统对故障告警信息对应的故障告警进行故障修复的过程包括以下步骤：

步骤601：本地故障告警采集上报模块获取容器上报的故障告警信息，并存储至本地缓存池；

这里，由于客户端中可以运行多个容器，若客户端中包含多个容器，则需要本地故障告警采集上报模块获取各容器上报的故障告警信息。

本地故障采集上报模块获取容器上报的故障告警信息时，第一故障告警信息中的告警等级为空。在确定故障告警信息对应的故障告警的告警等级是否为第四等级告警的过程中，本地故障采集上报模块通过容器对应的守护进程来获取容器所有进程的运行情况。若发现存在至少一个进程未正常运行的情况，则判断所述容器上报的故障告警信息中的告警等级为第四等级告警，同时，更新所述容器上报的故障告警信息中的告警等级并存储至本地缓存池。

当通过容器的守护进程判断所述容器的进程运行正常，则确定所述容器上报的故障告警信息对应的故障告警的告警等级不为第四等级告警，直接将所述容器上报的第一故障告警信息存储至本地缓存池。

实际应用时，每个客户端都配置了一个本地缓存池，用于存放上报的故障告警信息并支持根据故障告警信息中的告警生成时间和告警来源容器ID进行查找或者删除等操作。

其中，所述容器上报的故障告警信息可以包括：告警等级(alarm_level)、告警具体内容(content)、告警生成时间(time)、告警来源的节点UUID(node_uuid)、告警来源的容器ID(container_id)、告警业务类型(type)、告警窗口的监控数据(node_data/container_data)。所述告警等级产生时默认为空，经本应用实施例判断后添加，告警等级可以包括：第一等级故障告警、第二等级故障告警、第三等级故障告警、第四等级故障告警；所述告警具体内容可由用户自定义，在应用程序中预设好故障告警内容或者由Linux系统日志中的报错单元进行封装；所述告警生成时间格式为：YYYYMMDDHHMMSS；所述告警来源的节点UUID可以由主机(也可以称为客户端)的业务IP地址拼接而成；所述告警来源的容器ID表征告警来源docker容器的id；所述告警业务类型包含CPU密集型、内存密集型、IO密集型、无等类型；所述告警窗口的监控数据可以包括CPU使用率、内存使用率、IO使用率等。

示例性地，故障告警信息X的一种json格式结构如下：

步骤602：本地故障告警采集上报模块调度故障告警信息X，进行故障告警处理；

这里，每个客户端都配置了一个告警队列，所述告警队列表征存储从本地缓存池中调度后插入的队列数据结构。因此，本地故障告警采集上报模块根据本地缓存池中故障告警信息中的告警时间确定最早生成的故障告警信息(后续描述称为故障告警信息X)后，即第一故障告警信息，再从缓存池中读取故障告警信息X，调度至告警队列的队尾(即按照时间顺序排在队列中)，以便本地告警匹配模块对故障告警信息X对应的故障告警X进行故障修复。

实际应用时，读取故障告警信息X后，从本地缓存池中删除故障告警信息X。

这里，当本地缓存池为空时，则说明客户端内各个容器业务运行正常，无需执行故障处理操作。

另外，本地故障告警采集上报模块还会调度本地缓存池中其它与故障告警X有关联性的故障告警，按生成时间先后插入到告警队列队尾；相应地，也会从本地缓存池中删除被调度的其他与故障告警X有关联性的故障告警信息。

实际应用时，在确定故障告警信息X后，本地故障告警采集上报模块可以利用故障告警信息X的告警来源容器ID，在本地缓存池中查找具有相同告警来源容器ID的故障告警信息。然后，根据第一时间阈值T1，将与故障告警信息X的告警时间的时间差小于T1的故障告警信息对应的故障告警认为是与故障告警X有关联性的故障告警，再按照故障告警信息中的告警时间的先后顺序，将与故障告警X有关联性的故障告警信息调度至告警队列队尾。

然后，本地告警匹配处理模块从告警队列中调度队首的故障告警信息X，进行故障告警处理。

这里，客户端的本地告警匹配处理模块每次从告警队列的队首获取故障告警信息，进行告警处理，被处理的故障告警的故障告警信息则从队列中被删除；当从告警队列的队首获取故障告警信息X，则对故障告警信息X进行故障告警处理。

步骤603：本地告警匹配处理模块查看故障告警信息X的告警等级是否为第四等级告警；

其中，所述第四等级告警表征进程级的故障；

这里，若告警等级为第四等级告警，则执行步骤604；若不是第四等级告警，则执行步骤605；

步骤604：本地告警匹配处理模块从客户端本地数据库查找匹配的故障解决方案；

这里，由于客户端本地数据库预先存储了故障告警信息与故障解决方案的关联关系，当故障告警信息X的告警等级为第四等级告警时，便可以在本地数据库查找与故障告警信息X匹配的故障解决方案，并利用故障解决方案进行故障修复。示例性地，从本地数据库中获取故障告警信息X对应的故障修复脚本，通过重启与故障告警信息X对应的容器的docker进程来修复故障告警。

修复完成后，返回故障告警修复完成标志至本地故障告警采集上报模块，并执行步骤614。

步骤605：本地告警匹配处理模块确认故障告警信息X的告警等级为第三等级告警；

这里，当读取的故障告警信息X的告警等级为空时，本地告警匹配处理模块设置故障告警信息X的告警等级为第三等级告警，即应用级的故障，然后执行步骤606。

步骤606：本地告警匹配处理模块遍历客户端本地数据库，判断是否有与故障告警信息X匹配的故障告警信息；

具体地，本地告警匹配处理模块在本地数据库中查找与故障告警信息X的告警具体内容匹配的故障告警信息，若存在匹配的故障告警信息，则执行步骤607；若不存在匹配的故障告警信息，则执行步骤608。

步骤607：本地告警匹配处理模块从客户端本地数据库中查找匹配的故障解决方案；

这里，当本地告警匹配处理模块在本地数据库中查找到与故障告警信息X的告警具体内容匹配的故障告警信息(可以理解为本地命中)时，从本地数据库中获取匹配的故障解决方案。然后，利用获取的故障解决方案，对故障告警进行修复。具体地，从本地数据库中获取故障处理脚本后，通过故障告警信息X的告警来源容器ID，将故障处理脚本下发至对应的容器或宿主机中，以完成故障修复；所述宿主机表征客户端中容器之外的范畴。在完成故障修复后，返回一个告警修复完成标志给本地故障告警采集上报模块。然后，执行步骤614。

步骤608：本地告警匹配处理模块更新故障告警信息X的告警等级为第二等级告警，并上报更新后的故障告警信息X到服务器的故障匹配识别模块，之后执行步骤609；

当本地告警匹配处理模块无法利用客户端的资源对故障告警X进行处理时，更新故障告警信息X的告警等级，并将故障告警信息X发送至服务器的故障匹配识别模块，通过服务器的故障匹配识别模块来对故障告警X进行故障处理。

步骤609：所述故障匹配识别模块查看故障告警信息X的业务类型是否为资源密集型；

其中，所述故障匹配识别模块判断故障告警信息X的业务类型是否为资源密集型，若是资源密集型，则执行步骤610；若不是资源密集型，则执行步骤611。

步骤610：容器调度模块执行集群资源调度策略；

具体地，在故障告警X的业务类型为资源密集型的情况下，容器调度模块通过故障告警信息X的告警来源节点UUID获取对应节点的CPU利用率、内存使用率、磁盘IO使用率以及系统负载等信息。然后，调用故障告警信息X的告警窗口的监控数据，获取与故障告警信息X对应的容器的CPU利用率、内存使用率、磁盘IO使用率等资源使用情况。

若当前节点的资源使用率未超过预设节点的第一资源健康阈值，则通过告警窗口的监控数据，判断当前资源相对于容器所分配的资源最大值的占比是否超过预设的第二资源健康阈值。若超过第二资源健康阈值，则增加与故障告警信息X对应的容器所分配的资源最大值。

若当前节点的资源使用率超过预设节点的第一资源健康阈值，则说明当前客户端节点出现资源瓶颈，需要进行跨节点调度。具体地，容器调度模块对除当前客户端之外的其他客户端的资源使用率进行排序，将使用率最低，且各资源的使用率均不超过第一资源健康阈值的节点作为新节点，再将故障告警X对应的容器调度到新节点。示例性地，利用相关技术K8s的kube-scheduler，将故障告警X对应的容器调度到新节点，或者可以通过将容器镜像导出，再部署到新节点启动方式。

在资源调度完成后，返回告警修复完成标志至本地故障告警采集上报模块，并执行步骤614。

步骤611：故障匹配识别模块遍历服务器故障修复知识库(即服务器本地数据库)，判断是否有与故障告警信息X匹配的故障告警信息；

这里，服务器利用故障告警信息X的告警具体内容在故障修复知识库中查找匹配的故障告警信息，若存在匹配的故障告警信息，则执行步骤612；若不存在匹配的故障告警信息，则执行步骤613。

步骤612：故障匹配识别模块下发匹配的故障解决方案到对应的客户端；

这里，故障匹配识别模块在故障修复知识库查找到与匹配的故障告警信息后，再从故障修复知识库中获取对应的故障解决方案。然后，利用故障告警信息X的告警来源节点UUID，将故障解决方案下发到故障告警X对应的客户端，使得客户端利用所述故障解决方案进行故障修复，如修复客户端的文件系统损坏、宕机等故障。具体地，客户端接收下发的故障处理脚本后，利用故障处理脚本进行故障修复，并在修复完成返回一个告警修复完成标志给本地故障告警采集上报模块。

相应地，客户端将下发的故障解决方案存储至本地数据库中，便于针对重复的故障告警的进行自动化处理。然后，执行步骤614。

步骤613：故障匹配识别模块更新第一故障告警信息中的告警等级为第一等级告警，并通过上报人工干预模块获取故障解决方案；

其中，所述第一等级告警表征当前无法处理的故障。

实际应用时，人工干预模块针对上报的故障告警信息X输入对应的故障解决方案和修复失败的回退脚本，并存储至故障修复知识库中。故障匹配识别模块接收对应的故障解决方案后，将接收的故障解决方案下发至故障告警信息X对应的客户端，使得客户端利用下发的故障解决方案，对故障告警进行修复。在故障告警修复完成后，需要向本地故障告警采集上报模块返回告警修复完成标志。

这里，客户端接收到下发的故障解决方案后，将所述故障解决方案存储至本地数据库中，便于针对重复的故障告警进行自动化处理。然后，执行步骤614。

步骤614：本地故障告警采集上报模块获取故障告警X修复后在预设的告警监测周期阈值T2时间内所有容器上报的故障告警信息形成告警集合ALARMS_X；

实际应用时，T2的取值应大于本地故障告警采集上报模块所监测到的发生故障告警信息后所有的故障告警信息的上报周期。

这里，本地故障告警采集上报模块通过获取告警集合ALARMS_X，用来判断故障告警X是否修复成功，还可以判断告警队列和本地缓存池中随着故障告警X修复成功而修复的故障告警。

步骤615：本地故障告警采集上报模块判断告警集合ALARMS_X是否为空；

这里，若告警集合ALARMS_X为空，执行步骤616；若告警集合ALARMS_X不为空，则执行步骤617；

步骤616：本地故障告警采集上报模块清空此时告警队列、告警本地缓存池中所有的故障告警信息；

这里，由于告警集合包含了T2时间内所有容器上报的故障告警信息，若告警集合ALARMS_X为空，则说明T2时间内客户端内所有容器业务运行正常，没有故障告警上报。也就是说，随着故障告警X修复成功，告警队列和本地缓存池中所有的故障告警信息也修复成功。因此，本地故障告警采集上报模块清空告警队列和缓存池中所有的故障告警信息，并结束当前故障告警处理。

实际应用时，容器上报的故障告警是包含进程级的故障(即第四等级故障告警)、应用级的故障(即第三等级故障告警)、节点故障或者资源导致的故障(即第二等级故障告警)、以及当前无法处理的故障(即第一等级故障告警)四种故障类型的。若所有容器上报的故障告警为应用级的故障、节点故障或者资源导致的故障类型，那么，当故障告警X修复成功后，除故障告警X外的容器上报的故障告警是可以随着故障告警X的修复成功而修复的，此时，本地故障告警采集上报模块便可以清空告警队列和本地缓存池中所有的故障告警信息。

步骤617：本地故障告警采集上报模块判断ALARMS_X中是否有与故障告警信息X匹配的故障告警信息；

这里，当告警集合不为空时，本地故障告警采集上报模块可以在告警集合中查找到与故障告警信息X的告警具体内容和告警来源容器ID匹配的故障告警信息。若存在，说明故障告警X未修复成功，则执行步骤618；若不存在，说明故障告警X修复成功，则执行步骤619。

步骤618：本地故障告警采集上报模块运行故障告警X修复回退脚本；

当本地故障告警采集上报模块查找到与故障告警信息X匹配的故障告警信息，则说明故障告警X修复失败。这时，由于本地告警匹配处理模块或者故障匹配识别模块在下发故障解决方案时，也同时下发了与故障解决方案相关联的修复回退脚本。那么，在故障告警X修复失败的时候，便执行对应的修复回退脚本，并将故障告警信息X上报人工干预模块，进行异常情况处理。

然后，客户端利用人工干预模块下发的故障解决方案对故障告警X再次进行故障告警修复。修复完成后，返回告警修复完成标志至本地故障告警采集上报模块，并执行步骤614，以判断故障告警X是否修复成功。

步骤619：本地故障告警采集上报模块从队首到队尾遍历告警队列，依次删除与ALARMS-X集合中故障告警信息中的具体告警内容和告警来源容器ID不相同的故障告警信息；

这里，本地故障告警采集上报模块读取告警队列中的故障告警信息，并将告警队列中故障告警信息与告警集合中的故障告警信息相匹配，将与告警集合中故障告警信息中的具体告警内容和告警来源容器ID不相同的故障告警信息删除。这是因为：告警队列中的故障告警信息是与故障告警信息X相关联的，而告警集合中的故障告警信息是在故障告警X修复完成后的T2时间内获取的。若告警队列中的故障告警信息中的具体告警内容和告警来源容器ID与告警集合中的故障告警信息相匹配，则说明相同的故障告警信息重复上报，即故障告警信息对应的故障告警没有修复成功。若告警队列中的故障告警信息与告警集合中的故障告警信息不匹配，则说明在故障告警X修复完成后，告警队列中的故障告警信息没有再次上报，出现在告警集合中，即告警队列中的故障告警信息修复成功。因此，通过将告警队列中的故障告警信息与告警集合中的故障告警信息相匹配，可以确定随着故障告警X的修复而修复成功的故障告警信息，然后，从告警队列中删除修复成功的故障告警信息。然后，执行步骤620。

步骤620：本地故障告警采集上报模块判断告警队列是否为空；

这里，在遍历告警队列后，本地故障告警采集上报模块判断当前告警队列是否为空，若告警队列为空，则表明对当前容器上报的所有故障告警信息修复完成，执行步骤621，若告警队列不为空，则执行步骤622。

步骤621：本地故障告警采集上报模块从本地缓存池中调度下一个故障告警信息，进行故障告警处理；

实际应用时，对告警队列中故障告警X和与故障告警X相关联的故障告警修复完成后，若本地缓存池不为空，则本地故障告警采集上报模块根据本地缓存池中剩余的故障告警信息中的告警时间确定最早生成的故障告警信息，例如故障告警信息Z，再进行故障告警处理，即执行步骤602。

这里，若本地缓存池为空，则说明当前容器上报的所有故障告警信息修复完成，故障处理系统便停止故障告警处理。

步骤622：本地故障告警采集上报模块调度告警队列队首的故障告警信息，即采用步骤602，开始执行故障告警处理。

这里，遍历告警队列中的故障告警信息，在删除告警队列中与告警集合的故障告警信息不匹配的故障告警信息后，针对当前告警队列队首的故障告警信息Y，本地故障告警采集上报模块可以调度故障告警信息Y，进行故障告警修复处理，即执行步骤602。

从上面的描述可以看出，本应用实施例中，通过设计了一种故障告警格式，将容器场景下故障告警分为四个等级，结合本地告警匹配处理模块和故障匹配识别模块组成的多级故障告警匹配处理模块，可以对容器上报的故障告警信息进行匹配处理，逐级上报。针对不同故障告警信息中的告警等级，调用客户端或者服务器的资源进行响应处理。这样，可以有效减轻大量告警并发上报对服务器造成的压力，提高了故障告警的处理效率。

同时，由于每个客户端节点上均配置了缓存池和告警队列，可用于故障告警信息的本地存储及初步过滤筛选后进行调度，帮助用户高效定位和理清故障告警信息的先后逻辑，节省了用户的时间成本。

此外，本应用实施例中，对于不同告警等级的故障告警信息，分别设置了不同的响应及处理方法。针对常见的第四等级告警和第三等级告警，在客户端的本地数据库中预设解决方法。若各客户端的容器业务短时间内出现相同的故障告警，可以直接在本地故障知识库查找并下发故障解决方案，无需再上报至服务器匹配。而针对其他未知故障告警问题，第一次可以通过人工干预，然后，将故障解决方案固化下来录入到服务器的故障处理知识库中，再由服务器将故障解决方案下发到故障告警信息对应的客户端进行故障修复。这样，用户在处理容器场景下大量故障告警时，遇到同样的故障多次出现时，无需再进行重复处理。通过上述方式，若此后遇到相同的故障告警信息时，便可以通过客户端和服务器进行故障告警信息的匹配，实现了无人工干预的自动化处理，使得故障处理系统具备一定的自学习能力，从而实现一定程度的人工智能自动化响应及处理常见故障功能。

为了实现本申请实施例的方案，本申请实施例还提供一种故障处理装置，设置在客户端上，如图7所示，该装置包括：

第一获取单元701，用于获取第一故障告警信息；所述第一故障告警信息表征对应的容器业务出现故障；

第一处理单元702，用于在本地数据库查找与所述第一故障告警信息匹配的故障解决方案；当在本地数据库查找到与所述第一故障告警信息匹配的故障解决方案时，利用查找到的故障解决方案进行故障修复；

第一发送单元703，用于当在本地数据库未查找到与所述第一故障告警信息匹配的故障解决方案时，向服务器上报所述第一故障告警信息；

所述第一获取单元701，还用于接收所述服务器下发的故障解决方案，并利用所述下发的故障解决方案进行故障修复。

这里，第一获取单元701的获取第一故障告警信息的功能和第一发送单元703向服务器上报第一故障告警信息的功能相当于应用实施例中本地故障告警采集上报模块的功能。

第一处理单元702的查找匹配的故障解决方案的功能和向服务器上报第一故障告警信息的功能相当于应用实施例中本地告警匹配处理模块的功能。

其中，在一实施例中，所述第一获取单元701，用于：

将容器上报的第一故障告警信息存储至缓存池；

当根据所述第一故障告警信息中的告警时间确定调度所述第一故障告警信息对应的故障告警时，从所述缓存池中读取所述第一故障告警信息。

在一实施例中，所述第一处理单元702，还用于：

读取所述第一故障告警信息后，从所述缓存池中删除所述第一故障告警信息。

在一实施例中，所述容器上报的第一故障告警信息中的告警等级为空；所述第一获取单元701，用于：

当确定所述容器上报的第一故障告警信息对应的故障告警的告警等级为第四等级时，利用确定的告警等级更新所述第一故障告警信息中的告警等级，并将更新后的第一故障告警信息存储至所述缓存池；或者，

当确定所述容器上报的第一故障告警信息对应的故障告警的告警等级不为第四等级时，直接将所述容器上报的第一故障告警信息存储至所述缓存池。

在一实施例中，所述第一处理单元702，还用于：

当所述第一故障告警信息中的告警等级为第四等级告警时，确定能够在本地数据库查找到与所述第一故障告警信息匹配的故障解决方案；所述第四等级告警表征进程级的故障；

当所述第一故障告警信息中的告警等级为第三等级告警时，在本地数据库查找与所述第一故障告警信息匹配的故障解决方案；所述第三等级告警表征应用级的故障；当在本地数据库未查找到与所述第一故障告警信息匹配的故障解决方案时，将所述第一故障告警信息中的告警等级由第三等级告警更新为第二等级告警，向所述服务器上报更新后的第一故障告警信息；所述第二等级告警表征所述容器所在节点故障或者资源导致的故障；其中，

当从所述缓存池中读取的第一故障告警信息中的告警等级为空时，将读取的第一故障告警信息中的告警等级更新为第三等级，并在本地数据库查找与更新后的第一故障告警信息匹配的故障解决方案。

在一实施例中，所述第一处理单元702，还用于：

将所述下发的故障解决方案存储至本地数据库。

实际应用时，所述第一发送单元703可由故障处理装置中的通信接口实现；所述第一处理单元702可由故障处理装置中的处理器实现；所述第一获取单元701可由故障处理装置中的处理器结合通信接口实现。

为了实现本申请实施例服务器侧的方法，本申请实施例还提供了一种故障处理装置，设置在服务器上，如图8所示，该装置包括：

第二获取单元801，用于接收客户端上报的第一故障告警信息；所述第一故障告警信息表征对应的容器业务出现故障；

第二处理单元802，用于在所述服务器本地数据库查找与所述第一故障告警信息匹配的故障解决方案；所述客户端本地数据库未存储与所述第一故障告警信息匹配的故障解决方案；

第二发送单元803，用于所述第二处理单元802在所述服务器本地数据库查找到与所述第一故障告警信息匹配的故障解决方案时，向所述客户端下发与所述第一故障告警信息匹配的故障解决方案。

这里，第二处理单元802的在本地数据库查找匹配的故障解决方案的功能相当于应用实施例中故障匹配识别模块的功能；

本地数据库的功能相当于应用实施例中故障修复知识库的功能。

在一实施例中，所述第二处理单元802，还用于：

当所述第一故障告警信息中的业务类型不属于资源密集型时，在所述服务器本地数据库查找与所述第一故障告警信息匹配的故障解决方案；

所述第二发送单元803，还用于：

在所述服务器本地数据库未查找到与所述第一故障告警信息匹配的故障解决方案时，更新所述第一故障告警信息中的告警等级为第一等级告警，上报更新的第一故障告警信息；所述第一等级告警表征当前无法处理的故障；

所述第二发送单元803，还用于：

接收反馈的所述第一故障告警信息对应的故障解决方案，并下发所述第一故障告警信息对应的故障解决方案至所述客户端。

在一实施例中，所述第二处理单元802，还用于：

将反馈的所述第一故障告警信息对应的故障解决方案存储至所述服务器本地数据库。

实际应用时，所述第二获取单元801可由故障处理装置中的通信接口实现；所述第二处理单元802可由故障处理装置中的处理器实现；所述第二发送单元803可由故障处理装置中的处理器结合通信接口实现。

需要说明的是：上述实施例提供的故障处理装置在进行故障处理时，仅以上述各程序单元的划分进行举例说明，实际应用中，可以根据需要而将上述处理分配由不同的程序单元完成，即将装置的内部结构划分成不同的程序单元，以完成以上描述的全部或者部分处理。另外，上述实施例提供的故障处理装置与故障处理方法实施例属于同一构思，其具体实现过程详见方法实施例，这里不再赘述。

基于上述程序模块的硬件实现，且为了实现本申请实施例客户端侧的方法，本申请实施例还提供了一种客户端，如图9所示，该客户端900包括：

第一通信接口901，能够与服务器进行信息交互；

第一处理器902，与所述第一通信接口901连接，以实现与服务器进行信息交互，用于运行计算机程序时，执行上述客户端侧一个或多个技术方案提供的方法；所述计算机程序存储在第一存储器903上。

具体地，所述第一通信接口901，用于获取第一故障告警信息；所述第一故障告警信息表征对应的容器业务出现故障；还用于当在本地数据库未查找到与所述第一故障告警信息匹配的故障解决方案时，向服务器上报所述第一故障告警信息；还用于接收所述服务器下发的故障解决方案，并利用所述下发的故障解决方案进行故障修复。

所述第一处理器902，用于在本地数据库查找与所述第一故障告警信息匹配的故障解决方案；还用于当在本地数据库查找到与所述第一故障告警信息匹配的故障解决方案时，利用查找到的故障解决方案进行故障修复。

其中，在一实施例中，所述第一处理器902，用于：

将容器上报的第一故障告警信息存储至缓存池；

当根据所述第一故障告警信息中的告警时间确定调度所述第一故障告警信息对应的故障告警时，从所述缓存池中读取所述第一故障告警信息。

在一实施例中，所述第一处理器902，还用于读取所述第一故障告警信息后，从所述缓存池中删除所述第一故障告警信息。

在一实施例中，所述第一处理器902，用于：

当确定所述容器上报的第一故障告警信息对应的故障告警的告警等级为第四等级时，利用确定的告警等级更新所述第一故障告警信息中的告警等级，并将更新后的第一故障告警信息存储至所述缓存池；或者，

当确定所述容器上报的第一故障告警信息对应的故障告警的告警等级不为第四等级时，直接将所述容器上报的第一故障告警信息存储至所述缓存池。

在一实施例中，所述第一处理器902，还用于当所述第一故障告警信息中的告警等级为第四等级告警时，确定能够在本地数据库查找到与所述第一故障告警信息匹配的故障解决方案；所述第四等级告警表征进程级的故障；

当所述第一故障告警信息中的告警等级为第三等级告警时，在本地数据库查找与所述第一故障告警信息匹配的故障解决方案；所述第三等级告警表征应用级的故障；当在本地数据库未查找到与所述第一故障告警信息匹配的故障解决方案时，将所述第一故障告警信息中的告警等级由第三等级告警更新为第二等级告警，通过所述第一通信接口901向所述服务器上报更新后的第一故障告警信息；所述第二等级告警表征所述容器所在节点故障或者资源导致的故障；其中，

当从所述缓存池中读取的第一故障告警信息中的告警等级为空时，将读取的第一故障告警信息中的告警等级更新为第三等级，并在本地数据库查找与更新后的第一故障告警信息匹配的故障解决方案。

在一实施例中，所述第一处理器902，还用于将所述下发的故障解决方案存储至本地数据库。

需要说明的是：第一处理器902的具体处理过程可参照上述方法理解。

当然，实际应用时，客户端中的各个组件通过总线系统904耦合在一起。可理解，总线系统904用于实现这些组件之间的连接通信。总线系统904除包括数据总线之外，还包括电源总线、控制总线和状态信号总线。但是为了清楚说明起见，在图9中将各种总线都标为总线系统904。

本申请实施例中的第一存储器903用于存储各种类型的数据以支持客户端900的操作。这些数据的示例包括：用于在客户端900上操作的任何计算机程序。

上述本申请实施例揭示的方法可以应用于所述第一处理器902，或者由所述第一处理器902实现。所述第一处理器902可能是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法的各步骤可以通过所述第一处理器902中的硬件的集成逻辑电路或者软件形式的指令完成。上述的所述第一处理器902可以是通用处理器、数字信号处理器(DSP，Digital Signal Processor)，或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。所述第一处理器902可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者任何常规的处理器等。结合本申请实施例所公开的方法的步骤，可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于存储介质中，该存储介质位于第一存储器903，所述第一处理器902读取第一存储器903中的信息，结合其硬件完成前述方法的步骤。

在示例性实施例中，客户端900可以被一个或多个应用专用集成电路(ASIC，Application Specific Integrated Circuit)、DSP、可编程逻辑器件(PLD，ProgrammableLogic Device)、复杂可编程逻辑器件(CPLD，Complex Programmable Logic Device)、现场可编程门阵列(FPGA，Field-Programmable Gate Array)、通用处理器、控制器、微控制器(MCU，Micro Controller Unit)、微处理器(Microprocessor)、或者其他电子元件实现，用于执行前述方法。

基于上述程序模块的硬件实现，且为了实现本申请实施例服务器侧的方法，本申请实施例还提供了一种服务器，如图10所示，该服务器1000包括：

第二通信接口1001，能够与客户端进行信息交互；

第二处理器1002，与所述第二通信接口1001连接，以实现与客户端进行信息交互，用于运行计算机程序时，执行上述服务器侧一个或多个技术方案提供的方法；所述计算机程序存储在第二存储器1003上。

具体地，所述第二通信接口1001，用于接收客户端上报的第一故障告警信息；所述第一故障告警信息表征对应的容器业务出现故障；还用于在所述服务器本地数据库查找到与所述第一故障告警信息匹配的故障解决方案时，向所述客户端下发与所述第一故障告警信息匹配的故障解决方案。

所述第二处理器1002，用于在所述服务器本地数据库查找与所述第一故障告警信息匹配的故障解决方案；所述客户端本地数据库未存储与所述第一故障告警信息匹配的故障解决方案。

在一实施例中，所述第二处理器1002，还用于当所述第一故障告警信息中的业务类型不属于资源密集型时，在所述服务器本地数据库查找与所述第一故障告警信息匹配的故障解决方案；

所述第二处理器1002，还用于在所述服务器本地数据库未查找到与所述第一故障告警信息匹配的故障解决方案时，更新所述第一故障告警信息中的告警等级为第一等级告警，并通过所述第二通信接口1001上报更新的第一故障告警信息；所述第一等级告警表征当前无法处理的故障；还用于接收反馈的所述第一故障告警信息对应的故障解决方案，并下发所述第一故障告警信息对应的故障解决方案至所述客户端。

在一实施例中，所述第二处理器1002，还用于将反馈的所述第一故障告警信息对应的故障解决方案存储至所述服务器本地数据库。

需要说明的是：所述第二处理器1002的具体处理过程可参照上述方法理解。

当然，实际应用时，服务器中的各个组件通过总线系统1004耦合在一起。可理解，总线系统1004用于实现这些组件之间的连接通信。总线系统1004除包括数据总线之外，还包括电源总线、控制总线和状态信号总线。但是为了清楚说明起见，在图10中将各种总线都标为总线系统1004。

本申请实施例中的第二存储器1003用于存储各种类型的数据以支持服务器1000的操作。这些数据的示例包括：用于在服务器1000上操作的任何计算机程序。

上述本申请实施例揭示的方法可以应用于所述第二处理器1002中，或者由所述第二处理器1002实现。所述第二处理器1002可能是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法的各步骤可以通过所述第二处理器1002中的硬件的集成逻辑电路或者软件形式的指令完成。上述的所述第二处理器1002可以是通用处理器、DSP，或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。所述第二处理器1002可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者任何常规的处理器等。结合本申请实施例所公开的方法的步骤，可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于存储介质中，该存储介质位于第二存储器1003，所述第二处理器1002读取第二存储器1003中的信息，结合其硬件完成前述方法的步骤。

在示例性实施例中，服务器1000可以被一个或多个ASIC、DSP、PLD、CPLD、FPGA、通用处理器、控制器、MCU、Microprocessor、或其他电子元件实现，用于执行前述方法。

为了实现本申请实施例提供的方法，本申请实施例还提供了一种故障处理系统，如图11所示，该系统包括：客户端1101和服务器1102。

这里，需要说明的是：所述客户端1101和服务器1102的具体处理过程已在上文详述，这里不再赘述。

在示例性实施例中，本申请实施例还提供了一种存储介质，即计算机存储介质，具体为计算机可读存储介质，例如包括存储计算机程序的第一存储器903，上述计算机程序可由客户端900的第一处理器902执行，以完成前述客户端侧方法所述步骤，再比如包括存储计算机程序的第二存储器1003，上述计算机程序可由服务器1000的第二处理器1002执行，以完成前述服务器侧方法所述步骤。计算机可读存储介质可以是只读存储器(ROM，ReadOnly Memory)、可编程只读存储器(PROM，Programmable Read-Only Memory)、可擦除可编程只读存储器(EPROM，Erasable Programmable Read-Only Memory)、电可擦除可编程只读存储器(EEPROM，Electrically Erasable Programmable Read-Only Memory)、磁性随机存取存储器(FRAM，ferromagnetic random access memory)、快闪存储器(Flash Memory)、磁表面存储器、光盘、或只读光盘(CD-ROM，Compact Disc Read-Only Memory)；磁表面存储器可以是磁盘存储器或磁带存储器。

需要说明的是：“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。

另外，本申请实施例所记载的技术方案之间，在不冲突的情况下，可以任意组合。

以上所述，仅为本申请的较佳实施例而已，并非用于限定本申请的保护范围，凡在本申请的精神和原则之内所作的任何修改、等同替换和改进等，均应包含在本申请的保护范围之内。

Claims (10)

1.一种故障处理方法，其特征在于，应用于客户端，包括：

获取第一故障告警信息；所述第一故障告警信息表征对应的容器业务出现故障；

在本地数据库查找与所述第一故障告警信息匹配的故障解决方案；

当在本地数据库查找到与所述第一故障告警信息匹配的故障解决方案时，利用查找到的故障解决方案进行故障修复；当在本地数据库未查找到与所述第一故障告警信息匹配的故障解决方案时，向服务器上报所述第一故障告警信息；

接收所述服务器下发的故障解决方案，并利用所述下发的故障解决方案进行故障修复。

2.根据权利要求1所述的方法，其特征在于，所述获取第一故障告警信息，包括：

将容器上报的第一故障告警信息存储至缓存池；

当根据所述第一故障告警信息中的告警时间确定调度所述第一故障告警信息对应的故障告警时，从所述缓存池中读取所述第一故障告警信息。

3.根据权利要求2所述的方法，其特征在于，所述容器上报的第一故障告警信息中的告警等级为空；

所述将容器上报的第一故障告警信息存储至缓存池，包括：

当确定所述容器上报的第一故障告警信息对应的故障告警的告警等级为第四等级时，利用确定的告警等级更新所述第一故障告警信息中的告警等级，并将更新后的第一故障告警信息存储至所述缓存池；或者，

当确定所述容器上报的第一故障告警信息对应的故障告警的告警等级不为第四等级时，直接将所述容器上报的第一故障告警信息存储至所述缓存池。

4.根据权利要求3所述的方法，其特征在于，

当所述第一故障告警信息中的告警等级为第四等级告警时，确定能够在本地数据库查找到与所述第一故障告警信息匹配的故障解决方案；所述第四等级告警表征进程级的故障；

当所述第一故障告警信息中的告警等级为第三等级告警时，在本地数据库查找与所述第一故障告警信息匹配的故障解决方案；所述第三等级告警表征应用级的故障；当在本地数据库未查找到与所述第一故障告警信息匹配的故障解决方案时，将所述第一故障告警信息中的告警等级由第三等级告警更新为第二等级告警，向所述服务器上报更新后的第一故障告警信息；所述第二等级告警表征所述容器所在节点故障或者资源导致的故障；其中，

当从所述缓存池中读取的第一故障告警信息中的告警等级为空时，将读取的第一故障告警信息中的告警等级更新为所述第三等级告警，并在本地数据库查找与更新后的第一故障告警信息匹配的故障解决方案。

5.一种故障处理方法，其特征在于，应用于服务器，包括：

接收客户端上报的第一故障告警信息；所述第一故障告警信息表征对应的容器业务出现故障；

在所述服务器本地数据库查找与所述第一故障告警信息匹配的故障解决方案；所述客户端本地数据库未存储与所述第一故障告警信息匹配的故障解决方案；

在所述服务器本地数据库查找到与所述第一故障告警信息匹配的故障解决方案时，向所述客户端下发与所述第一故障告警信息匹配的故障解决方案。

6.根据权利要求5所述的方法，其特征在于，所述第一故障告警信息中的告警等级为第二等级告警；所述第二等级告警表征所述容器所在节点故障或者资源导致的故障；

当所述第一故障告警信息中的业务类型不属于资源密集型时，在所述服务器本地数据库查找与所述第一故障告警信息匹配的故障解决方案；

在所述服务器本地数据库未查找到与所述第一故障告警信息匹配的故障解决方案时，更新所述第一故障告警信息中的告警等级为第一等级告警，上报更新的第一故障告警信息；所述第一等级告警表征当前无法处理的故障；

接收反馈的所述第一故障告警信息对应的故障解决方案，并下发所述第一故障告警信息对应的故障解决方案至所述客户端。

7.根据权利要求6所述的方法，其特征在于，所述方法还包括：

将反馈的所述第一故障告警信息对应的故障解决方案存储至所述服务器本地数据库。

8.一种客户端，其特征在于，包括：第一处理器和用于存储能够在处理器上运行的计算机程序的第一存储器，

其中，所述第一处理器用于运行所述计算机程序时，执行权利要求1至4任一项所述方法的步骤。

9.一种服务器，其特征在于，包括：第二处理器和用于存储能够在处理器上运行的计算机程序的第二存储器，

其中，所述第二处理器用于运行所述计算机程序时，执行权利要求5至7任一项所述方法的步骤。

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

Images