容器监控方法、装置、设备及计算机可读存储介质与流程

本发明涉及容器管理技术领域，尤其涉及一种容器监控方法、装置、设备及计算机可读存储介质。

背景技术：

随着docker容器技术的发展，docker容器技术的应用越来越广泛。容器技术是利用linux操作系统的特性进行的资源隔离，是的资源更充分和有效利用，但是同时也给容器的管理和运维带来了新的挑战。docker容器的监控就是其中一个方面。

docker容器在操作系统层面的隔离不够完善，宿主机上的所有docker容器与宿主机共享proc文件系统，docker容器运行过程中，用户使用常用的资源查看命令，得到的都是宿主机的资源信息，无法查询到各个docker容器的资源信息。目前通过mesos/marathon、或者kubernetes的docker集群管理方法，来实现对docker容器的监控，但是这两种方案都必须遵循既有规范，不够灵活，docker容器的监控门槛高，难度大。

技术实现要素：

本发明提供一种容器监控方法、装置、设备及计算机可读存储介质，用以解决现有技术中对docker容器的监控方法必须遵循既有规范，不够灵活，容器的监控门槛高，难度大的问题。

本发明的一个方面是提供一种容器监控方法，包括：

启动容器时，将所述容器所在宿主机的自定义用户态文件系统的目标目录挂载到所述容器的指定目录；

将生成的所述容器的用户态文件存储到所述容器的指定目录；

通过所述容器内的代理模块，从所述容器的指定目录采集所述容器的监控数据。

本发明的另一个方面是提供一种容器监控装置，包括：

挂载映射模块，用于启动容器时，将所述容器所在宿主机的自定义用户态文件系统的目标目录挂载到所述容器的指定目录；

数据存储模块，用于将生成的所述容器的用户态文件存储到所述容器的指定目录；

监控模块，用于通过所述容器内的代理模块，从所述容器的指定目录采集所述容器的监控数据。

本发明的另一个方面是提供一种宿主机，其特征在于，包括：

存储器，处理器，以及存储在所述存储器上并可在所述处理器上运行的计算机程序，

所述处理器运行所述计算机程序时实现上述所述的容器监控方法。

本发明的另一个方面是提供一种计算机可读存储介质，存储有计算机程序，

所述计算机程序被处理器执行时实现上述所述的容器监控方法。

本发明提供的容器监控方法、装置、设备及计算机可读存储介质，通过在启动容器时，将所述容器所在宿主机的自定义用户态文件系统的目标目录挂载到所述容器的指定目录；将生成的所述容器的用户态文件存储到所述容器的指定目录；在容器启动后通过所述容器内的代理模块，从所述容器的指定目录采集所述容器的监控数据，从而可以实时地查询到各个容器的资源信息，能够灵活的实现对各个容器的监控，提高了容器运维效率，降低了容器运维的难度。

附图说明

图1为本发明实施例一提供的容器监控方法流程图；

图2为本发明实施例二提供的容器监控方法流程图；

图3为本发明实施例三提供的容器监控装置的结构示意图；

图4为本发明实施例四提供的容器监控装置的结构示意图；

图5为本发明实施例五提供的宿主机的结构示意图。

通过上述附图，已示出本发明明确的实施例，后文中将有更详细的描述。这些附图和文字描述并不是为了通过任何方式限制本发明构思的范围，而是通过参考特定实施例为本领域技术人员说明本发明的概念。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本发明相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本发明的一些方面相一致的装置和方法的例子。

首先对本发明所涉及的名词进行解释：

lxcfs是一个开源的基于linux内核的用户态文件系统(filesysteminuserspace，fuse)。lxcfs基于c语言开发，目前较多使用在lxc容器中。

proc文件系统是一个伪文件系统，它只存在内存当中，而不占用外存空间。它以文件系统的方式为访问系统内核数据的操作提供接口。用户和应用程序可以通过proc文件系统得到系统的信息，并可以改变内核的某些参数。

此外，术语“第一”、“第二”等仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。在以下各实施例的描述中，“多个”的含义是两个以上，除非另有明确具体的限定。

下面这几个具体的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例中不再赘述。下面将结合附图，对本发明的实施例进行描述。

实施例一

图1为本发明实施例一提供的容器监控方法流程图。本发明实施例针对现有技术中对docker容器的监控方法必须遵循既有规范，不够灵活，容器的监控门槛高，难度大的问题，提供了容器监控方法。本实施例中的方法应用于容器所在宿主机。如图1所示，该方法具体步骤如下：

步骤s101、启动容器时，将容器所在宿主机的自定义用户态文件系统的目标目录挂载到容器的指定目录。

本实施例中，在每一个docker容器的宿主机上预先编译安装自定义用户态文件系统。可选的，自定义用户态文件系统可以是lxcfs。

自定义用户态文件系统能够在docker容器内部提供一个虚拟的proc文件系统和docker容器自身的控制组(controlgroup，简称cgroup)的目录树。自定义用户态文件在启动时需指定一个用户态文件系统的目标目录，该目标目录是宿主机上所有容器的文件系统所在的目录。例如，用户态文件系统的目标目录可以指定为：/valivar/lib/lxcfs。

步骤s102、将生成的容器的用户态文件存储到容器的指定目录。

本实施例中，容器的指定目录用于存放容器自身的用户态文件。容器的用户态文件可以包括：用于记录cpu信息的文件，例如cpuinfo文件；用于记录磁盘信息的文件，例如diskstats文件；用于记录内存信息的文件，例如meminfo文件；用于记录cpu时钟片信息的文件，例如stat文件；用于记录交换分区信息的文件，例如swaps文件；用于记录系统启动时间信息的文件，例如uptime文件；等等。

在容器启动时或者容器运行过程中，宿主机会将生成的容器的用户态文件存放到容器的指定目录中。另外，宿主机还可以在容器运行过程中，实时地更新容器的指定目录中的容器的用户态文件的内容。

步骤s103、通过容器内的代理模块，从容器的指定目录采集容器的监控数据。

本实施例中，在构件docker镜像时，在容器内部安装用于采集监控数据的代理模块。容器启动后，宿主机可以通过容器内的代理模块，从容器的指定目录采集容器的监控数据。容器资源监控不再依赖docker开放的api端口，实现了通过容器内的代理模块采集容器的资源数据进行容器监控的形式，实现了一种docker容器监控的新模式。

本发明实施例通过在启动容器时，将容器所在宿主机的自定义用户态文件系统的目标目录挂载到容器的指定目录；将生成的容器的用户态文件存储到容器的指定目录；在容器启动后通过容器内的代理模块，从容器的指定目录采集容器的监控数据，从而可以实时地查询到各个容器的资源信息，能够灵活的实现对各个容器的监控，提高了容器运维效率，降低了容器运维的难度。

实施例二

图2为本发明实施例二提供的容器监控方法流程图。在上述实施例一的基础上，本实施例中，通过容器内的代理模块，从容器的指定目录采集容器的监控数据之后，根据采集的容器的监控数据，计算容器的至少一项指标数据，并将容器的至少一项指标数据进行存储。另外，方法还可以包括：将容器的procps软件包内的各资源查看命令的读取路径修改为容器的指定目录，其中资源查看命令至少包括top命令和free命令。在启动容器之后，接收到对容器的资源查看命令执行指令时，根据资源查看命令执行指令执行对应的资源查看命令，从容器的指定目录中获取对应的监控数据。

如图2所示，该方法具体步骤如下：

步骤s101、启动容器时，将容器所在宿主机的自定义用户态文件系统的目标目录挂载到容器的指定目录。

本实施例中，在每一个docker容器的宿主机上预先编译安装自定义用户态文件系统。可选的，自定义用户态文件系统可以是lxcfs。

自定义用户态文件系统能够在docker容器内部提供一个虚拟的proc文件系统和docker容器自身的cgroup的目录树。自定义用户态文件在启动时需指定一个用户态文件系统的目标目录，该目标目录是宿主机上所有容器的文件系统所在的目录。例如，用户态文件系统的目标目录可以指定为：/valivar/lib/lxcfs。

启动容器时，宿主机将容器所在宿主机的自定义用户态文件系统的目标目录挂载到容器的指定目录，以建立宿主机的自定义用户态文件系统的目标目录与容器的指定目录的映射。

例如，宿主机的用户态文件系统的目标目录可以为：/valivar/lib/lxcfs，容器的指定目录可以为/docker/proc，在该步骤中通过将宿主机的自定义用户态文件系统的目标目录挂载到容器的指定目录，可以建立宿主机的用户态文件系统的目标目录/valivar/lib/lxcfs到容器的指定目录可以为/docker/proc。

可选的，启动自定义用户态文件系统时，将预设目录设置为自定义用户态文件系统的目标目录。

其中，预设目录可以由技术人员根据实际需要进行设定，例如，可以设定预设目录为/valivar/lib/lxcfs，本实施例此处不做具体限定。

步骤s102、将生成的容器的用户态文件存储到容器的指定目录。

本实施例中，容器的指定目录用于存放容器自身的用户态文件。容器的用户态文件可以包括：用于记录cpu信息的文件，例如cpuinfo文件；用于记录磁盘信息的文件，例如diskstats文件；用于记录内存信息的文件，例如meminfo文件；用于记录cpu时钟片信息的文件，例如stat文件；用于记录交换分区信息的文件，例如swaps文件；用于记录系统启动时间信息的文件，例如uptime文件；等等。

在容器启动时或者容器运行过程中，宿主机会将生成的容器的用户态文件存放到容器的指定目录中。另外，宿主机还可以在容器运行过程中，实时地更新容器的指定目录中的容器的用户态文件的内容。

可选的，宿主机可以以挂载数据卷的方式，将目标目录挂载到容器的指定目录。

步骤s103、通过容器内的代理模块，从容器的指定目录采集容器的监控数据。

本实施例中，在构件docker镜像时，在容器内部安装用于采集监控数据的代理模块。容器启动后，宿主机可以通过容器内的代理模块，从容器的指定目录采集容器的监控数据。容器资源监控不再依赖docker开放的api端口，实现了通过容器内的代理模块采集容器的资源数据进行容器监控的形式，实现了一种docker容器监控的新模式。

在容器启动后，容器内的代理模块可以自动运行，从容器的指定目录采集容器的监控数据。容器内的代理模块可以采集容器的指定目录中存储的数据信息，可以包括容器的cpu信息，内存信息，cpu时钟片信息，交换分区信息，系统启动时间信息，等等。

另外，容器内的代理模块可以使用任何开发语言进行自定义开发的程序实现。

步骤s104、根据采集的容器的监控数据，计算容器的至少一项指标数据，并将容器的至少一项指标数据进行存储。

本实施例中，在采集到容器监控数据之后，还可以根据预设规则对容器的监控数据进行统计和分析处理，计算得到容器的至少一项指标数据。例如，容器的指标数据可以是用于表示cpu使用情况、内存使用情况等的统计结果。

另外，具体计算哪些指标数据以及计算指标数据的预设规则可以由技术人员根据实际需要进行设定，本实施例此处不做具体限定。

可选的，宿主机可以将容器的至少一项指标数据存储到数据库中，例如，可以将容器的至少一项指标数据发送到hbase集群，以对指标数据分布式地存储到hbase数据库中。

可选的，指标数据的集中存储可以mondodb等云数据库、或者elasticsearch等分布式存储的方式进行存储，本实施例对于指标数据的存储方式不做具体限定。

步骤s105、通过显示装置显示至少一项指标数据。

该步骤为可选的步骤，在计算得到容器的至少一项指标数据之后，宿主机可以控制显示装置显示容器的至少一项指标数据。例如，可以通过前端web页面显示容器的至少一项指标数据。

可选的，在计算得到容器的至少一项指标数据之后，宿主机还可以将容器的至少一项指标数据发送到指定的监控系统所在的客户端设备，以客户端设备显示容器的至少一项指标数据。

步骤s106、将容器的procps软件包内的各资源查看命令的读取路径修改为容器的指定目录。

其中，资源查看命令至少包括top命令和free命令。

基于linux操作系统的docker镜像一般都会安装procps软件包，该软件包中包含top、free等运维常用的资源查询命令的源码。

本实施例中，宿主机通过修改这些命令的源码，将容器的procps软件包内的各资源查看命令的读取路径修改为容器的指定目录，将procps软件包进行升级。

具体的，将proc文件数据读取的路径由文件系统的路径(例如/proc)修改为容器的指定目录(例如/docker/proc)，完成procps软件包的升级。然后在构件镜像时编译安装升级后的procps软件包，替换基础镜像自带的procps软件包，即可实现在docker容器内运维时通过执行top、free等资源查询命令查看容器真实资源利用状态。

步骤s107、接收到对容器的资源查看命令执行指令时，根据资源查看命令执行指令执行对应的资源查看命令，从容器的指定目录中获取对应的监控数据。

本实施例中，宿主机通过对容器的procps软件包内的各资源查看命令的读取路径修改为容器的指定目录，完成了procps软件包的升级。在接收到对容器的资源查看命令执行指令时，宿主机通过执行对应的资源查看命令，即可从容器的指定目录中获取对应的监控数据，完成对容器的资源使用状况的查询，得到监控数据。

本发明实施例通过对容器的procps软件包升级，将容器的procps软件包内的各资源查看命令的读取路径修改为容器的指定目录，在容器运行过程中，宿主机通过执行对应的资源查看命令，即可从容器的指定目录中获取对应的监控数据，完成对容器的资源使用状况的查询，得到监控数据，实现了通过资源查询命令直接查询容器真实的资源使用情况，能够灵活的实现对各个容器的监控，进一步提高了容器运维效率，降低了容器运维的难度。

实施例三

图3为本发明实施例三提供的容器监控装置的结构示意图。本发明实施例提供的容器监控装置可以执行容器监控方法实施例提供的处理流程。如图3所示，该装置30包括：挂载映射模块301，数据存储模块302，和监控模块303。

具体地，挂载映射模块301用于启动容器时，将容器所在宿主机的自定义用户态文件系统的目标目录挂载到容器的指定目录。

数据存储模块302用于将生成的容器的用户态文件存储到容器的指定目录。

监控模块303用于通过容器内的代理模块，从容器的指定目录采集容器的监控数据。

本发明实施例提供的装置可以具体用于执行上述实施例一所提供的方法实施例，具体功能此处不再赘述。

本发明实施例通过在启动容器时，将容器所在宿主机的自定义用户态文件系统的目标目录挂载到容器的指定目录；将生成的容器的用户态文件存储到容器的指定目录；在容器启动后通过容器内的代理模块，从容器的指定目录采集容器的监控数据，从而可以实时地查询到各个容器的资源信息，能够灵活的实现对各个容器的监控，提高了容器运维效率，降低了容器运维的难度。

实施例四

图4为本发明实施例四提供的容器监控装置的结构示意图。在上述实施例三的基础上，本实施例中，监控模块还用于：根据采集的容器的监控数据，计算容器的至少一项指标数据，并将容器的至少一项指标数据进行存储。

可选的，挂载映射模块还用于：

以挂载数据卷的方式，将目标目录挂载到容器的指定目录。

本实施例中，如图4所示，容器监控装置30还可以包括：软件包升级模块304。

具体的，软件包升级模块304用于将容器的procps软件包内的各资源查看命令的读取路径修改为容器的指定目录。

可选的，监控模块还用于：

接收到对容器的资源查看命令执行指令时，根据资源查看命令执行指令执行对应的资源查看命令，从容器的指定目录中获取对应的监控数据。

本发明实施例提供的装置可以具体用于执行上述实施例二所提供的方法实施例，具体功能此处不再赘述。

本发明实施例通过对容器的procps软件包升级，将容器的procps软件包内的各资源查看命令的读取路径修改为容器的指定目录，在容器运行过程中，宿主机通过执行对应的资源查看命令，即可从容器的指定目录中获取对应的监控数据，完成对容器的资源使用状况的查询，得到监控数据，实现了通过资源查询命令直接查询容器真实的资源使用情况，能够灵活的实现对各个容器的监控，进一步提高了容器运维效率，降低了容器运维的难度。

实施例五

图5为本发明实施例五提供的宿主机的结构示意图。如图5所示，本实施例中，该宿主机50可以运行多个容器。该宿主机50包括：处理器501，存储器502，以及存储在存储器502上并可由处理器501执行的计算机程序。

处理器501在执行存储在存储器502上的计算机程序时实现上述任一方法实施例提供的容器方法。

本发明实施例通过在启动容器时，将容器所在宿主机的自定义用户态文件系统的目标目录挂载到容器的指定目录；将生成的容器的用户态文件存储到容器的指定目录；在容器启动后通过容器内的代理模块，从容器的指定目录采集所述容器的监控数据，从而可以实时地查询到各个容器的资源信息，能够灵活的实现对各个容器的监控，提高了容器运维效率，降低了容器运维的难度。

另外，本发明实施例还提供一种计算机可读存储介质，存储有计算机程序，所述计算机程序被处理器执行时实现上述任一方法实施例提供的容器监控方法。

在本发明所提供的几个实施例中，应该理解到，所揭露的装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的形式实现。

上述以软件功能单元的形式实现的集成的单元，可以存储在一个计算机可读取存储介质中。上述软件功能单元存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或处理器(processor)执行本发明各个实施例所述方法的部分步骤。而前述的存储介质包括：u盘、移动硬盘、只读存储器(read-onlymemory，rom)、随机存取存储器(randomaccessmemory，ram)、磁碟或者光盘等各种可以存储程序代码的介质。

本领域技术人员可以清楚地了解到，为描述的方便和简洁，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将装置的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。上述描述的装置的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本发明的其它实施方案。本发明旨在涵盖本发明的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本发明的一般性原理并包括本发明未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本发明的真正范围和精神由下面的权利要求书指出。

应当理解的是，本发明并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本发明的范围仅由所附的权利要求书来限制。