CN112199247B - 一种无业务状态下Docker容器进程活性的检查方法及装置 - Google Patents
一种无业务状态下Docker容器进程活性的检查方法及装置 Download PDFInfo
- Publication number
- CN112199247B CN112199247B CN201910611719.1A CN201910611719A CN112199247B CN 112199247 B CN112199247 B CN 112199247B CN 201910611719 A CN201910611719 A CN 201910611719A CN 112199247 B CN112199247 B CN 112199247B
- Authority
- CN
- China
- Prior art keywords
- container
- docker container
- docker
- container resource
- resource consumption
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/3003—Monitoring arrangements specially adapted to the computing system or computing system component being monitored
- G06F11/301—Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system is a virtual computing platform, e.g. logically partitioned systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/3051—Monitoring arrangements for monitoring the configuration of the computing system or of the computing system component, e.g. monitoring the presence of processing resources, peripherals, I/O links, software programs
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Computing Systems (AREA)
- Physics & Mathematics (AREA)
- Quality & Reliability (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Mathematical Physics (AREA)
- Debugging And Monitoring (AREA)
Abstract
本发明公开了一种无业务状态下Docker容器进程活性的检查方法及装置,该方法包括:将前端模拟信号传送至系统后台,以供系统后台中的Docker容器启动内部进程;采集Docker容器启动内部进程后的各项容器资源消耗指标,并计算与各项容器资源消耗指标相对应的权重值;根据各项容器资源消耗指标和与各项容器资源消耗指标相对应的权重值计算Docker容器的容器资源负载值;根据容器资源负载值和应用进程存活数之间的对应关系,确定容器资源负载值所对应的Docker容器进程的假死阶段。本发明能够通过模拟实际情况中的前端业务信号实现无业务状态下的Docker容器内进程的活性检查,同时采集Docker容器的容器资源消耗指标,实现对Docker容器资源的直接检测。
Description
技术领域
本发明涉及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容器的CPU 使用率、内存使用率、磁盘读写率、网络带宽使用率、请求响应时间、以及 业务并发数。
可选地,该装置进一步包括:故障检查模块,故障检查模块适于:
检查是否存在非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)=∑wi×loadi(x)
其中,wi为某一容器资源消耗指标对应的权重值,x为某一容器资源消耗 指标的具体数值,loadi(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使用率、内存使用率、磁盘 读写率、网络带宽使用率、请求响应时间、以及业务并发数。数量约束定理 具体包括:若指标x1,x2,...,xm之间的重要性为x1>x2>...>xm,则数量约束值 rk与rk-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使用率对应的数量约束 值r1赋值为1.2。CPU使用率对应的数量约束值r1与CPU使用率对应的数量 约束值r2之间满足即r2可以赋值为1。依照上述过程,在 确定两个容器资源消耗指标的重要性后,依次为容器资源消耗指标对应的数 量约束值赋值。
第二步,根据容器资源消耗指标所对应的数量约束值确定与每个容器资 源消耗指标相对应的权重值。确定上述权重值具体包括:按照第一步中计算 所得的数量约束值和权重值计算公式确定每个容器资源消耗指标所对应的权 重值。
权重值计算公式具体如下:
wk-1=rkwk
其中,k=m,m-1,m-2,...,3,2,i为容器资源消耗指标的个数,ri为某一容器 资源消耗指标对应的数量约束值,wi为某一容器资源消耗指标对应的权重值。
步骤S230:根据各项容器资源消耗指标和与各项容器资源消耗指标相对 应的权重值计算Docker容器的容器资源负载值。
其中,容器资源负载值是指反映单个Docker容器整体资源使用情况的指 标。容器资源负载值综合考虑了Docker容器的CPU使用率、内存使用率、磁 盘读写率、网络带宽使用率、请求响应时间、以及业务并发数。容器资源负 载值具体由load(x)计算求得。
具体地,Docker容器的容器资源负载值具体计算公式如下:
load(w)=∑wi×loadi(x)
其中,wi为某一容器资源消耗指标对应的权重值,x为某一容器资源消耗 指标的具体数值,loadi(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读写率、网络带宽使用率和应用程序相关日志(调 度日志、应用程序日志、网络连接日志、堆栈日志、队列日志)。为了方便 管理不同类型的应用进程资源采集信息,故统一采集格式,如下:
系统|模块|进程类型|进程名|cpu使用率|内存使用率|IO写率|网络带宽使用 率|调度日志文件名|应用程序日志文件名|网络连接日志文件名|堆栈日志文件 名|队列日志文件名。
2.数据分析模块
应用系统进程假死主要由应用代码异常和宿主容器资源负载高引起,其 中,应用代码异常由功能验收测试可检测出来,可通过对运行日志、内存状 态等分析具体原因。宿主容器负载主要由cpu使用率、内存使用率、IO读写 率、网络带宽等要素综合影响,可通过容器资源使用情况分析应用程序是否 假死。
需要说明的是,考虑到docker容器自身资源弹性伸缩特性,当容器资源 消耗达到预警的阈值时,docker容器会自动扩容重启,此时应用程序已经死 亡,没有检查的必要。因此,本发明实施例在容器资源消耗未达到阈值前提 下应用程序假死检查方法。具体方法如下:
(1)检查是否存在非Docker容器自身导致的故障。其中,非Docker容 器自身导致的故障包括以下中的至少一个:数据库故障、防火墙故障、主机 故障、以及系统故障。若存在非Docker容器自身导致的故障,生成故障提示 消息,上述故障提示消息用于触发解决非Docker容器自身导致的故障的操作。
(2)通过采集模块获取现有容器的CPU占用率、内存的使用率、磁盘 的I/O读写率、网络带宽使用率、请求响应时间、业务并发数。
(3)根据各个指标对于系统的整体需求和重要程度,需要综合考虑多个 指标,为其分配相应的权数。
(4)单个容器资源负载值计算:
容器是一个独立的实例资源,容器资源负载是由CPU、内存、I/O、网络 带宽等指标构成,因此,容器资源负载值如下:
load(w)=∑wi×loadi(x)
其中,wi为某一容器资源消耗指标对应的权重值,x为某一容器资源消耗 指标的具体数值,loadi(x)为某一容器资源消耗指标对应的容器资源负载值, load(w)为Docker容器的容器资源负载值。
通过对预设采集时间切片下的Docker容器的容器资源负载值load(w)与 Docker容器的内部进程存活数进行机器学习,拟合得到Docker容器的容器资 源负载值load(w)与Docker容器的内部进程存活数之间的对应关系曲线。例 如,可以采用多项式拟合,拟合得到如下的对应关系:
其中,x是指Docker容器的容器资源负载值,y是指Docker容器的内部 进程存活数。需要说明的是,本发明实施例还可以拟合得到其他类型的对应 关系曲线。
图5示出了拟合所得的容器资源负载值与内部进程存活数之间的对应关 系曲线,如图5所示,对应关系曲线上标明Docker容器进程的不同假死阶段, 阶段①为个别假死阶段,阶段②为大范围假死阶段,阶段③为全部死亡阶段。 将拟合所得的容器资源负载值与内部进程存活数之间的对应关系曲线作为参 照标准,根据Docker容器某一时刻的容器资源负载值确定该时刻Docker容器 进程的假死阶段。
由此可见,本提案提出一种对Docker容器进程活性的检查方法及装置, 结合巡检、采集等技术,能够对系统交付上线前进行进程活性检查,避免了 用户实际使用过程中暴露出Docker容器内应用程序假死问题;同时,该方法 和装置运用于回归测试,对系统进程业务能力进行回归检测,避免了重大业 务故障的发生。
实施例三
图3示出了依据实施例三的一种无业务状态下Docker容器进程活性的检 查装置的结构图,上述装置包括:
模拟信号发送模块31,适于将模拟信号发送给Docker容器,以供Docker 容器启动进程;
指标权重值计算模块32,采集Docker容器启动进程后的各项容器资源消 耗指标,并计算与各项容器资源消耗指标相对应的权重值;
资源负载值计算模块33,根据各项容器资源消耗指标和与各项容器资源 消耗指标相对应的权重值计算Docker容器的容器资源负载值;
进程假死阶段确定模块34,根据容器资源负载值和应用进程存活数之间 的对应关系,确定容器资源负载值所对应的Docker容器进程的假死阶段。
可选地,指标权重值计算模块32适于:
预先确定与每个容器资源消耗指标相对应的数量约束值;
根据容器资源消耗指标所对应的数量约束值确定与每个容器资源消耗指 标相对应的权重值。
可选地,容器资源消耗指标包括以下中的至少一个:Docker容器的CPU 使用率、内存使用率、磁盘读写率、网络带宽使用率、请求响应时间、以及 业务并发数。
可选地,该装置进一步包括:故障检查模块30,故障检查模块30适于:
检查是否存在非Docker容器自身导致的故障;
若是,生成故障提示消息,故障提示消息用于触发解决非Docker容器自 身导致的故障的操作。
可选地,非Docker容器自身导致的故障包括以下中的至少一个:数据库 故障、防火墙故障、主机故障、以及系统故障。
可选地,进程假死阶段确定模块34适于:
对预设采集时间切片下的容器资源负载值和应用进程存活数进行拟合分 析,确定容器资源负载值和应用进程存活数之间的对应关系曲线;
其中,对应关系曲线上标明Docker容器进程的不同假死阶段。
可选地,该装置进一步包括:处理措施执行模块35,处理措施执行模块 35适于:
针对Docker容器进程的假死阶段执行与假死阶段相对应的处理措施。
本申请实施例提供了一种非易失性计算机存储介质,计算机存储介质存 储有至少一可执行指令,该计算机可执行指令可执行上述任意方法实施例中 的一种无业务状态下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 (10)
1.一种无业务状态下Docker容器进程活性的检查方法,包括:
将前端模拟信号传送至系统后台,以供系统后台中的Docker容器启动内部进程;
采集Docker容器启动内部进程后的各项容器资源消耗指标,并计算与所述各项容器资源消耗指标相对应的权重值;
根据所述各项容器资源消耗指标和与所述各项容器资源消耗指标相对应的权重值计算容器资源负载值;
根据容器资源负载值和应用进程存活数之间的对应关系,确定容器资源负载值所对应的Docker容器进程的假死阶段。
2.根据权利要求1所述的方法,其中,所述计算与所述各项容器资源消耗指标相对应的权重值具体包括:
预先确定与每个容器资源消耗指标相对应的数量约束值;
根据容器资源消耗指标所对应的数量约束值确定与每个容器资源消耗指标相对应的权重值。
3.根据权利要求1或2所述的方法,其中,所述容器资源消耗指标包括以下中的至少一个:Docker容器的CPU使用率、内存使用率、磁盘读写率、网络带宽使用率、请求响应时间、以及业务并发数。
4.根据权利要求1所述的方法,其中,所述方法执行之前,进一步包括:
检查是否存在非Docker容器自身导致的故障;
若是,生成故障提示消息,所述故障提示消息用于触发解决非Docker容器自身导致的故障的操作。
5.根据权利要求4所述的方法,其中,所述非Docker容器自身导致的故障包括以下中的至少一个:数据库故障、防火墙故障、主机故障、以及系统故障。
6.根据权利要求1所述的方法,其中,所述容器资源负载值和应用进程存活数之间的对应关系具体包括:
对预设采集时间切片下的容器资源负载值和应用进程存活数进行拟合分析,确定容器资源负载值和应用进程存活数之间的对应关系曲线;
其中,所述对应关系曲线上标明Docker容器进程的不同假死阶段。
7.根据权利要求1所述的方法,其中,所述确定容器资源负载值所对应的Docker容器进程的假死阶段之后,进一步包括:
针对Docker容器进程的假死阶段执行与假死阶段相对应的处理措施。
8.一种无业务状态下Docker容器进程活性的检查装置,包括:
模拟信号发送模块,适于将模拟信号发送给Docker容器,以供Docker容器启动进程;
指标权重值计算模块,采集Docker容器启动进程后的各项容器资源消耗指标,并计算与所述各项容器资源消耗指标相对应的权重值;
资源负载值计算模块,根据所述各项容器资源消耗指标和与所述各项容器资源消耗指标相对应的权重值计算容器资源负载值;
进程假死阶段确定模块,根据容器资源负载值和应用进程存活数之间的对应关系,确定容器资源负载值所对应的Docker容器进程的假死阶段。
9.一种电子设备,包括:处理器、存储器、通信接口和通信总线,所述处理器、所述存储器和所述通信接口通过所述通信总线完成相互间的通信;
所述存储器用于存放至少一可执行指令,所述可执行指令使所述处理器执行如权利要求1-7中任一项所述的一种无业务状态下Docker容器进程活性的检查方法对应的操作。
10.一种计算机存储介质,所述存储介质中存储有至少一可执行指令,所述可执行指令使处理器执行如权利要求1-7中任一项所述的一种无业务状态下Docker容器进程活性的检查方法对应的操作。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201910611719.1A CN112199247B (zh) | 2019-07-08 | 2019-07-08 | 一种无业务状态下Docker容器进程活性的检查方法及装置 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201910611719.1A CN112199247B (zh) | 2019-07-08 | 2019-07-08 | 一种无业务状态下Docker容器进程活性的检查方法及装置 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN112199247A CN112199247A (zh) | 2021-01-08 |
CN112199247B true CN112199247B (zh) | 2022-07-01 |
Family
ID=74004466
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201910611719.1A Active CN112199247B (zh) | 2019-07-08 | 2019-07-08 | 一种无业务状态下Docker容器进程活性的检查方法及装置 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN112199247B (zh) |
Families Citing this family (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN114218050A (zh) * | 2021-12-15 | 2022-03-22 | 唯品会(广州)软件有限公司 | 一种云平台故障处理方法及装置 |
Citations (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN107220100A (zh) * | 2016-03-22 | 2017-09-29 | 中国移动(深圳)有限公司 | 一种开发运维方法、装置及云计算PaaS平台 |
CN107256178A (zh) * | 2017-04-27 | 2017-10-17 | 北京数人科技有限公司 | 一种容器管理平台 |
CN107423112A (zh) * | 2017-06-28 | 2017-12-01 | 郑州云海信息技术有限公司 | 一种Docker容器状态实时同步方法 |
CN108182130A (zh) * | 2017-12-12 | 2018-06-19 | 江苏润和软件股份有限公司 | 一种基于模板的云应用容器自动化监测方法 |
CN108984269A (zh) * | 2018-07-16 | 2018-12-11 | 中山大学 | 基于随机回归森林模型的容器资源供给方法及系统 |
CN109586999A (zh) * | 2018-11-12 | 2019-04-05 | 深圳先进技术研究院 | 一种容器云平台状态监控预警系统、方法及电子设备 |
CN109684073A (zh) * | 2018-10-26 | 2019-04-26 | 平安科技(深圳)有限公司 | 电子装置、云服务资源分配方法及存储介质 |
Family Cites Families (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US9934073B2 (en) * | 2015-10-23 | 2018-04-03 | Futurewei Technologies, Inc. | Extension of resource constraints for service-defined containers |
US10379908B2 (en) * | 2017-05-30 | 2019-08-13 | Red Hat, Inc. | Merging scaled-down container clusters using vitality metrics |
-
2019
- 2019-07-08 CN CN201910611719.1A patent/CN112199247B/zh active Active
Patent Citations (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN107220100A (zh) * | 2016-03-22 | 2017-09-29 | 中国移动(深圳)有限公司 | 一种开发运维方法、装置及云计算PaaS平台 |
CN107256178A (zh) * | 2017-04-27 | 2017-10-17 | 北京数人科技有限公司 | 一种容器管理平台 |
CN107423112A (zh) * | 2017-06-28 | 2017-12-01 | 郑州云海信息技术有限公司 | 一种Docker容器状态实时同步方法 |
CN108182130A (zh) * | 2017-12-12 | 2018-06-19 | 江苏润和软件股份有限公司 | 一种基于模板的云应用容器自动化监测方法 |
CN108984269A (zh) * | 2018-07-16 | 2018-12-11 | 中山大学 | 基于随机回归森林模型的容器资源供给方法及系统 |
CN109684073A (zh) * | 2018-10-26 | 2019-04-26 | 平安科技(深圳)有限公司 | 电子装置、云服务资源分配方法及存储介质 |
CN109586999A (zh) * | 2018-11-12 | 2019-04-05 | 深圳先进技术研究院 | 一种容器云平台状态监控预警系统、方法及电子设备 |
Non-Patent Citations (1)
Title |
---|
博客园.容器 故障检测机制.《https://www.csdn.net/tags/MtTaMgzsMzY4NTUzLWJsb2cO0O0O.html》.2018, * |
Also Published As
Publication number | Publication date |
---|---|
CN112199247A (zh) | 2021-01-08 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US9672085B2 (en) | Adaptive fault diagnosis | |
CN109783262B (zh) | 故障数据处理方法、装置、服务器及计算机可读存储介质 | |
CN109586952B (zh) | 服务器扩容方法、装置 | |
CN112882796B (zh) | 异常根因分析方法和装置,及存储介质 | |
CN115118581B (zh) | 一种基于5g的物联网数据全链路监控和智能保障系统 | |
CN106789306B (zh) | 通信设备软件故障检测收集恢复方法和系统 | |
CN112241350B (zh) | 微服务评估方法、装置、计算设备及微服务检测系统 | |
CN103699475A (zh) | 对模糊测试中的测试用例进行优化的方法,装置和系统 | |
CN109981419A (zh) | 负载均衡特性的测试方法、装置、系统、设备及存储介质 | |
CN107181607A (zh) | 一种基于端到端的应用系统故障定位方法及装置 | |
CN114155692A (zh) | 一种设备故障上报方法、装置及存储介质 | |
CN112199247B (zh) | 一种无业务状态下Docker容器进程活性的检查方法及装置 | |
US9397921B2 (en) | Method and system for signal categorization for monitoring and detecting health changes in a database system | |
CN110941545A (zh) | 基于缺陷的回归测试用例的处理方法、装置及计算设备 | |
CN103731315A (zh) | 一种服务器故障检测方法 | |
CN105721233B (zh) | 网站存活检测方法、装置和系统 | |
CN116541728A (zh) | 一种基于密度聚类的故障诊断方法及装置 | |
CN107870848A (zh) | Cpu性能冲突的检测方法、装置和系统 | |
CN116662285A (zh) | 服务器日志的存储方法和装置、存储介质及电子装置 | |
CN115190039A (zh) | 一种设备健康评测方法、系统、设备以及存储介质 | |
CN113282496B (zh) | 接口自动测试方法、装置、设备及存储介质 | |
CN114629786A (zh) | 日志实时分析方法、装置、存储介质及系统 | |
CN114385498A (zh) | 性能测试方法、系统、计算机设备及可读存储介质 | |
CN112860509A (zh) | 拨测告警方法及装置 | |
CN111581062A (zh) | 服务的故障处理方法及服务器 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant |