应用容器引擎的系统资源占用量监控方法和装置与流程

本发明涉及系统资源占用监控领域，具体地，涉及一种应用容器引擎的系统资源占用量监控方法和装置。

背景技术：

应用容器引擎使得开发者可以将他们的应用以及依赖包打包到其中，然后发布到机器上。例如，Docker是一个开源的应用容器引擎，开发者可以将他们的应用以及依赖包打包到Docker中，然后将其发布至任何流行的Linux设备上，其也可以实现虚拟化。Docker使得开发人员易于快速构建可随时运行的容器化应用程序，大大简化了应用程序的任务的管理和部署。

例如，为手机、电视、车载等终端提供的各种后端rest-api服务，其生产环境均可以采用Docker虚拟机来部署，但是目前rest-api服务具体的系统消耗无法进行实时反馈。

举例来说，如果将web-app直接部署在一个linux服务器上，那么其系统资源消耗(例如CPU，MEM)的采集是很容易的，这是因为linux系统支持实时采集。但是本申请发明人在实现本发明的过程中发现，由于Docker虚拟机是基于linux服务器进行的二次虚拟，其本身并不支持系统资源资源占用量的采集，因而无法关注Docker虚拟机在整个服务器上的系统消耗。

也就是说，应用容器引擎(例如Docker)虽然可以有效地利用服务器资源(多核、CPU、MEM)，但是其对服务器的系统资源占用量无法获得，进而无法对产品的生产环境的扩容、缩容问题进行合理把控。

技术实现要素：

本发明实施例的目的是提供一种应用容器引擎的系统资源占用量监控方法和装置，该应用容器引擎的系统资源占用量监控方法和装置能够随应用容器的系统资源占用量进行实时监控，进而能够对产品的生产环境的扩容、缩容问题进行合理把控。

为了实现上述目的，本发明实施例提供一种应用容器引擎的系统资源占用量监控方法，所述系统资源占用量监控方法包括：多次采集所述应用容器引擎的CPU占用时间和/或内存使用量；根据所述应用容器引擎的CPU占用时间获得所述应用容器引擎的CPU占用率；以及使用所述应用容器引擎的CPU占用率和/或内存使用量来表征所述应用容器引擎的系统资源占用量。

可选地，所述CPU占用时间包括：内核态占用时间和用户态占用时间。

可选地，根据以下等式计算所述应用容器引擎的CPU占用率CPU_oc：CPU_oc＝(cpu_sys+cpu_user-cpu_pre)/(time_now-time_pre)，其中，cpu_sys为所述内核态占用时间，cpu_user为所述用户态占用时间，cpu_pre为上一次采集的所述内核态占用时间与上一次采集的所述用户态占用时间的和，time_now为从第一次采集开始到本次采集所经历的时间，time_pre为从所述第一次采集开始到上一次采集所经历的时间。

可选地，所述多次采集为周期性的。

可选地，所述系统资源占用量监控方法还包括：在所述应用容器引擎的CPU占用率超过CPU占用率阈值和/或所述内存使用量超过内存使用量阈值的情况下，确定所述应用容器引擎的系统资源占用量超限。

可选地，所述系统资源占用量监控方法还包括：将所述CPU占用率和/或所述内存使用量进行前端展示渲染。

可选地，所述应用容器引擎为Docker。

相应地，本发明实施例还提供一种应用容器引擎的系统资源占用量监控装置，所述系统资源占用量监控装置包括：数据采集模块，用于多次采集所述应用容器引擎的CPU占用时间和/或内存使用量；以及数据处理模块，用于：根据所述应用容器引擎的CPU占用时间获得应用容器引擎的CPU占用率；及使用所述应用容器引擎的CPU占用率和/或内存使用量来表征所述应用容器引擎的系统资源占用量。

可选地，所述CPU占用时间包括：内核态占用时间和用户态占用时间。

可选地，所述数据处理模块根据以下等式计算所述应用容器引擎的CPU占用率CPU_oc：CPU_oc＝(cpu_sys+cpu_user-cpu_pre)/(time_now-time_pre)，其中，cpu_sys为所述内核态占用时间，cpu_user为所述用户态占用时间，cpu_pre为上一次采集的所述内核态占用时间与上一次采集的所述用户态占用时间的和，time_now为从第一次采集开始到本次采集所经历的时间，time_pre为从所述第一次采集开始到上一次采集所经历的时间。

可选地，所述多次采集为周期性的。

可选地，所述数据处理模块还用于：在所述应用容器引擎的CPU占用率超过CPU占用率阈值和/或所述内存使用量超过内存使用量阈值的情况下，确定所述应用容器引擎的系统资源占用量超限。

可选地，所述系统资源占用量监控装置还包括前端渲染模块：用于将所述CPU占用率和/或所述内存使用量进行前端展示渲染。

可选地，所述应用容器引擎为Docker。

通过上述技术方案，根据多次采集所述应用容器引擎的CPU占用时间获得所述应用容器引擎的CPU占用率，并使用CPU占用率和/或多次采集的内存使用量来表征所述应用容器引擎的系统资源占用量。如此能够实现对应用容器引擎的资源占用量的实时监控，进而能够对产品的生产环境的扩容、缩容问题进行合理把控。

本发明实施例的其它特征和优点将在随后的具体实施方式部分予以详细说明。

附图说明

附图是用来提供对本发明的进一步理解，并且构成说明书的一部分，与下面的具体实施方式一起用于解释本发明，但并不构成对本发明的限制。在附图中：

图1是根据本发明实施例提供一种应用容器引擎的系统资源占用量监控方法的流程图；

图2是根据本发明一种实施方式提供的应用容器引擎的CPU占用率的曲线图；

图3是根据本发明一种实施方式提供的应用容器引擎的内存使用量的曲线图；

图4是根据本发明一种实施方式提供的Docker的系统资源占用量监控方法的流程图；

图5是根据本发明实施例提供的应用容器引擎的系统资源占用量监控装置的结构示意图；

图6是根据本发明一种实施方式提供的Docker的系统资源占用量监控装置的结构示意图；以及

图7是根据本发明实施例提供的用于实现应用容器引擎的系统资源占用量监控装置的计算机系统的结构示意图。

附图标记说明

51 数据采集模块 52 数据处理模块

53 数据库 54 前端渲染模块

60 Docker 700 计算机系统

701 中央处理模块 702 只读存储器

703 随机访问存储器 704 总线

705 输入/输出接口 706 输入部分

707 输出部分 708 存储部分

709 通信部分 710 驱动器

711 可拆卸介质

具体实施方式

以下结合附图对本发明的具体实施方式进行详细说明。应当理解的是，此处所描述的具体实施方式仅用于说明和解释本发明，并不用于限制本发明。

实施例一

图1是根据本发明实施例提供一种应用容器引擎的系统资源占用量监控方法的流程图。

如图1所示，本发明实施例提供的应用容器引擎的系统资源占用量监控方法可以包括：在步骤11处，多次采集所述应用容器引擎的CPU占用时间和/或内存使用量。

例如，分时多任务操作系统对CPU都是分时间片使用的，比如A进程占用10ms，然后B进程占用30ms，然后空闲60ms，也就是说在100ms的时间内，A进程的CPU占用时间为10ms，B进程的CPU占用时间为30ms。同样的，对于应用容器引擎的CPU占用时间也可以是针对在一定时间内应用容器引擎的CPU占用时间。对于应用容器引擎的内存使用量，可以通过采集应用容器引擎中部署的应用程序的内存使用量来获得。

在步骤12处，根据所述应用容器引擎的CPU占用时间获得所述应用容器引擎的CPU占用率。

在步骤13处，使用所述应用容器引擎的CPU占用率和/或内存使用量来表征所述应用容器引擎的系统资源占用量。

其中，应用容器引擎的CPU占用率及其内存使用量均能反映出应用容器引擎对系统资源的消耗，因为可以通过二者中的任意一者或二者相结合来表征所述应用容器引擎的系统资源占用量。

通过本发明提供的上述系统资源占用量监控方法能够实现对应用容器引擎的资源占用量的实时监控，进而能够对产品的生产环境的扩容、缩容问题进行合理把控。

实施例二

所述CPU占用时间可以包括：内核态占用时间和用户态占用时间，因此，在该实施例二中可以多次采集所述应用容器引擎的内核态占用时间和用户态占用时间、和/或内存使用量。

进一步地，可以根据以下等式计算所述应用容器引擎的CPU占用率CPU_oc：CPU_oc＝(cpu_sys+cpu_user-cpu_pre)/(time_now-time_pre)，其中，cpu_sys为所述内核态占用时间，cpu_user为所述用户态占用时间，cpu_pre为上一次采集的所述内核态占用时间与上一次采集的所述用户态占用时间的和，time_now为从第一次采集开始到本次采集所经历的时间，time_pre为从所述第一次采集开始到上一次采集所经历的时间。

也就是说，计算从上次采集至本次采集的时间t内，应用容器引擎的CPU占用时间，然后用CPU占用时间除以从上次采集至本次采集的时间t，从而简单而快速的得出应用容器引擎的CPU占用率。

其中，所述多次采集可以是周期性的，例如采集周期为但不限于10min，当然本领域技术人员也可以采用不定期地采集。

另外，所述系统资源占用量监控方法还可以包括：在所述应用容器引擎的CPU占用率超过CPU占用率阈值和/或所述内存使用量超过内存使用量阈值的情况下，确定所述应用容器引擎的系统资源占用量超限。如此通过CPU占用率阈值和/或内存使用量阈值来判断应用容器引擎的系统资源占用量是否超限，以能够及时对产品的生产环境的扩容、缩容问题进行合理把控，避免造成系统运行缓慢，降低用户的体验感。

而且，为了能够直观的呈现应用容器引擎的系统资源占用量，所述系统资源占用量监控方法还可以包括：将所述CPU占用率和/或所述内存使用量进行前端展示渲染。例如，可以以但不限于曲线或者柱状图的形式来进行渲染。

另外，还可以将采集到的应用容器引擎的CPU占用时间和/或内存使用量存储至数据库中，例如Mysql，针对每次采集到的CPU占用时间和/或内存使用量进行处理，可以在前端进行展示渲染应用容器引擎在时间维度上的CPU占用率和/或内存使用量，例如可以支持1-3天时间内的展示。

例如，图2和图3分别示出了多个应用容器引擎在时间维度上的CPU占用率和内存使用量的曲线图，其中应用程序newtv部署在该多个应用容器引擎上，即，图2和图3实际上显示了应用程序newtv的CPU占用率和内存使用量的曲线图。其中两个图中的直线分别表示设置的CPU占用率阈值和内存使用量阈值。当然应该理解的是，也可以针对不同应用容器引擎设置不同的CPU占用率阈值和不同的内存使用量阈值。

以下将参考图4通过实施例三来详细描述本发明，但是应该注意的是本发明并不限制于此。

实施例三

如图4所示，在步骤41处，周期性采集Docker的CPU占用时间和内存使用量；

在步骤42处，将所采集的Docker的CPU占用时间和内存使用量存储至数据库中；

在步骤43处，从数据库中读取相邻两个周期采集的Docker的CPU占用时间，两次采集的Docker的CPU占用时间的差值的绝对值即该周期时间内Docker的CPU占用时间，使用该周期时间内Docker的CPU占用时间除以周期时间，得出该周期内的CPU占用率，如此能够计算出每个周期内的CPU占用率；

在步骤44处，根据用户需求对Docker的CPU占用率和内存使用量进行前端展示渲染。例如，当用户想要查看应用程序newtv的系统资源占用量时，可以选中应用程序newtv，此时会要求用户选择部署有newtv的所有Docker或者选择其中一个或多个Docker，根据用户的选择，会将所选择的Docker的CPU占用率和内存使用量进行前端展示渲染。另外，客户可以根据需要在客户端输入想要查看的哪段时间的Docker的CPU占用率和内存使用量，如输入2016年3月29日11点20分至2016年3月30日8点30分，在客户端会以曲线形式来显示Docker的CPU占用率和内存使用量(如图2和3所示)，当然也可以设置显示的形式，例如曲线、柱状图等等，并可以根据需求显示某一个或多个指定的Docker的CPU占用率和内存使用量。

虽然，上述仅仅给出针对一个应用的一个或多个Docker的CPU占用率和内存使用量的前端展示渲染，但是还可以针对多个应用程序的Docker的CPU占用率和内存使用量进行前端展示渲染。用户可以选择需要查看的多个应用程序，根据用户选择的应用程序，会将所选的应用程序对应的Docker展示给用户，用户再选择所有或部分Docker，基于用户选择的Docker来展示相应的CPU占用率和内存使用量。

相应地，本发明实施例还提供一种应用容器引擎的系统资源占用量监控装置。图5是根据本发明实施例四提供的应用容器引擎的系统资源占用量监控装置的结构示意图。

实施例四

如图5所示，本发明实施例四提供的应用容器引擎的系统资源占用量监控装置可以包括：数据采集模块51，用于多次采集所述应用容器引擎的CPU占用时间和/或内存使用量；以及数据处理模块52，用于：根据所述应用容器引擎的CPU占用时间获得应用容器引擎的CPU占用率；及使用所述应用容器引擎的CPU占用率和/或内存使用量来表征所述应用容器引擎的系统资源占用量。如此能够实现对应用容器引擎的资源占用量的实时监控，进而能够对产品的生产环境的扩容、缩容问题进行合理把控。

实施例五

所述CPU占用时间可以包括：内核态占用时间和用户态占用时间，因此，数据采集模块51可以多次采集所述应用容器引擎的内核态占用时间和用户态占用时间、和/或内存使用量。

在该实施例中，所述数据处理模块52根据以下等式计算所述应用容器引擎的CPU占用率CPU_oc：CPU_oc＝(cpu_sys+cpu_user-cpu_pre)/(time_now-time_pre)，其中，cpu_sys为所述内核态占用时间，cpu_user为所述用户态占用时间，cpu_pre为上一次采集的所述内核态占用时间与上一次采集的所述用户态占用时间的和，time_now为从第一次采集开始到本次采集所经历的时间，time_pre为从所述第一次采集开始到上一次采集所经历的时间。

其中，所述多次采集可以是周期性的，例如采集周期为但不限于10min，当然本领域技术人员也可以采用不定期地采集。

所述数据处理模块52还用于：在所述应用容器引擎的CPU占用率超过CPU占用率阈值和/或所述内存使用量超过内存使用量阈值的情况下，确定所述应用容器引擎的系统资源占用量超限。如此通过CPU占用率阈值和/或内存使用量阈值来判断应用容器引擎的系统资源占用量是否超限，以能够及时对产品的生产环境的扩容、缩容问题进行合理把控，避免造成系统运行缓慢，降低用户的体验感。

而且，为了能够直观的呈现应用容器引擎的系统资源占用量，所述系统资源占用量监控装置还包括前端渲染模块(例如显示器)：用于将所述CPU占用率和/或所述内存使用量进行前端展示渲染。例如，可以以但不限于曲线或者柱状图的形式来进行渲染。

另外，还可以将采集到的应用容器引擎的CPU占用时间和/或内存使用量存储至数据库中，例如Mysql，针对每次采集到的CPU占用时间和/或内存使用量进行处理，可以在前端进行展示渲染应用容器引擎在时间维度上的CPU占用率和/或内存使用量，例如可以支持1-3天时间内的展示。

实施例六

图6是根据本发明一种实施方式提供的Docker的系统资源占用量监控装置的结构示意图。

如图6所示，该实施方式中，Docker的系统资源占用量监控装置包括：数据采集模块51、数据库53、数据处理模块52以及前端渲染模块54。其中在S61处，数据采集模块51对Docker 60进行CPU占用时间以及内存使用量进行采集；在S62处，将采集的CPU占用时间以及内存使用量存储至数据库53中；在S63处，数据处理模块52读取数据库以获取个采集周期所采集的Docker 60的CPU占用时间以及内存使用量，并对其进行处理，以获得CPU占用率，以及可以根据用户需求绘制相应的CPU占用率以及内存使用量的时间曲线图；在S64处，通过前端渲染模块54向用户形象地展示CPU占用率以及内存使用量，以表征所述应用容器引擎的系统资源占用量。

实施例七

图7是根据本发明实施例提供的用于实现应用容器引擎的系统资源占用量监控装置的计算机系统的结构示意图。

如图7所示，计算机系统700可以包括中央处理模块(CPU)701，其可以根据存储在只读存储器(ROM)702中的程序或者从存储部分708加载到随机访问存储器(RAM)703中的程序而执行各种适当的动作和处理。在RAM 703中，还可以存储有计算机系统700操作所需的各种程序和数据。CPU 701、ROM 702以及RAM 703可以通过总线704彼此相连，而且输入/输出(I/O)接口705也可以连接至总线704。

以下部件连接至I/O接口705：包括键盘、鼠标等的输入部分706；包括诸如阴极射线管(CRT)、液晶显示器(LCD)等以及扬声器等的输出部分707；包括硬盘等的存储部分708；以及包括诸如LAN卡、调制解调器等的网络接口卡的通信部分709。通信部分709经由诸如因特网的网络执行通信处理。驱动器710也根据需要连接至I/O接口705。可拆卸介质711，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器710上，以便于从其上读出的计算机程序根据需要被安装入存储部分708。

特别地，根据本公开的实施例，上文参考流程图描述的过程可以被实现为计算机软件程序。例如，本公开的实施例包括一种计算机程序产品，其包括有形地包含在机器可读介质上的计算机程序，所述计算机程序包含用于执行图1和图4所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信部分709从网络上被下载和安装，和/或从可拆卸介质711被安装。

本领域技术人员可以理解实现上述实施例方法中的全部或部分步骤是可以通过程序来指令相关的硬件来完成，该程序存储在一个存储介质中，包括若干指令用以使得一个设备(可以是单片机，芯片等)或处理器(processor)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

以上结合附图详细描述了本发明的可选实施方式，但是，本发明并不限于上述实施方式中的具体细节，在本发明的技术构思范围内，可以对本发明的技术方案进行多种简单变型，这些简单变型均属于本发明的保护范围。

另外需要说明的是，在上述具体实施方式中所描述的各个具体技术特征，在不矛盾的情况下，可以通过任何合适的方式进行组合，为了避免不必要的重复，本发明对各种可能的组合方式不再另行说明。

此外，本发明的各种不同的实施方式之间也可以进行任意组合，只要其不违背本发明的思想，其同样应当视为本发明所公开的内容。