CN110262917A - 宿主机自愈方法、装置、计算机设备及存储介质 - Google Patents

Abstract

本申请实施例提供一种宿主机自愈方法、装置、计算机设备及存储介质，其涉及云计算技术领域，可应用于PaaS平台中。所述方法包括：若检测到宿主机出现异常且满足自愈的条件，根据所出现的异常类型对宿主机进行自愈，其中，不同的异常类型所对应的自愈方式不同，不同的异常类型所对应的自愈的条件不同；在自愈后的预设时间内，若检测到宿主机出现相同异常，则进行报警提示。本申请实施例在宿主机出现异常时，先进行自愈，减少宿主机出现异常的概率；由于自愈是检测到出现异常且满足自愈的条件即可开始自愈，实时响应异常，因此不会因为异常的出现，而影响宿主机上容器的运行，提高了宿主机运行的稳定性；对宿主机进行自愈以减少处理异常的人力成本。

Description

宿主机自愈方法、装置、计算机设备及存储介质

技术领域

本申请涉及云计算技术领域，尤其涉及一种宿主机自愈方法、装置、计算机设备及存储介质。

背景技术

在云平台中，如在PaaS(Platform-as-a-Service，平台即服务)平台中，有大量的宿主机。由于宿主机可能一直在使用，因此，宿主机很容易出现一些异常，如宿主机上数据卷的存储容量快用完了；如宿主机内的一些组件挂掉了，如docker组件挂掉了；如存储镜像的镜像仓库快满了等等。若出现了异常，则进行提醒，再由相关人员进行处理，那么大量的宿主机需要大量的相关人员，如此需要大量的人力成本和时间成本；同时宿主机出现异常后，相关人员一个一个的处理，必然会导致有些异常较长时间仍未处理，会影响云平台的运行。

发明内容

本申请实施例提供一种宿主机自愈方法、装置、计算机设备及存储介质，可实时响应异常，减少宿主机出现异常的概率，提高了宿主机运行的稳定性。

第一方面，本申请实施例提供了一种宿主机自愈方法，包括：

若检测到宿主机出现异常且满足自愈的条件，根据所出现的异常类型对宿主机进行自愈，其中，不同的异常类型所对应的自愈方式不同，不同的异常类型所对应的自愈的条件不同；在自愈后的预设时间内，若检测到宿主机出现相同异常，则进行报警提示。

第二方面，本发明实施例提供了一种宿主机自愈装置，该宿主机自愈装置包括用于执行上述第一方面所述的方法对应的单元。

第三方面，本发明实施例提供了一种计算机设备，所述计算机设备包括存储器，以及与所述存储器相连的处理器；

所述存储器用于存储计算机程序，所述处理器用于运行所述存储器中存储的计算机程序，以执行上述第一方面所述的方法。

第四方面，本发明实施例提供了一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序被处理器执行时，实现上述第一方面所述的方法。

本申请实施例在检测到宿主机出现异常且满足自愈的条件下，根据所出现的异常类型对宿主机进行自愈，如此，在宿主机出现异常时，先进行自愈，减少宿主机出现异常的概率；由于自愈是检测到出现异常且满足自愈的条件即可开始自愈，实时响应异常，因此不会因为异常的出现，而影响宿主机上容器的运行，提高了宿主机运行的稳定性；对宿主机进行自愈以减少处理异常的人力成本。

附图说明

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

图1是本申请实施例提供的宿主机自愈方法的流程示意图；

图2是本申请实施例提供的宿主机自愈方法的子流程示意图；

图3是本申请实施例提供的宿主机自愈方法的子流程示意图；

图4是本申请实施例提供的宿主机自愈方法的子流程示意图；

图5是本申请实施例提供的宿主机自愈方法的子流程示意图；

图6是本申请实施例提供的宿主机自愈装置的示意性框图；

图7是本申请实施例提供的自愈单元的示意性框图；

图8是本申请实施例提供的卷自愈单元的示意性框图；

图9是本申请实施例提供的另一自愈单元的示意性框图；

图10是本申请实施例提供的组件自愈单元的示意性框图；

图11是本申请实施例提供的计算机设备的示意性框图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

图1是本申请实施例提供的宿主机自愈方法的流程示意图。如图1所示，该方法包括S101-S102。

S101，若检测到宿主机出现异常且满足自愈的条件，根据所出现的异常类型对宿主机进行自愈，其中，不同的异常类型所对应的自愈方式不同，不同的异常类型所对应的自愈的条件不同。

其中，异常类型包括多种，如宿主机的数据卷异常、宿主机上本地应用镜像异常、宿主机上的组件异常、宿主机的资源异常等等。不同的异常类型所对应的自愈方式不同，不同的异常类型所对应的自愈的条件不同。

宿主机上包括数据卷，在一实施例中，所述异常类型包括宿主机的数据卷异常。根据平台中宿主机上的数据卷的情况以及数据卷的用途将数据卷分为三类，这三类分别是：1、容器应用的日志卷，也可称为容器日志目录，也就是存放容器应用日志的数据卷，如存在容器应用日志的NAS(Network Attached Storage，网络附属存储)卷；2、宿主机本地卷，包括docker的数据卷(datavolume，也可称为data卷)、docker的元数据卷(metadata volume，也可称为metadata卷)、宿主机的根卷等；3、容器应用的应用卷。需要注意的是，对数据卷的分类还可以按照其他的分类方式。

如图2所示，所述异常类型包括宿主机的数据卷异常，如此，对宿主机进行自愈，包括：对宿主机上的数据卷进行自愈。步骤S101包括以下步骤S201-S203。

S201，若检测到宿主机上的数据卷的存储容量达到第一预设容量，则判定检测到宿主机上的数据卷出现异常且满足自愈的条件。

可按照预设时间间隔来检测宿主机上数据卷的大小，如可通过docker info来进行检测。其中，可以检测宿主机上数据卷的总大小(Space Total)、数据卷的已用大小(Space Used)、数据卷可用大小(Space Available)。

Space Used:xxx MB

Space Total:xxxxx MB

Space Available:xxxxx MB

当space Used占比超过数据卷的第一预设容量，如第一预设容量可以为90％或其他数值，则判定检测到宿主机的数据卷出现异常且满足自愈的条件。

S202，检测宿主机上的出现异常的数据卷的类型。

如检测引发异常的数据卷，也即异常是从哪个数据卷发出，并根据该数据卷与所保存的数据之间的关系，确定出现异常的数据卷的类型。数据卷与所保存的数据之间的关系可保存在数据库中，也可保存在其他位置，如保存在宿主机的某个文件中。

S203，根据出现异常的数据卷的类型对所述宿主机上的数据卷进行自愈。

数据卷的类型包括容器应用的日志卷、宿主机本地卷、容器应用的应用卷。不同数据卷的类型所对应的自愈方式不同。

在一实施例中，如图3所示，步骤S203包括以下步骤S301-S303。

S301，若所述宿主机上出现异常的数据卷为容器应用的日志卷，遍历所述数据卷中的大文件。

其中，容器应用的日志卷中保存的是容器应用的各类日志，如标准输出日志、数据日志、访问日志等。数据卷中的大文件可以理解为文件的存储容量大于某一设定的容量，或者数据卷中文件的存储容量按照从大到小的顺序排列后占前预设名次的文件，如存储容量按照从大到小的顺序排列后占前10的文件。

S302，判断所述大文件是否为标准输出日志文件。

标准输出日志文件指的是容器应用启动过程中的输出日志文件，有特定的日志文件格式，如.out文件格式。

若所述大文件为标准输出日志文件，执行步骤S303；若所述大文件为非标准输出日志文件，执行步骤S304。

S303，执行删除脚本，以删除所述大文件中的标准输出日志文件。

可以理解地，应用的标准输出日志的利用价值最低，也就是只需要保留当天的日志即可，这种日志则可以直接删除，不会影响到应用业务的后续分析。

S304，将所述大文件进行压缩归档。

可以理解地，若大文件不为非标准输出日志文件，如该大文件为数据日志，访问日志等，这种就很有价值，这种日志则需要进行压缩归档，即先进性压缩，在进行归档。其中，该云平台中有单独的归档服务器，可根据大文件中保存的数据的内容进行归档。

以上步骤S301-S304对容器应用的日志卷进行自愈，即将数据卷中的标准输出日志的大文件进行删除，其他的日志类型的大文件进行压缩归档。

S305，若所述宿主机上出现异常的数据卷为宿主机本地卷，检测所述数据卷是宿主机本地卷中的docker的数据卷、docker的元数据卷还是宿主机的根卷。

其中，docker的数据卷中存储的是容器应用的应用包信息；docker的元数据卷中存放的是tag、name、status等信息。

S306，若所述数据卷为docker的数据卷，执行第一清除脚本，以清除所述宿主机上残留的容器应用包的信息。

S307，若所述数据卷为docker的元数据卷，执行第二清除脚本，以清除所述宿主机上异常退出的容器的数据。

由于meatadata卷中存放的是tag、name、status等信息，这些信息会随着执行的容器数的增大，将meatadata卷撑满，同时异常退出的容器，无法将相应的tag跟status等信息进行移除，此时则会存在垃圾数据在meatadata卷中。如第二清除脚本可以为：dockerps-aqfstatus＝exited|xargs dockerrm。执行该第二清楚脚本以清楚宿主机上异常退出的容器的垃圾数据。

S308，若所述数据卷为宿主机的根卷，检测宿主机当前所处的应用环境，并根据宿主机当前所处的应用环境，对所述宿主机的根卷中的预设文件进行相应处理。

宿主机当前所处的应用环境，指的是该宿主机属于哪个应用环境下的宿主机。其中，应用环境包括生产环境、测试环境、开发环境等。其中，生产环境意味着该宿主机上的资源(如安装在宿主机上的容器、宿主机上的CPU等资源)对接外部环境，或者供外部用户进行访问；测试环境意味着该宿主机上的资源供测试使用；开发环境意味着该宿主机上的资源供开发使用。根据宿主机当前所处的应用环境，对所述宿主机的根卷中的预设文件进行相应处理，包括：若宿主机当前所处的应用环境为生产环境，对所述宿主机的根卷中的预设文件进行压缩处理；若宿主机当前所处的应用环境不为生产环境，对所述宿主机的根卷中的预设文件进行删除。其中，预设文件是预先指定的文件，如journal日志文件等。其中，可以理解地，生产环境下宿主机上的资源供外部用户进行访问，如此，宿主机根卷中存储的文件比其他环境下的文件更加的有价值。

以上步骤S305-S308实现了对宿主机本地卷进行自愈处理，根据宿主机本地卷的不同类型进行不同的自愈处理。

S309，若所述宿主机上出现异常的数据卷为容器应用的应用卷，遍历所述数据卷中占空间最大的前预设个数(如前30个)的容器应用，以得到容器应用目录，根据容器应用目录、容器应用的信息向预设用户发送邮件，以使得预设用户根据邮件的信息进行进一步的操作。其中进一步的操作，包括对容器应用的应用卷进行评估是扩容还是对用户上传的文件进行规范。预设用户包括容器应用的项目组以及容器应用的应用管理员等。

图2-图3所示的实施例实现对宿主机上的数据卷进行检测，在数据卷的存储容量达到第一预设容量时，对数据卷进行自愈。如此，实现了对异常的提前检测和预知，并对提前检测到的异常进行自愈。其中，数据卷的自愈是自动执行的，提高了数据卷自愈的效率，减少数据卷出现异常的概率，同时自愈是检测到数据卷出现异常且满足自愈的条件时，既可以开始自愈，如此，实时地响应数据卷的异常，不会影响宿主机的运行，提高了宿主机运行的稳定性；对宿主机进行自愈以减少处理异常的人力成本。

宿主机中包括应用镜像，包括两种情况，一，宿主机本地应用镜像，可以理解为，在容器启动前，需要确保宿主机本地确保有该镜像，才能基于该镜像进行启动；二，宿主机属于镜像仓库中的宿主机。那么宿主机的自愈方法，包括宿主机的镜像卷自愈方法和镜像仓库的可用性检测。

在一实施例中，所述异常类型包括宿主机上的本地应用镜像异常，步骤S101包括：若检测到所述宿主机上的用来保存本地应用镜像的镜像卷的存储容量达到第二预设容量，则判定检测到所述宿主机上的用来保存本地应用镜像的镜像卷出现异常且满足自愈的条件；执行第三清除脚本，以清除所述宿主机上残留的应用镜像信息。

可以理解地，容器应用的容器在启动前，需要宿主机本地确保有镜像，才能基于该镜像进行启动，而如果容器下线后，本地镜像不会进行删除，因为有可能其他容器在使用。这种情况下，宿主机的容器应用镜像(也可称为应用镜像)所占用的存储会不断的增大，一旦超过卷的大小，则会导致新的容器无法拉取所对应的镜像，从而使得容器无法启动。因此，若检测到宿主机上的用来保存本地应用镜像的镜像卷的存储容量达到第二预设容量，执行第三清除脚本，以清楚宿主机上的残留容器镜像信息。

如通过docker info每个一段时间来检测：Data Space Used:xxx GB；Data SpaceTotal:xxxxx GB；Data Space Available:xxxxx GB。当Data Space Used占比超过第二预设容量，如90％的时候，自动触发第三清除脚本，如第三清除脚本可以为：docker images|awk'{print$3}'|xargs dockerrmi。

对于镜像仓库的可用性探测异常。具体地，步骤S101包括：若检测到达到探测镜像仓库的时间，通过执行脚本来探测docker组件关联的镜像仓库地址，以探测该镜像仓库地址的的可用性；若镜像仓库地址不可用，判断宿主机上的镜像仓库出现异常且满足自愈的条件；向预设用户发送邮件。以通过预设用户来检测镜像仓库地址不可用的原因，如仓库服务异常、端口未开启、网络不同等。其中，如向镜像仓库地址所对应的宿主机发送ping请求，若接收到镜像仓库地址所对应的宿主机返回的数据，则意味着镜像仓库地址可用，若在一定时间内未收到镜像仓库地址所对应的宿主机返回的数据，则意味着镜像仓库地址不可用。

宿主机中有很多资源，如CPU、内存(也可简称为mem)资源等。异常类型包括宿主机中的资源异常，如此，宿主机的自愈方法，包括宿主机资源的自愈方法。

具体地，步骤S101包括：检测宿主机中的CPU使用率是否达到预设CPU使用率(如80％或其他数值)，或者检测宿主机中的mem使用率是否达到预设mem使用率(如80％或其他数值)；若宿主机中的CPU使用率达到预设CPU使用率，或者宿主机中的mem使用率达到预设mem，判定宿主机出现异常且满足自愈的条件；获取占用CPU资源或者mem资源的前预设数量的进程，获取该进程所对应的容器应用，并获取容器应用的资源配置；将占用CPU资源或者mem资源的前预设数量的进程，以及所对应的容器应用的资源配置，发送给相关人员。如通过邮件发送给相关人员以使得相关人员根据占用CPU资源或者mem资源的前预设数量的进程，以及所对应的容器应用的资源配置来进行异常排查。如果发现宿主机的资源不够，将会对相应的宿主机集群，增加新的宿主机，这样，资源消耗高的宿主机上的容器漂移到新的宿主机上，以分担宿主机上的压力。

宿主机中包括组件，如此，异常类型包括宿主机上的组件异常，宿主机的自愈方法，包括宿主机上组件的自愈方法。需要注意的是，云平台的组件根据云平台的架构、需求等确定的。如云平台的组件包括docker组件、mesos组件、marathon组件、zookeeper组件等。

在一实施例中，如图4所示，步骤S101包括以下步骤S401-S402。

S401，若检测到到达监控组件的时间，确定所要监控的组件的类型。

可以理解地，定期执行监控组件的监控脚本，其中，该监控脚本可通过云平台的配置页面进行配置下发。

S402，根据所要监控的组件的类型，来检测宿主机上的组件是否出现异常且满足自愈的条件，若检测到宿主机上的组件出现异常且满足自愈的条件，对宿主机上的组件进行自愈。若未检测到宿主机上的组件出现异常且满足自愈的条件，不进行任何处理。

宿主机的不同组件类型所对应的自愈方式不同。

在一实施例中，如图5所示，步骤S402包括以下步骤S501-S504。

S501，若所要监控的组件的类型为docker组件，执行组件信息查看脚本，以查看所述docker组件信息；若在预定时间内未收到所述docker组件返回的数据，则判定检测到宿主机上的所述docker组件出现异常且满足自愈的条件；执行docker重启脚本，以重启所述宿主机上的所述docker组件。

通过执行dockerinfo的查看脚本，以查看docker组件信息，包括镜像和容器数等，如若在5秒内还是没有返回数据，说明docker组件hang住了，即docker组件卡死了。在该种情况下，执行docker重启脚本，以重启docker组件。其中，docker重启脚本可以为：systemctl restartdocker。其中，预设时间还可以设置为其他的时间。

S502，若所要监控的组件的类型为docker组件，执行组件状态查看脚本，以查看所述docker组件当前运行状态信息；若所述docker组件当前运行状态为停止状态，则判定检测到宿主机上的所述docker组件出现异常且满足自愈的条件；执行docker启动脚本，以启动所述宿主机上的所述docker组件。

可以理解地，组件信息查看脚本和组件状态查看脚本可以同一时间执行，也可以分开执行，如间隔一段时间执行，如可以在到达监控组件的时间时执行其中一个脚本，再下一次达到监控组件的时间时执行另一个脚本。

其中，可通过systemctl status docker来查看docker组件当前运行状态是否为停止(stop)状态，即docker组件是否挂了，若docker组件当前运行状态为停止状态，执行docker启动脚本，以启动docker组件。其中，docker启动脚本可以为：systemctl startdocker。

S503，若所要监控的组件的类型为mesos组件或者为marathon组件，执行进程查看脚本，以检测组件所对应的进程是否存在；若不存在组件所对应的进程，则判定检测到宿主机上的组件出现异常且满足自愈的条件；执行相应的启动脚本，以启动所述宿主机上的相应组件。

其中，若所要监控的组件的类型为mesos组件，执行mesos进程查看脚本，以检测mesos进程是否存在；若不存在mesos进程，则判定检测到宿主机上的组件出现异常且满足自愈的条件；执行mesos组件启动脚本，以启动mesos组件。如可通过ps–ef|grep mesos-slave查看mesos进程是否存在，如果不存在，则自动执行mesos组件的启动脚本。

其中，若所要监控的组件的类型为marathon组件，执行marathon进程查看脚本，以检测marathon进程是否存在；若不存在marathon进程，则判定检测到宿主机上的组件出现异常且满足自愈的条件；执行marathon组件启动脚本，以启动marathon组件。如可通过ps–ef|grep marathon查看marathon进程是否存在，如果不存在，则执行marathon组件的启动脚本。

S504，若所要监控的组件的类型为zookeeper组件，执行端口查看脚本，以检测所述zookeeper组件的监听端口是否开启；若zookeeper组件的监听端口未开启，则判定检测到宿主机上的所述zookeeper组件出现异常且满足自愈的条件；执行端口启动脚本，以启动所述zookeeper组件的监听端口。

如可通过netstat–anp|grep zk_port来检测zookeeper组件的监听端口是否开启，其中，zk_port指的是zookeeper的监听端口，如果不存在，则自动执行启动zookeeper组件的端口启动脚本，以启动zookeeper组件的监听端口。

需要注意的是，宿主机上的组件还包括其他的组件。

图4-图5所示的实施例实现对宿主机上的组件进行自愈。通过定时检测宿主机上的组件是否出现异常，若出现异常对宿主机上的组件进行自愈。其中，数据卷的自愈是自动执行的，提高了数据卷自愈的效率，减少数据卷出现异常的概率，同时自愈是检测到数据卷出现异常且满足自愈的条件时，既可以开始自愈，如此，实时地响应数据卷的异常，不会影响宿主机的运行，提高了宿主机运行的稳定性；对宿主机进行自愈以减少处理异常的人力成本。

S102，在自愈后的预设时间内，若检测到宿主机出现相同异常，则进行报警提示。

可以理解地，进行自愈之后，若在预设时间内，仍出现相同异常，那么可认为自愈之后仍不能解决该异常，则进行报警提示。需要注意的是，若在自愈后的预设时间内，并未检测到宿主机出现相同异常，而超过预设时间后，再次检测到宿主机出现相同异常，则仍按照步骤S101中的方式进行处理。

如异常类型包括宿主机的数据卷异常，在对宿主机的数据卷进行自愈后，若在第一预设时间内仍出现数据卷的存储容量达到第一预设容量，则进行报警提示，同时向预设用户发送报警邮件，以使得预设用户来对宿主机的数据卷进行评估确定是扩容还是对用户上传的文件进行规范等。其中，第一预设时间可以为10分钟等，第一预设时间还可以为其他时间。如异常类型包括宿主机上的本地应用镜像异常，在对宿主机上的用来保存本地应用镜像的镜像卷进行自愈后，若在第二预设时间内仍出现宿主机上用来保存本地应用镜像的镜像卷的存储容量达到第二预设容量，则进行报警提示，同时向预设用户发送报警邮件。第二预设时间可以为半天等，第二预设时间还可以为其他时间。

如异常类型包括镜像仓库的可用性探测异常，在对镜像仓库地址进行可用性探测后，若在第三预设时间内仍出现镜像仓库地址不可用，则进行报警提示，同时向预设用户发送报警邮件。第三预设时间可以为1小时等，还可以为其他时间。

如异常类型包括宿主机中的资源异常，若对宿主机中的资源进行自愈后，在第四预设时间内仍出现宿主机中的资源异常，则进行报警提示，同时向预设用户发送报警邮件。第四预设时间可以为5分钟等，还可以为其他时间。

如异常类型包括宿主机上的组件异常，若对宿主机上的组件进行自愈后，在第五预设时间内仍出现宿主机中的组件异常，则进行报警提示，同时向预设用户发送报警邮件。第五预设时间可以为半小时等，还可以为其他时间。

图6是本申请实施例提供的宿主机自愈装置的示意性框图。该装置包括用于执行上述宿主机自愈方法所对应的单元。如图6所示，该宿主机自愈装置100包括自愈单元101、提示单元102。

自愈单元101，用于若检测到宿主机出现异常且满足自愈的条件，根据所出现的异常类型对宿主机进行自愈，其中，不同的异常类型所对应的自愈方式不同，不同的异常类型所对应的自愈的条件不同。

提示单元102，用于在自愈后的预设时间内，若检测到宿主机出现相同异常，则进行报警提示。

在一实施例中，所述异常类型包括宿主机的数据卷异常。如图7所示，自愈单元101包括卷自愈判定单元201、卷类型检测单元202、卷自愈单元203。

卷自愈判定单元201，用于若检测到宿主机上的数据卷的存储容量达到第一预设容量，则判定检测到宿主机上的数据卷出现异常且满足自愈的条件。

卷类型检测单元202，用于检测宿主机上的出现异常的数据卷的类型。

卷自愈单元203，用于根据出现异常的数据卷的类型对所述宿主机上的数据卷进行自愈。

在一实施例中，如图8所示，卷自愈单元203包括遍历单元301、文件判断单元302、文件删除单元303、压缩归档单元304、本地卷检测单元305、第一清除单元306、第二清除单元307、根卷处理单元308、应用卷处理单元309。

遍历单元301，用于若所述宿主机上出现异常的数据卷为容器应用的日志卷，遍历所述数据卷中的大文件。

文件判断单元302，用于判断所述大文件是否为标准输出日志文件。

文件删除单元303，用于若所述大文件为标准输出日志文件，则执行删除脚本，以删除所述大文件中的标准输出日志文件。

压缩归档单元304，用于若所述大文件为非标准输出日志文件，则将所述大文件进行压缩归档。

本地卷检测单元305，用于若所述宿主机上出现异常的数据卷为宿主机本地卷，检测所述数据卷是宿主机本地卷中的docker的数据卷、docker的元数据卷还是宿主机的根卷。

第一清除单元306，用于若所述数据卷为docker的数据卷，执行第一清除脚本，以清除所述宿主机上残留的容器应用包的信息。

第二清除单元307，用于若所述数据卷为docker的元数据卷，执行第二清除脚本，以清除所述宿主机上异常退出的容器的数据。

根卷处理单元308，用于若所述数据卷为宿主机的根卷，检测宿主机当前所处的应用环境，并根据宿主机当前所处的应用环境，对所述宿主机的根卷中的预设文件进行相应处理。

应用卷处理单元309，用于若所述宿主机上出现异常的数据卷为容器应用的应用卷，遍历所述数据卷中占空间最大的前预设个数(如前30)个的容器应用，以得到容器应用目录，根据容器应用目录、容器应用的信息向预设用户发送邮件，以使得预设用户根据邮件的信息进行进一步的操作。

在一实施例中，所述异常类型包括宿主机上的本地应用镜像异常。自愈单元101包括镜像卷自愈判定单元、镜像卷清除单元。其中，镜像卷自愈判定单元，用于若检测到所述宿主机上的用来保存本地应用镜像的镜像卷的存储容量达到第二预设容量，则判定检测到所述宿主机上的用来保存本地应用镜像的镜像卷出现异常且满足自愈的条件。镜像卷清除单元，用于执行第三清除脚本，以清除所述宿主机上残留的应用镜像信息。

在一实施例中，所述异常类型包括镜像仓库的可用性探测异常。自愈单元101包括可用性探测单元、可用性自愈判定单元、发送单元。其中，可用性探测单元，用于若检测到达到探测镜像仓库的时间，通过执行脚本来探测docker组件关联的镜像仓库地址，以探测该镜像仓库地址的的可用性。可用性自愈判定单元，用于若镜像仓库地址不可用，判定宿主机上的镜像仓库出现异常且满足自愈的条件。发送单元，用于向预设用户发送邮件。

在一实施例中，异常类型包括宿主机中的资源异常。自愈单元101包括资源检测单元、资源自愈判定单元、获取发送单元。资源检测单元，用于检测宿主机中的CPU使用率是否达到预设CPU使用率，或者检测宿主机中的mem使用率是否达到预设mem使用率。资源自愈判定单元，用于若宿主机中的CPU使用率达到预设CPU使用率，或者宿主机中的mem使用率达到预设mem，判定宿主机出现异常且满足自愈的条件。获取发送单元，获取占用CPU资源或者mem资源的前预设数量的进程，获取该进程所对应的容器应用，并获取容器应用的资源配置；将占用CPU资源或者mem资源的前预设数量的进程，以及所对应的容器应用的资源配置，发送给相关人员。

在一实施例中，异常类型包括宿主机中的组件异常。如图9所示，自愈单元101包括组件类型确定单元401、组件自愈单元402。

组件类型确定单元401，用于若检测到到达监控组件的时间，确定所要监控的组件的类型。

组件自愈单元402，用于根据所要监控的组件的类型，来检测宿主机上的组件是否出现异常且满足自愈的条件，若检测到宿主机上的组件出现异常且满足自愈的条件，对宿主机上的组件进行自愈。

在一实施例中，如图10所示，组件自愈单元402包括docker组件自愈单元501、mesos组件自愈单元502、marathon组件自愈单元503、zookeeper组件自愈单元504。

docker组件自愈单元501，用于若所要监控的组件的类型为docker组件，执行组件信息查看脚本，以查看所述docker组件信息；若在预定时间内未收到所述docker组件返回的数据，则判定检测到宿主机上的所述docker组件出现异常且满足自愈的条件；执行docker重启脚本，以重启所述宿主机上的所述docker组件。

docker组件自愈单元501，还用于若所要监控的组件的类型为docker组件，执行组件状态查看脚本，以查看所述docker组件当前运行状态信息；若所述docker组件当前运行状态为停止状态，则判定检测到宿主机上的所述docker组件出现异常且满足自愈的条件；执行docker启动脚本，以启动所述宿主机上的所述docker组件。

mesos组件自愈单元502，用于若所要监控的组件的类型为mesos组件，执行mesos进程查看脚本，以检测mesos进程是否存在；若不存在mesos进程，则判定检测到宿主机上的组件出现异常且满足自愈的条件；执行mesos组件启动脚本，以启动mesos组件。

marathon组件自愈单元503，用于若所要监控的组件的类型为marathon组件，执行marathon进程查看脚本，以检测marathon进程是否存在；若不存在marathon进程，则判定检测到宿主机上的组件出现异常且满足自愈的条件；执行marathon组件启动脚本，以启动marathon组件。

zookeeper组件自愈单元504，用于若所要监控的组件的类型为zookeeper组件，执行端口查看脚本，以检测所述zookeeper组件的监听端口是否开启；若zookeeper组件的监听端口未开启，则判定检测到宿主机上的所述zookeeper组件出现异常且满足自愈的条件；执行端口启动脚本，以启动所述zookeeper组件的监听端口。

需要说明的是，所属领域的技术人员可以清楚地了解到，上述装置和各单元的具体实现过程，可以参考前述方法实施例中的相应描述，为了描述的方便和简洁，在此不再赘述。

上述装置可以实现为一种计算机程序的形式，计算机程序可以在如图11所示的计算机设备上运行。

图11为本申请实施例提供的一种计算机设备的示意性框图。该设备为终端等设备，如PaaS平台中的宿主机等。该设备100包括通过***总线101连接的处理器102、存储器和网络接口103，其中，存储器可以包括非易失性存储介质104和内存储器105。

该非易失性存储介质104可存储操作***1041和计算机程序1042。该非易失性存储介质中所存储的计算机程序1042被处理器102执行时，可实现上述终端中所述的宿主机自愈方法。该处理器102用于提供计算和控制能力，支撑整个设备100的运行。该内存储器105为非易失性存储介质中的计算机程序的运行提供环境，该计算机程序被处理器102执行时，可使得处理器102执行上述终端中所述的宿主机自愈方法。该网络接口103用于进行网络通信。本领域技术人员可以理解，图中示出的结构，仅仅是与本申请方案相关的部分结构的框图，并不构成对本申请方案所应用于其上的设备的限定，具体的设备可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。

其中，所述处理器102用于运行存储在存储器中的计算机程序，以实现上述宿主机自愈方法的任一实施例。

应当理解，在本申请实施例中，所称处理器102可以是中央处理单元(CentralProcessing Unit，CPU)，该处理器还可以是其他通用处理器、数字信号处理器(DigitalSignal Processor，DSP)、专用集成电路(应用程序lication Specific IntegratedCircuit，ASIC)、现成可编程门阵列(Field-Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。

本领域普通技术人员可以理解的是实现上述实施例的方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成。该计算机程序可存储于一存储介质中，该存储介质可以为计算机可读存储介质。该计算机程序被该计算机***中的至少一个处理器执行，以实现上述方法的实施例的流程步骤。

因此，本申请还提供了一种存储介质。该存储介质可以为计算机可读存储介质，该计算机可读存储介质包括非易失性计算机可读存储介质。该存储介质存储有计算机程序，该计算机程序当被处理器执行时实现上述宿主机自愈方法的任一实施例。

所述存储介质可以是U盘、移动硬盘、只读存储器(Read-Only Memory，ROM)、磁碟或者光盘等各种可以存储程序代码的计算机可读存储介质。

在本申请所提供的几个实施例中，应该理解到，所揭露的装置、设备和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，上述描述的装置、设备和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到各种等效的修改或替换，这些修改或替换都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以权利要求的保护范围为准。

Claims (10)

1.一种宿主机自愈方法，其特征在于，所述方法包括：

若检测到宿主机出现异常且满足自愈的条件，根据所出现的异常类型对宿主机进行自愈，其中，不同的异常类型所对应的自愈方式不同，不同的异常类型所对应的自愈的条件不同；

在自愈后的预设时间内，若检测到宿主机出现相同异常，则进行报警提示。

2.根据权利要求1所述的方法，其特征在于，所述异常类型包括宿主机的数据卷异常，所述若检测到宿主机出现异常且满足自愈的条件，根据所出现的异常类型对宿主机进行自愈，包括：

若检测到宿主机上的数据卷的存储容量达到第一预设容量，则判定检测到宿主机上的数据卷出现异常且满足自愈的条件；

检测宿主机上的出现异常的数据卷的类型；

根据出现异常的数据卷的类型对所述宿主机上的数据卷进行自愈。

3.根据权利要求2所述的方法，其特征在于，所述数据卷的类型包括容器应用的日志卷，所述根据出现异常的数据卷的类型对所述宿主机上的数据卷进行自愈，包括：

若所述宿主机上出现异常的数据卷为容器应用的日志卷，遍历所述数据卷中的大文件；

判断所述大文件是否为标准输出日志文件；

若所述大文件为标准输出日志文件，则执行删除脚本，以删除所述大文件中的标准输出日志文件；

若所述大文件为非标准输出日志文件，则将所述大文件进行压缩归档。

4.根据权利要求2所述的方法，其特征在于，所述数据卷的类型包括宿主机本地卷，所述根据出现异常的数据卷的类型对所述宿主机上的数据卷进行自愈，包括：

若所述宿主机上出现异常的数据卷为宿主机本地卷，检测所述数据卷是宿主机本地卷中的docker的数据卷、docker的元数据卷还是宿主机的根卷；

若所述数据卷为docker的数据卷，执行第一清除脚本，以清除所述宿主机上残留的容器应用包的信息；

若所述数据卷为docker的元数据卷，执行第二清除脚本，以清除所述宿主机上异常退出的容器的数据；

若所述数据卷为宿主机的根卷，检测宿主机当前所处的应用环境，并根据宿主机当前所处的应用环境，对所述宿主机的根卷中的预设文件进行相应处理。

5.根据权利要求1所述的方法，其特征在于，所述异常类型包括宿主机上的本地应用镜像异常，所述若检测到宿主机出现异常且满足自愈的条件，根据所出现的异常类型对宿主机进行自愈，包括：

若检测到所述宿主机上的用来保存本地应用镜像的镜像卷的存储容量达到第二预设容量，则判定检测到所述宿主机上的用来保存本地应用镜像的镜像卷出现异常且满足自愈的条件；

执行第三清除脚本，以清除所述宿主机上残留的应用镜像信息。

6.根据权利要求1所述的方法，其特征在于，所述异常类型包括宿主机上的组件异常，所述若检测到宿主机出现异常且满足自愈的条件，根据所出现的异常类型对宿主机进行自愈，包括：

若检测到到达监控组件的时间，确定所要监控的组件的类型；

根据所要监控的组件的类型，来检测宿主机上的组件是否出现异常且满足自愈的条件，若检测到宿主机上的组件出现异常且满足自愈的条件，对宿主机上的组件进行自愈。

7.根据权利要求6所述的方法，其特征在于，所述根据所要监控的组件的类型，来检测宿主机上的组件是否出现异常且满足自愈的条件，若检测到宿主机上的组件出现异常且满足自愈的条件，对宿主机上的组件进行自愈，包括：

若所要监控的组件的类型为docker组件，执行组件信息查看脚本，以查看所述docker组件信息；若在预定时间内未收到所述docker组件返回的数据，则判定检测到宿主机上的所述docker组件出现异常且满足自愈的条件；执行docker重启脚本，以重启所述宿主机上的所述docker组件；

若所要监控的组件的类型为docker组件，执行组件状态查看脚本，以查看所述docker组件当前运行状态信息；若所述docker组件当前运行状态为停止状态，则判定检测到宿主机上的所述docker组件出现异常且满足自愈的条件；执行docker启动脚本，以启动所述宿主机上的所述docker组件；

若所要监控的组件的类型为mesos组件或者为marathon组件，执行进程查看脚本，以检测组件所对应的进程是否存在；若不存在组件所对应的进程，则判定检测到宿主机上的组件出现异常且满足自愈的条件；执行相应的启动脚本，以启动所述宿主机上的相应组件；

若所要监控的组件的类型为zookeeper组件，执行端口查看脚本，以检测所述zookeeper组件的监听端口是否开启；若zookeeper组件的监听端口未开启，则判定检测到宿主机上的所述zookeeper组件出现异常且满足自愈的条件；执行端口启动脚本，以启动所述zookeeper组件的监听端口。

8.一种宿主机自愈装置，其特征在于，所述宿主机自愈装置包括：

自愈单元，用于若检测到宿主机出现异常且满足自愈的条件，根据所出现的异常类型对宿主机进行自愈，其中，不同的异常类型所对应的自愈方式不同，不同的异常类型所对应的自愈的条件不同；

提示单元，用于在自愈后的预设时间内，若检测到宿主机出现相同异常，则进行报警提示。

9.一种计算机设备，其特征在于，所述计算机设备包括存储器，以及与所述存储器相连的处理器；

所述存储器用于存储计算机程序；所述处理器用于运行所述存储器中存储的计算机程序，以执行如权利要求1-7任一项所述的方法。

10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储有计算机程序，所述计算机程序被处理器执行时，实现如权利要求1-7任一项所述的方法。