CN112199247A

CN112199247A - 一种无业务状态下Docker容器进程活性的检查方法及装置

Info

Publication number: CN112199247A
Application number: CN201910611719.1A
Authority: CN
Inventors: 吁玲; 林文英; 竺士杰; 余建利
Original assignee: China Mobile Communications Group Co Ltd; China Mobile Group Zhejiang Co Ltd
Current assignee: China Mobile Communications Group Co Ltd; China Mobile Group Zhejiang Co Ltd
Priority date: 2019-07-08
Filing date: 2019-07-08
Publication date: 2021-01-08
Anticipated expiration: 2039-07-08
Also published as: CN112199247B

Abstract

本发明公开了一种无业务状态下Docker容器进程活性的检查方法及装置，该方法包括：将前端模拟信号传送至系统后台，以供系统后台中的Docker容器启动内部进程；采集Docker容器启动内部进程后的各项容器资源消耗指标，并计算与各项容器资源消耗指标相对应的权重值；根据各项容器资源消耗指标和与各项容器资源消耗指标相对应的权重值计算Docker容器的容器资源负载值；根据容器资源负载值和应用进程存活数之间的对应关系，确定容器资源负载值所对应的Docker容器进程的假死阶段。本发明能够通过模拟实际情况中的前端业务信号实现无业务状态下的Docker容器内进程的活性检查，同时采集Docker容器的容器资源消耗指标，实现对Docker容器资源的直接检测。

Description

一种无业务状态下Docker容器进程活性的检查方法及装置

技术领域

本发明涉及Docker容器进程测试技术领域，具体涉及一种无业务状态下 Docker容器进程活性的检查方法及装置。

背景技术

随着Docker容器的不断推广，Docker容器技术越来越多被应用于各大系统，Docker容器负责承载应用程序容量弹性伸缩，但应用程序无业务情况下应用程序启动是否具备业务处理能力，并没有一种有效的检查监控手段。目前主流的解决方案如下：

(1)系统运行时，通过监控应用程序运行端口状态，判断应用程序进程是否存在。

(2)系统运行时，通过URL(Uniform Resource Locator，统一资源定位符)检查，通过系统页面是否可以正常登陆来判断程序进程是否正常。

(3)通过业务的功能和非功能测试检测应用程序业务处理成功率，进而判断应用程序是否具备业务处理能力检查。

现有监控技术无法在无业务情况下判断Docker容器内应用程序是否假死。URL检查具有局限性，无法覆盖全量应用程序。业务功能和非功能测试同样无法完全覆盖所有Docker容器内的应用程序，需要依赖用户实际使用过程中暴露出Docker容器内应用程序是否假死，然后进行相应应对措施。因此，整体看来目前的技术手段缺少在交付用户使用前监控和判断Docker容器内应用程序是否假死的手段。

现有技术主要缺陷有：

(1)业务上线后，应用系统程序在无业务情况下，现有Docker健康检查手段无法监控多集群的动态端口变化的监控，同时无法判断所有Docker容器内应用程序是否假死，造成业务使用过程个别假死应用程序引起的业务处理异常。

(2)业务上线后，应用系统程序在无业务情况下，功能和非功能验收测试不能覆盖全部Docker容器全部实例或具体单个容器实例，造成个别Docker 容器应用程序假死引起业务中断。

发明内容

鉴于上述问题，提出了本发明以便提供一种克服上述问题或者至少部分地解决上述问题的一种无业务状态下Docker容器进程活性的检查方法及装置。

依据本发明的一个方面，提供了一种无业务状态下Docker容器进程活性的检查方法，包括：

将前端模拟信号传送至系统后台，以供系统后台中的Docker容器启动内部进程；

采集Docker容器启动内部进程后的各项容器资源消耗指标，并计算与各项容器资源消耗指标相对应的权重值；

根据各项容器资源消耗指标和与各项容器资源消耗指标相对应的权重值计算Docker容器的容器资源负载值；

根据容器资源负载值和应用进程存活数之间的对应关系，确定容器资源负载值所对应的Docker容器进程的假死阶段。

可选地，计算与各项容器资源消耗指标相对应的权重值具体包括：

预先确定与每个容器资源消耗指标相对应的数量约束值；

根据容器资源消耗指标所对应的数量约束值确定与每个容器资源消耗指标相对应的权重值。

可选地，容器资源消耗指标包括以下中的至少一个：Docker容器的CPU 使用率、内存使用率、磁盘读写率、网络带宽使用率、请求响应时间、以及业务并发数。

可选地，该方法执行之前，进一步包括：

检查是否存在非Docker容器自身导致的故障；

若是，生成故障提示消息，故障提示消息用于触发解决非Docker容器自身导致的故障的操作。

可选地，非Docker容器自身导致的故障包括以下中的至少一个：数据库故障、防火墙故障、主机故障、以及系统故障。

可选地，容器资源负载值和应用进程存活数之间的对应关系具体包括：

对预设采集时间切片下的容器资源负载值和应用进程存活数进行拟合分析，确定容器资源负载值和应用进程存活数之间的对应关系曲线；

其中，对应关系曲线上标明Docker容器进程的不同假死阶段。

可选地，确定容器资源负载值所对应的Docker容器进程的假死阶段之后，进一步包括：

针对Docker容器进程的假死阶段执行与假死阶段相对应的处理措施。

依据本发明的一个方面，提供了一种无业务状态下Docker容器进程活性的检查装置，包括：

模拟信号发送模块，适于将模拟信号发送给Docker容器，以供Docker 容器启动进程；

指标权重值计算模块，采集Docker容器启动进程后的各项容器资源消耗指标，并计算与各项容器资源消耗指标相对应的权重值；

资源负载值计算模块，根据各项容器资源消耗指标和与各项容器资源消耗指标相对应的权重值计算Docker容器的容器资源负载值；

进程假死阶段确定模块，根据容器资源负载值和应用进程存活数之间的对应关系，确定容器资源负载值所对应的Docker容器进程的假死阶段。

可选地，指标权重值计算模块适于：

预先确定与每个容器资源消耗指标相对应的数量约束值；

可选地，该装置进一步包括：故障检查模块，故障检查模块适于：

检查是否存在非Docker容器自身导致的故障；

可选地，进程假死阶段确定模块适于：

其中，对应关系曲线上标明Docker容器进程的不同假死阶段。

可选地，该装置进一步包括：处理措施执行模块，处理措施执行模块适于：

根据本发明的再一方面，提供了一种电子设备，包括：处理器、存储器、通信接口和通信总线，处理器、存储器和通信接口通过通信总线完成相互间的通信；

存储器用于存放至少一可执行指令，可执行指令使处理器执行上述一种无业务状态下Docker容器进程活性的检查方法对应的操作。

根据本发明的再一方面，提供了一种计算机存储介质，存储介质中存储有至少一可执行指令，可执行指令使处理器执行如上述无业务状态下Docker 容器进程活性的检查方法对应的操作。

综上所述，本发明公开了一种无业务状态下Docker容器进程活性的检查方法及装置，首先，将前端模拟信号传送至系统后台，以供系统后台中的 Docker容器启动内部进程。然后，采集Docker容器启动内部进程后的各项容器资源消耗指标，并计算与各项容器资源消耗指标相对应的权重值。接着，根据各项容器资源消耗指标和与各项容器资源消耗指标相对应的权重值计算 Docker容器的容器资源负载值。最后，根据容器资源负载值和应用进程存活数之间的对应关系，确定容器资源负载值所对应的Docker容器进程的假死阶段。由此可见，本发明能够通过模拟实际情况中的前端业务信号实现无业务状态下的Docker容器内进程的活性检查，同时采集Docker容器的容器资源消耗指标，实现对Docker容器资源的直接检测。

上述说明仅是本发明技术方案的概述，为了能够更清楚了解本发明的技术手段，而可依照说明书的内容予以实施，并且为了让本发明的上述和其它目的、特征和优点能够更明显易懂，以下特举本发明的具体实施方式。

附图说明

通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，而并不认为是对本发明的限制。而且在整个附图中，用相同的参考符号表示相同的部件。在附图中：

图1示出了依据实施例一的一种无业务状态下Docker容器进程活性的检查方法的流程图；

图2示出了依据实施例二的一种无业务状态下Docker容器进程活性的检查方法的流程图；

图3示出了依据实施例三的一种无业务状态下Docker容器进程活性的检查装置的结构图；

图4示出了根据本发明实施例的一种电子设备的结构示意图；

图5示出了拟合所得的容器资源负载值与内部进程存活数之间的对应关系曲线；

图6示出了本发明实施例架构功能示意图。

具体实施方式

下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例，然而应当理解，可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本公开，并且能够将本公开的范围完整的传达给本领域的技术人员。

实施例一

图1示出了依据实施例一的一种无业务状态下Docker容器进程活性的检查方法的流程图。如图1所示，该方法包括以下步骤：

步骤S110：将前端模拟信号传送至系统后台，以供系统后台中的Docker 容器启动内部进程。

其中，前端模拟信号是指模拟实际情况中的前端业务信号，前端模拟信号中包含Agent权限码，Agent权限码用于判断是否允许Docker容器启动内部进程。需要说明的是，无论是实际情况中的前端业务信号还是前端模拟信号都需要经过系统的中台，最后到达系统的后台。

具体地，首先，模拟实际情况中的前端业务信号。然后，将前端模拟信号传送至系统后台。其中，系统后台中包含多个Docker容器，Docker容器获取到前端模拟信号中的Agent权限码，并与自身预先设置的Agent权限码匹配，若Agent权限码匹配成功，说明允许Docker容器启动内部进程。

步骤S120：采集Docker容器启动内部进程后的各项容器资源消耗指标，并计算与各项容器资源消耗指标相对应的权重值。

其中，容器资源消耗指标是指反映单个Docker容器某一类资源使用情况的指标，容器资源消耗指标具体包括以下中的至少一个：Docker容器的CPU 使用率、内存使用率、磁盘读写率、网络带宽使用率、请求响应时间、以及业务并发数。例如，CPU使用率反映了Docker容器的CPU使用情况，内存使用率反映了Docker容器的内存使用情况。需要说明的是，本实施例对容器资源消耗指标的具体内涵不作限制，本领域技术人员可以采用其他方法说明容器资源消耗指标的具体内涵。

具体地，首先，在Docker容器启动内部进程后，采集某一时刻下的Docker 容器的各项容器资源消耗指标。然后，计算与各项容器资源消耗指标相对应的权重值。其中，确定上述权重值具体包括：根据每个容器资源消耗指标的重要性确定容器资源消耗指标对应的数量约束值，进而根据上述数量约束值确定权重值。需要说明的是，本实施例对权重值的具体计算方法不作限制，本领域技术人员可以采用其他方法计算权重值。

步骤S130：根据各项容器资源消耗指标和与各项容器资源消耗指标相对应的权重值计算Docker容器的容器资源负载值。

其中，容器资源负载值是指反映单个Docker容器整体资源使用情况的指标。容器资源负载值综合考虑了Docker容器的CPU使用率、内存使用率、磁盘读写率、网络带宽使用率、请求响应时间、以及业务并发数。容器资源负载值具体由load(x)计算求得。

具体地，Docker容器的容器资源负载值具体计算公式如下：

load(w)＝∑w_i×load_i(x)

其中，w_i为某一容器资源消耗指标对应的权重值，x为某一容器资源消耗指标的具体数值，load_i(x)为某一容器资源消耗指标对应的容器资源负载值， load(w)为Docker容器的容器资源负载值。需要说明的是，本实施例对Docker 容器的容器资源负载值的具体计算方法不作限制，本领域技术人员可以采用其他方法计算Docker容器的容器资源负载值。

步骤S140：根据容器资源负载值和应用进程存活数之间的对应关系，确定容器资源负载值所对应的Docker容器进程的假死阶段。

其中，Docker容器进程的假死阶段具体包括三个阶段：个别假死阶段、大范围假死阶段、以及全部死亡阶段。容器资源负载值和应用进程存活数之间的对应关系具体包括：对预设采集时间切片下的容器资源负载值和应用进程存活数进行拟合分析，确定容器资源负载值和应用进程存活数之间的对应关系曲线。

将预设采集时间切片下容器资源负载值和应用进程存活数之间的对应关系曲线作为参照标准，根据Docker容器某一时刻的容器资源负载值确定该时刻Docker容器进程的假死阶段。

综上所述，该方式通过模拟实际情况中的前端业务信号实现无业务状态下的Docker容器内进程的活性检查，同时采集Docker容器的容器资源消耗指标，实现对Docker容器资源的直接检测。

实施例二

图2示出了依据实施例二的一种无业务状态下Docker容器进程活性的检查方法的流程图。如图2所示，该方法包括以下步骤：

步骤S200：检查是否存在非Docker容器自身导致的故障。

其中，非Docker容器自身导致的故障包括以下中的至少一个：数据库故障、防火墙故障、主机故障、以及系统故障。需要说明的是，本实施例对非Docker容器自身导致的故障的具体内涵不作限制，本领域技术人员可以采用其他方法说明非Docker容器自身导致的故障的具体内涵。

具体地，检查是否存在非Docker容器自身导致的故障，比如，数据库故障、防火墙故障、主机故障、和/或系统故障。若存在非Docker容器自身导致的故障，生成故障提示消息，上述故障提示消息用于触发解决非Docker容器自身导致的故障的操作。其中，上述解决非Docker容器自身导致的故障的操作可以是通过悬浮窗或弹窗的方式提示人为介入检查和解决上述非Docker容器自身导致的故障。需要说明的是，本实施例对解决非Docker容器自身导致的故障的操作不作具体限制，本领域技术人员可以采用其他解决非Docker容器自身导致的故障的操作。

步骤S210：将前端模拟信号传送至系统后台，以供系统后台中的Docker 容器启动内部进程。

其中，前端模拟信号是指模拟实际情况中的前端业务信号，前端模拟信号中包含Agent权限码。

具体地，首先，模拟实际情况中的前端业务信号。然后，将前端模拟信号传送至系统后台。其中，系统后台中包含多个Docker容器。各个Docker 容器每隔预设时间扫描传送至系统后台的前端模拟信号，获取前端模拟信号中的Agent权限码，将获取的Agent权限码与Docker容器中预先设置的Agent 权限码匹配。若前端模拟信号中的Agent权限码与Docker容器中预先设置的 Agent权限码匹配成功，说明允许Docker容器启动内部进程。需要说明的是， Agent权限码匹配成功的Docker容器可以有多个，多个Docker容器启动内部进程。

步骤S220：采集Docker容器启动内部进程后的各项容器资源消耗指标，并计算与各项容器资源消耗指标相对应的权重值。

其中，容器资源消耗指标是指反映单个Docker容器某一类资源使用情况的指标，容器资源消耗指标具体包括以下中的至少一个：Docker容器的CPU 使用率、内存使用率、磁盘读写率、网络带宽使用率、请求响应时间、以及业务并发数。

具体地，首先，在Docker容器启动内部进程后，采集某一时刻下的Docker 容器的各项容器资源消耗指标，比如，CPU使用率、内存使用率、磁盘读写率、网络带宽使用率、请求响应时间、以及业务并发数。

然后，计算与各项容器资源消耗指标相对应的权重值。具体实施时，第一步，预先确定与每个容器资源消耗指标相对应的数量约束值。确定上述数量约束值具体包括：根据容器资源消耗指标的重要性和数量约束定理确定每个容器资源消耗指标所对应的数量约束值。例如，将各个容器资源消耗指标按照其对应的重要性由高到低排序，分别为CPU使用率、内存使用率、磁盘读写率、网络带宽使用率、请求响应时间、以及业务并发数。数量约束定理具体包括：若指标x₁,x₂,...,x_m之间的重要性为x₁＞x₂＞...＞x_m，则数量约束值 r_k与r_k-1满足

其中，k＝m,m-1,m-2,...,3,2。数量约束值的具体赋值参考下表1。

表1数量约束值的具体赋值参考表

r<sub>k</sub>	说明
		1	指标x<sub>k-1</sub>与指标x<sub>k</sub>具有同样重要性
1.2	指标x<sub>k-1</sub>比指标x<sub>k</sub>稍微重要
		1.4	指标x<sub>k-1</sub>比指标x<sub>k</sub>明显重要
1.6	指标x<sub>k-1</sub>比指标x<sub>k</sub>强烈重要

例如，CPU使用率比内存使用率稍微重要，CPU使用率对应的数量约束值r₁赋值为1.2。CPU使用率对应的数量约束值r₁与CPU使用率对应的数量约束值r₂之间满足

即

r₂可以赋值为1。依照上述过程，在确定两个容器资源消耗指标的重要性后，依次为容器资源消耗指标对应的数量约束值赋值。

第二步，根据容器资源消耗指标所对应的数量约束值确定与每个容器资源消耗指标相对应的权重值。确定上述权重值具体包括：按照第一步中计算所得的数量约束值和权重值计算公式确定每个容器资源消耗指标所对应的权重值。

权重值计算公式具体如下：

w_k-1＝r_kw_k

其中，k＝m,m-1,m-2,...,3,2，i为容器资源消耗指标的个数，r_i为某一容器资源消耗指标对应的数量约束值，w_i为某一容器资源消耗指标对应的权重值。

步骤S230：根据各项容器资源消耗指标和与各项容器资源消耗指标相对应的权重值计算Docker容器的容器资源负载值。

具体地，Docker容器的容器资源负载值具体计算公式如下：

load(w)＝∑w_i×load_i(x)

其中，w_i为某一容器资源消耗指标对应的权重值，x为某一容器资源消耗指标的具体数值，load_i(x)为某一容器资源消耗指标对应的容器资源负载值， load(w)为Docker容器的容器资源负载值。

步骤S240：根据容器资源负载值和应用进程存活数之间的对应关系，确定容器资源负载值所对应的Docker容器进程的假死阶段。

其中，Docker容器进程的假死阶段具体包括三个阶段：个别假死阶段、大范围假死阶段、以及全部死亡阶段。

容器资源负载值和应用进程存活数之间的对应关系具体包括：对预设采集时间切片下的容器资源负载值和应用进程存活数进行拟合分析，确定容器资源负载值和应用进程存活数之间的对应关系曲线。具体实施时，预设采集时间切片下，Docker容器内部的进程经历个别假死阶段、大范围假死阶段、以及全部死亡阶段的三个假死阶段。在对Docker容器目前内部进程活性检查前，通过对预设采集时间切片下的Docker容器的容器资源负载值load(w)与 Docker容器的内部进程存活数进行机器学习，拟合得到Docker容器的容器资源负载值load(w)与Docker容器的内部进程存活数之间的对应关系曲线。例如，可以采用多项式拟合，拟合得到如下的对应关系：

其中，x是指Docker容器的容器资源负载值，y是指Docker容器的内部进程存活数。

图5示出了拟合所得的容器资源负载值与内部进程存活数之间的对应关系曲线，如图5所示，对应关系曲线上标明Docker容器进程的不同假死阶段，阶段①为个别假死阶段，阶段②为大范围假死阶段，阶段③为全部死亡阶段。将拟合所得的容器资源负载值与内部进程存活数之间的对应关系曲线作为参照标准，根据Docker容器某一时刻的容器资源负载值确定该时刻Docker容器进程的假死阶段。

进一步地，在确定Docker容器进程的假死阶段后，针对Docker容器进程的假死阶段执行与假死阶段相对应的处理措施。具体地，当Docker容器进程处于个别假死阶段时，触发风险预警，并提示人工介入检查假死进程，并重新启动进程；当Docker容器进程处于大范围假死阶段时，触发业务影响警告，并实施Docker容器资源扩容；当Docker容器进程处于全部死亡阶段时，触发业务中断警告，并提示切换备份Docker容器。

综上所述，该方式一方面模拟实际情况中的前端业务信号，将前端模拟信号传送至系统后台，以供系统后台中的Docker容器启动内部进程，实现了在无业务状态下对Docker容器内的进程检查并及时发出预警，对系统交付上线前进行进程活性检查，大大提高了系统的稳健性，避免了用户实际使用过程中暴露出Docker容器内进程假死问题。另一方面，通过采集Docker容器启动内部进程后的各项容器资源消耗指标，直接对Docker容器本身的资源消耗情况进行监测，解决了传统方法通过监测宿主机的资源消耗情况造成对Docker容器性能评估不准确的问题。同时，进程活性检查方法考虑了CPU、内存、并发量等多项参考因素，具有很强的实用性和扩展性。

下面以一个具体实施例说明本发明的方法。

本实施例主要包括三大模块：信号管理模块、分析模块、运维模块。图6 示出了本发明实施例架构功能示意图，信号管理模块主要负责模拟信号管理和运行指标采集，数据分析模块主要是对指标数据进行整合和分析，运维模块主要对巡检、采集、分析策略进行查询和变更维护。

下面对本发明实施例的装置主要功能和具体实施方法进行详细说明。

1.信号管理模块：信号管理模块由信号收集子模块、信号发送子模块和指标采集子模块组成。

(1)部署信息采集子模块

通过环境巡检技术，采集系统应用程序部署信息(容器appid、数量、进程名称、端口、输入信号类型)，标记输入信号类型和用途说明，并根据输入信号三种类型(参数、文件、值)进行模糊化处理，保证输入信号不会造成真实业务受影响。

(2)信号发送子模块

信号发送子模块将前端模拟信号传送至系统后台，以供系统后台中的 Docker容器启动内部进程。该模块采用被动发送模式，容器内agent发送长连接定时扫描信号发送子模块前端模拟信号中的agent代理配置码，校验成功后，允许访问并获取执行权限和待执行内容，同时负责管理agent配置码和执行权限管理。

(3)资源指标采集子模块

负责进程活性检测过程中的监控指标采集和管理。采集信息包含：CPU 使用率、内存使用率、IO读写率、网络带宽使用率和应用程序相关日志(调度日志、应用程序日志、网络连接日志、堆栈日志、队列日志)。为了方便管理不同类型的应用进程资源采集信息，故统一采集格式，如下：

2.数据分析模块

应用系统进程假死主要由应用代码异常和宿主容器资源负载高引起，其中，应用代码异常由功能验收测试可检测出来，可通过对运行日志、内存状态等分析具体原因。宿主容器负载主要由cpu使用率、内存使用率、IO读写率、网络带宽等要素综合影响，可通过容器资源使用情况分析应用程序是否假死。

需要说明的是，考虑到docker容器自身资源弹性伸缩特性，当容器资源消耗达到预警的阈值时，docker容器会自动扩容重启，此时应用程序已经死亡，没有检查的必要。因此，本发明实施例在容器资源消耗未达到阈值前提下应用程序假死检查方法。具体方法如下：

(1)检查是否存在非Docker容器自身导致的故障。其中，非Docker容器自身导致的故障包括以下中的至少一个：数据库故障、防火墙故障、主机故障、以及系统故障。若存在非Docker容器自身导致的故障，生成故障提示消息，上述故障提示消息用于触发解决非Docker容器自身导致的故障的操作。

(2)通过采集模块获取现有容器的CPU占用率、内存的使用率、磁盘的I/O读写率、网络带宽使用率、请求响应时间、业务并发数。

(3)根据各个指标对于系统的整体需求和重要程度，需要综合考虑多个指标，为其分配相应的权数。

(4)单个容器资源负载值计算：

容器是一个独立的实例资源，容器资源负载是由CPU、内存、I/O、网络带宽等指标构成，因此，容器资源负载值如下：

load(w)＝∑w_i×load_i(x)

通过对预设采集时间切片下的Docker容器的容器资源负载值load(w)与 Docker容器的内部进程存活数进行机器学习，拟合得到Docker容器的容器资源负载值load(w)与Docker容器的内部进程存活数之间的对应关系曲线。例如，可以采用多项式拟合，拟合得到如下的对应关系：

其中，x是指Docker容器的容器资源负载值，y是指Docker容器的内部进程存活数。需要说明的是，本发明实施例还可以拟合得到其他类型的对应关系曲线。

由此可见，本提案提出一种对Docker容器进程活性的检查方法及装置，结合巡检、采集等技术，能够对系统交付上线前进行进程活性检查，避免了用户实际使用过程中暴露出Docker容器内应用程序假死问题；同时，该方法和装置运用于回归测试，对系统进程业务能力进行回归检测，避免了重大业务故障的发生。

实施例三

图3示出了依据实施例三的一种无业务状态下Docker容器进程活性的检查装置的结构图，上述装置包括：

模拟信号发送模块31，适于将模拟信号发送给Docker容器，以供Docker 容器启动进程；

指标权重值计算模块32，采集Docker容器启动进程后的各项容器资源消耗指标，并计算与各项容器资源消耗指标相对应的权重值；

资源负载值计算模块33，根据各项容器资源消耗指标和与各项容器资源消耗指标相对应的权重值计算Docker容器的容器资源负载值；

进程假死阶段确定模块34，根据容器资源负载值和应用进程存活数之间的对应关系，确定容器资源负载值所对应的Docker容器进程的假死阶段。

可选地，指标权重值计算模块32适于：

预先确定与每个容器资源消耗指标相对应的数量约束值；

可选地，该装置进一步包括：故障检查模块30，故障检查模块30适于：

检查是否存在非Docker容器自身导致的故障；

可选地，进程假死阶段确定模块34适于：

其中，对应关系曲线上标明Docker容器进程的不同假死阶段。

可选地，该装置进一步包括：处理措施执行模块35，处理措施执行模块 35适于：

本申请实施例提供了一种非易失性计算机存储介质，计算机存储介质存储有至少一可执行指令，该计算机可执行指令可执行上述任意方法实施例中的一种无业务状态下Docker容器进程活性的检查方法。

图4示出了根据本发明实施例的一种电子设备的结构示意图，本发明具体实施例并不对电子设备的具体实现做限定。

如图4所示，该电子设备可以包括：处理器(processor)402、通信接口(Communications Interface)404、存储器(memory)406、以及通信总线408。

其中：

处理器402、通信接口404、以及存储器406通过通信总线408完成相互间的通信。

通信接口404，用于与其它设备比如客户端或其它服务器等的网元通信。

处理器402，用于执行程序410，具体可以执行上述基于多级网络节点的故障定位方法实施例中的相关步骤。

具体地，程序410可以包括程序代码，该程序代码包括计算机操作指令。

处理器402可能是中央处理器CPU，或者是特定集成电路ASIC (ApplicationSpecific Integrated Circuit)，或者是被配置成实施本发明实施例的一个或多个集成电路。电子设备包括的一个或多个处理器，可以是同一类型的处理器，如一个或多个CPU；也可以是不同类型的处理器，如一个或多个CPU以及一个或多个ASIC。

存储器406，用于存放程序410。存储器406可能包含高速RAM存储器，也可能还包括非易失性存储器(non-volatile memory)，例如至少一个磁盘存储器。

程序410具体可以用于使得处理器402执行上述方法实施例中的各项操作。

在此提供的算法和显示不与任何特定计算机、虚拟系统或者其它设备固有相关。各种通用系统也可以与基于在此的示教一起使用。根据上面的描述，构造这类系统所要求的结构是显而易见的。此外，本发明也不针对任何特定编程语言。应当明白，可以利用各种编程语言实现在此描述的本发明的内容，并且上面对特定语言所做的描述是为了披露本发明的最佳实施方式。

在此处所提供的说明书中，说明了大量具体细节。然而，能够理解，本发明的实施例可以在没有这些具体细节的情况下实践。在一些实例中，并未详细示出公知的方法、结构和技术，以便不模糊对本说明书的理解。

类似地，应当理解，为了精简本公开并帮助理解各个发明方面中的一个或多个，在上面对本发明的示例性实施例的描述中，本发明的各个特征有时被一起分组到单个实施例、图、或者对其的描述中。然而，并不应将该公开的方法解释成反映如下意图：即所要求保护的本发明要求比在每个权利要求中所明确记载的特征更多的特征。更确切地说，如下面的权利要求书所反映的那样，发明方面在于少于前面公开的单个实施例的所有特征。因此，遵循具体实施方式的权利要求书由此明确地并入该具体实施方式，其中每个权利要求本身都作为本发明的单独实施例。

本领域那些技术人员可以理解，可以对实施例中的设备中的模块进行自适应性地改变并且把它们设置在与该实施例不同的一个或多个设备中。可以把实施例中的模块或单元或组件组合成一个模块或单元或组件，以及此外可以把它们分成多个子模块或子单元或子组件。除了这样的特征和/或过程或者单元中的至少一些是相互排斥之外，可以采用任何组合对本说明书(包括伴随的权利要求、摘要和附图)中公开的所有特征以及如此公开的任何方法或者设备的所有过程或单元进行组合。除非另外明确陈述，本说明书(包括伴随的权利要求、摘要和附图)中公开的每个特征可以由提供相同、等同或相似目的的替代特征来代替。

此外，本领域的技术人员能够理解，尽管在此的一些实施例包括其它实施例中所包括的某些特征而不是其它特征，但是不同实施例的特征的组合意味着处于本发明的范围之内并且形成不同的实施例。例如，在下面的权利要求书中，所要求保护的实施例的任意之一都可以以任意的组合方式来使用。

本发明的各个部件实施例可以以硬件实现，或者以在一个或者多个处理器上运行的软件模块实现，或者以它们的组合实现。本领域的技术人员应当理解，可以在实践中使用微处理器或者数字信号处理器(DSP)来实现根据本发明实施例的系统中的一些或者全部部件的一些或者全部功能。本发明还可以实现为用于执行这里所描述的方法的一部分或者全部的设备或者系统程序 (例如，计算机程序和计算机程序产品)。这样的实现本发明的程序可以存储在计算机可读介质上，或者可以具有一个或者多个信号的形式。这样的信号可以从因特网网站上下载得到，或者在载体信号上提供，或者以任何其他形式提供。

应该注意的是上述实施例对本发明进行说明而不是对本发明进行限制，并且本领域技术人员在不脱离所附权利要求的范围的情况下可设计出替换实施例。在权利要求中，不应将位于括号之间的任何参考符号构造成对权利要求的限制。单词“包含”不排除存在未列在权利要求中的元件或步骤。位于元件之前的单词“一”或“一个”不排除存在多个这样的元件。本发明可以借助于包括有若干不同元件的硬件以及借助于适当编程的计算机来实现。在列举了若干系统的单元权利要求中，这些系统中的若干个可以是通过同一个硬件项来具体体现。单词第一、第二、以及第三等的使用不表示任何顺序。可将这些单词解释为名称。

Claims

1.一种无业务状态下Docker容器进程活性的检查方法，包括：

采集Docker容器启动内部进程后的各项容器资源消耗指标，并计算与所述各项容器资源消耗指标相对应的权重值；

根据所述各项容器资源消耗指标和与所述各项容器资源消耗指标相对应的权重值计算容器资源负载值；

2.根据权利要求1所述的方法，其中，所述计算与所述各项容器资源消耗指标相对应的权重值具体包括：

预先确定与每个容器资源消耗指标相对应的数量约束值；

3.根据权利要求1或2所述的方法，其中，所述容器资源消耗指标包括以下中的至少一个：Docker容器的CPU使用率、内存使用率、磁盘读写率、网络带宽使用率、请求响应时间、以及业务并发数。

4.根据权利要求1所述的方法，其中，所述方法执行之前，进一步包括：

检查是否存在非Docker容器自身导致的故障；

若是，生成故障提示消息，所述故障提示消息用于触发解决非Docker容器自身导致的故障的操作。

5.根据权利要求4所述的方法，其中，所述非Docker容器自身导致的故障包括以下中的至少一个：数据库故障、防火墙故障、主机故障、以及系统故障。

6.根据权利要求1所述的方法，其中，所述容器资源负载值和应用进程存活数之间的对应关系具体包括：

其中，所述对应关系曲线上标明Docker容器进程的不同假死阶段。

7.根据权利要求1所述的方法，其中，所述确定容器资源负载值所对应的Docker容器进程的假死阶段之后，进一步包括：

8.一种无业务状态下Docker容器进程活性的检查装置，包括：

模拟信号发送模块，适于将模拟信号发送给Docker容器，以供Docker容器启动进程；

指标权重值计算模块，采集Docker容器启动进程后的各项容器资源消耗指标，并计算与所述各项容器资源消耗指标相对应的权重值；

资源负载值计算模块，根据所述各项容器资源消耗指标和与所述各项容器资源消耗指标相对应的权重值计算容器资源负载值；

9.一种电子设备，包括：处理器、存储器、通信接口和通信总线，所述处理器、所述存储器和所述通信接口通过所述通信总线完成相互间的通信；

所述存储器用于存放至少一可执行指令，所述可执行指令使所述处理器执行如权利要求1-7中任一项所述的一种无业务状态下Docker容器进程活性的检查方法对应的操作。

10.一种计算机存储介质，所述存储介质中存储有至少一可执行指令，所述可执行指令使处理器执行如权利要求1-7中任一项所述的一种无业务状态下Docker容器进程活性的检查方法对应的操作。