具体实施方式
下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例,然而应当理解,可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反,提供这些实施例是为了能够更透彻地理解本公开,并且能够将本公开的范围完整的传达给本领域的技术人员。
图1示出了根据本发明一个实施例的对宿主机中容器进行本地实时监控的方法的流程图。如图1所示,本方法包括以下步骤:
步骤S101,扫描宿主机内处于存活状态的容器,更新容器列表。
本发明在宿主机内部启动本地监控程序(也称:localmonitor),本地监控程序定时扫描宿主机内处于存活状态的容器,更新容器列表,容器列表中记录有处于存活状态的容器名称。
步骤S102,为容器列表中每个处于存活状态的容器配置对应的进程。
本发明的本地监控程序在第一次启动时为容器列表中每个处于存活状态的容器创建对应的进程。在后续定时执行本方法的过程中,在更新容器列表后,先查找上一次方法执行时是否已存在各个容器对应的进程,若未查找到某个容器的进程,则为该容器创建进程。通过本步骤,保证宿主机内存活的容器都有对应的进程为其实行监控服务。也即,本方法为多进程的处理方法,多个进程并行执行以获取各个容器的监控信息。
步骤S103,各个进程同步抽取各自容器的原始状态信息。
本步骤中,各个进程是同步运行的,每个进程负责抽取其对应的容器的原始状态信息。
步骤S104,对各容器的原始状态信息进行处理得到监控信息,以进行显示。
在每个进程抽取各自容器的原始状态信息之后,可以对各容器的原始状态信息进行处理得到监控信息,将这些监控信息汇总起来,而后由用于进行显示的终端将各个容器的监控信息进行刷新显示,以同时展示宿主机内处于存活状态的所有容器的监控信息。应可理解,上述对原始状态信息的处理可以由各个进程分别执行,也可以由相同进程/模块统一执行。
通过本实施例提供的监控方法,为每个处于存活状态的容器创建各自的进程,采用多进程并行运行的方式,抽取处理得到各个容器的监控信息进行展示。利用本方法,运维人员只需启动本地监控程序,该本地监控程序利用创建的多进程抽取各个容器的监控信息,与现有技术繁琐的手动方式相比,大大提高了执行效率。而且,由于多个进程同步抽取处理得到监控信息,这样刷新展示的时候显示的是多个容器在同一时刻的监控数据,运维人员可依据这些监控数据对多个容器的状态进行比较分析,更有利于反映出宿主机内各个容器的运行状态,提升了监控效率。
图2示出了根据本发明另一个实施例的对宿主机中容器进行本地实时监控的方法的流程图。本实施例以宿主机为基于Docker应用容器引擎的服务器为例进行说明,以下称这样的宿主机为Docker宿主机。Docker宿主机根据终端发送的监控命令启动本地监控程序,本地监控程序每隔预定时间定时运行执行如图2所示的方法,该方法具体包括以下步骤:
步骤S201,调用Docker应用容器引擎的接口,查看处于存活状态的容器,更新容器列表。
Docker作为开源工具提供了许多可调用接口,本地监控程序可通过调用对应的接口查找到当前处于存活状态的容器列表。本实施例中,本地监控程序调用容器发现接口,具体代码实现如下:
上述容器发现接口调用后所返回的值就是容器列表,可选地,将容器列表处理为json格式,如下:
{“data”:[{“{#NODE}”:“c0021v.add.bjdt.qihoo.net”},{“{#NODE}”:“c0016v.add.bjdt.qihoo.net”},{“{#NODE}”:“c0010v.add.bjdt.qihoo.net”},{“{#NODE}”:“c0006v.add.bjdt.qihoo.net”},{“{#NODE}”:“c0002v.add.bjdt.qihoo.net”}]}
上述示例中列出了5个容器的容器名称,分别为“c0021v.add.bjdt.qihoo.net”、“c0016v.add.bjdt.qihoo.net”、“c0010v.add.bjdt.qihoo.net”、“c0006v.add.bjdt.qihoo.net”以及“c0002v.add.bjdt.qihoo.net”。
步骤S202,查找容器列表中每个容器对应的进程,对于未查找到进程的容器,创建该容器对应的进程。
本地监控程序为每一个处于存活状态的容器创建对应的进程。本方法是定时执行的,如果此次方法执行得到的容器列表与上一次方法执行得到的容器列表一致,表明当前容器列表中每个容器都具有对应的进程(之前创建的进程);如果此次方法执行得到的容器列表相比上一次方法执行得到的容器列表增添了新的容器,那么本步骤为该容器创建对应的进程;如果此次方法执行得到的容器列表相比上一次方法执行得到的容器列表减少了某些容器,也即Docker宿主机内存在此次容器列表内未记录的容器对应的进程,则销毁这些进程。通过该处理过程,保证Docker宿主机内存活的容器都有对应的进程为其实行监控服务。本方法为多进程的处理方法,多个进程并行执行以获取各个容器的监控信息。
步骤S203,各个进程同步抽取各自容器的原始状态信息。
本步骤中,各个进程是同步运行的,每个进程负责抽取其对应的容器的原始状态信息。例如,对于上述示例中的5个容器,分别对应有进程A、B、C、D和E,这5个进程同步运行。
各个进程抽取的原始状态信息包含但不限于以下几种:cpu状态信息、内存状态信息、网络状态信息以及磁盘状态信息。这几种信息是反映容器运行状态的关键指标信息。Docker宿主机内具有一指定目录cgroup,cgroup目录下有一些文件是实时更新的,cpu状态信息和内存状态信息可通过读取这些文件记录的数据得到。而网络状态信息和磁盘状态信息可通过调用Docker的exec()接口得到。
步骤S204,对各容器的原始状态信息进行处理得到监控信息。
各个进程处理得到的监控信息包含但不限于以下几种:cpu占用信息、内存占用信息、网络流量信息以及磁盘占用信息。
下面通过几个具体的示例介绍进程抽取各种原始状态信息和处理得到各种监控信息的方法。
对于cpu占用信息,以cpu空闲率为例进行说明:
(1)首先,进程在Docker的cgroup目录下读取文件,得到宿主机内部所有cpu的中断值。
cat/proc/stat
cpu 3133469 7401 3104242 3553123569 132473 58 21602 0 0 0
cpu0 251944 9 260082 147709125 8397 0 5074 0 0 0
cpu1 304201 33 145887 147843986 9281 0 1561 0 0 0
cpu2 225218 202 166714 147876139 8957 9 2568 0 0 0
cpu3 215084 140 171011 147888463 8706 0 826 0 0 0
cpu4 266368 12 158857 147866110 8352 0 739 0 0 0
cpu5 203034 50 143072 147945613 7846 0 635 0 0 0
cpu6 105463 1435 210546 147987078 9087 0 2338 0 0 0
cpu7 139176 779 116588 148059723 9221 0 645 0 0 0
cpu8 137439 56 194463 147940180 8667 0 219 0 0 0
cpu9 87186 66 161497 148063120 8368 0 148 0 0 0
cpu10 75995 129 108372 148123556 11497 0 192 0 0 0
cpu11 76255 553 222601 148008104 9589 0 227 0 0 0
cpu12 37616 390 29130 148273198 519 0 104 0 0 0
cpu13 192658 1721 147542 147973978 1709 0 144 0 0 0
cpu14 91335 27 77563 148165505 748 0 102 0 0 0
cpu15 113149 44 135527 148086739 378 0 90 0 0 0
cpu16 74054 24 50266 148206655 1187 6 845 0 0 0
cpu17 56611 11 22716 148251531 1337 5 1075 0 0 0
cpu18 31401 2 38718 148264411 1431 10 611 0 0 0
cpu19 181266 1682 147994 147947551 4622 7 674 0 0 0
cpu20 97981 2 88707 148135665 1732 4 901 0 0 0
cpu21 96187 10 156737 148069044 3637 4 944 0 0 0
cpu22 53852 10 54436 148212130 4637 9 896 0 0 0
cpu23 19986 2 95205 148225954 2557 0 35 0 0 0
本示例中,Docker宿主机内部共有24个cpu,上述第二列信息为各个cpu的中断值。
(2)进程获取对应容器所占用的cpu总中断值。
cat/cgroup/cpuacct/docker/00bd87b4bd7f2cab5ac6912eda67c1a55a943f825c7624b273d6ff7d497a45df/cpuacct.stat
user 1048888
system 359653
其中,“user 1048888”是容器占用的用户态的中断值,“system 359653”是容器占用的内核态的中断值,这两个数值之和理解为容器所占用的cpu总中断值。
(3)根据宿主机的cpu共享策略,对容器所占用的cpu总中断值进行处理得到容器的cpu空闲率。
这里宿主机的cpu共享策略分为两种,一种是共享cpu,另一种是不共享cpu。对于不同的共享策略,cpu空闲率的计算方式不同:
其中,cfs_quota_us为-1,表示共享cpu,利用容器后一秒的中断值减去前一秒的中断值得到数值a,利用宿主机后一秒的总中断值减去前一秒的总中断值的得到宿主机的总中断值b,a/b*100得到该容器的cpu空闲率c_cpu_idle。
cfs_quota_us为-1,表示不共享cpu,而且cfs_quota_us的数值本身表示分配给该容器的中断比值,利用容器后一秒的中断值减去前一秒的中断值得到数值a,利用cfs_quota_us除以10000得到值b,a/b*100得到该容器的cpu空闲率c_cpu_idle。
对于内存占用信息,以内存占用值和内存占用比例为例说明。
进程在Docker的cgroup目录下读取文件,得到内存状态信息。
cat/cgroup/memory/docker/00bd87b4bd7f2cab5ac6912eda67c1a55a943f825c7624b273d6ff7d497a45df/memory.stat
cache 1303879680
rss 74170368
rss_huge 8388608
mapped_file 19103744
writeback 0
swap 0
pgpgin 300770031
pgpgout 300439725
pgfault 1104410446
pgmajfault 1068
inactive_anon 602853376
active_anon 74174464
inactive_file 289038336
active_file 411983872
unevictable 0
hierarchical_memory_limit 8589934592
hierarchical_memsw_limit 17179869184
total_cache 1303879680
total_rss 74170368
total_rss_huge 8388608
total_mapped_file 19103744
total_writeback 0
total_swap 0
total_pgpgin 300770031
total_pgpgout 300439725
total_pgfault 1104410446
total_pgmajfault 1068
total_inactive_anon 602853376
total_active_anon 74174464
total_inactive_file 289038336
total_active_file 411983872
total_unevictable 0
其中,“total_rss 74170368”即为容器的内存占用值,根据该内存占用值和分配给容器的内存总大小计算得到内存占用比例。
对于网络流量信息,以网络流量(in)和网络流量(out)为例进行说明:
进程通过调用Docker的exec()接口得到网络状态信息。
例如,调用exec()接口得到网卡出入站数据:
cat/sys/devices/virtual/net/eth0/statistics/rx_bytes
13210803
cat/sys/devices/virtual/net/eth0/statistics/tx_bytes
32392931
由于网卡出入站数据为流量的累加数据,因此利用后一秒的网卡出入站数据减去前一秒的网卡出入站数据,得到后一秒时刻的网络流量in和out数据。
对于磁盘占用信息,也可通过调用Docker的exec()接口得到磁盘状态信息,进而处理得到磁盘占用值和磁盘占用比例。
步骤S205,将所有容器的监控信息汇总到数据队列中,每个容器的监控信息利用容器标识进行区分。
上述各个进程抽取到监控信息后,将监控信息汇总到数据队列中。每个容器的监控信息利用容器标识进行区分,这里的容器标识是标示容器的唯一标识,如可采用上述容器名称作为容器标识。
步骤S206,根据容器标识从数据队列中提取各个容器的监控信息,将各个容器的监控信息发送给终端。
步骤S207,终端将各个容器的监控信息插入到对应的显示区域进行刷新显示。
将提取的各个容器的监控信息提供给终端,终端实时从顶端清屏以刷新数据进行展示。各个容器的各种监控信息在终端对应有显示区域,将各个容器的各种监控信息分别插入到对应的显示区域进行刷新显示。本实施例以表格的形式展示终端所示的数据,如表1所示。
表1
本实施例也可设定终端数据的刷新率,例如刷新间隔为1s。终端数据的刷新率与后端数据的更新率有关,后端数据的更新率至少高于终端数据的刷新率。进一步的,后端数据的更新率是由本实施例方法执行的预定时间间隔决定的,可选的,该预定时间依据系统性能而设定。在系统运行正常、资源丰富的情况下,运维人员无需经常查看宿主机中容器的运行状态,这样预定时间设定可较长;在系统运行不正常、资源紧张等情况下,运维人员需要实时查看宿主机中的容器的运行状态,这样预定时间设定可较短,提升后端数据的更新率,进而提高终端数据的刷新率。
通过本实施例提供的监控方法,为每个处于存活状态的容器创建各自的进程,采用多进程并行运行的方式,抽取处理得到各个容器的监控信息进行展示。利用本方法,运维人员只需启动本地监控程序,该本地监控程序自动定时运行,每隔预定时间利用创建的多进程抽取各个容器的监控信息,与现有技术繁琐的手动方式相比,大大提高了执行效率。而且,由于多个进程同步抽取监控信息,这样刷新展示的时候显示的是多个容器在同一时刻的监控数据,运维人员可依据这些监控数据对多个容器的状态进行比较分析,更有利于反映出宿主机内各个容器的运行状态,提升了监控效率。
具体来说,多进程处理一方面提高了监控方法的执行效率,提升了终端显示的实时性;另一个方面可以让多个容器的监控信息同时实时更新,避免了多个容器之间信息更新的时延问题。例如,在容器数量很多的情况下,如果从头到尾顺序更新各个容器的监控信息,很有可能导致最后一个容器的监控信息更新完毕后,最早更新的容器的监控信息已经失效,这样运维人员无法对容器的监控信息进行对比分析,及时发现一些资源争抢状况。
图3示出了根据本发明一个实施例的对宿主机中容器进行本地实时监控的装置的功能结构框图。如图3所示,该装置300包括:扫描模块310、配置模块320、抽取模块330以及处理模块340。
扫描模块310,适于扫描宿主机内处于存活状态的容器,更新容器列表。以宿主机为基于Docker应用容器引擎的服务器为例,扫描模块310进一步适于:调用Docker应用容器引擎的接口,查看处于存活状态的容器。参照方法实施例的描述,扫描模块310调用容器发现接口discovery(),其返回值就是容器列表,可选地,将容器列表处理为json格式。
配置模块320,适于为容器列表中每个处于存活状态的容器配置对应的进程。可选的,在第一次装置运行时,配置模块320适于为容器列表中每个容器创建对应的进程。在后续装置定时运行时,配置模块320适于查找容器列表中每个容器对应的进程,对于未查找到进程的容器,创建该容器对应的进程。如果配置模块320查找到此次装置运行得到的容器列表相比上一次装置运行得到的容器列表增添了新的容器,则为该容器创建对应的进程。配置模块320还适于若宿主机内存在容器列表内未记录的容器对应的进程,销毁该进程。
抽取模块330,适于利用各个进程同步抽取各自容器的原始状态信息。
处理模块340,适于对各容器的原始状态信息进行处理得到监控信息,以进行显示。
应可理解,上述对原始状态信息的处理,可以通过处理模块340利用各个进程分别执行的方式完成,也可以由相同进程/模块统一执行来完成。
各个进程处理的监控信息包含但不限于以下几种:cpu占用信息、内存占用信息、网络流量信息以及磁盘占用信息。这几种信息是反映容器运行状态的关键指标信息。Docker宿主机内具有一指定目录cgroup,cgroup目录下有一些文件是实时更新的,cpu状态信息和内存状态信息可通过读取这些文件记录的数据得到。而网络状态信息和磁盘状态信息可通过调用Docker的exec()接口得到。
抽取模块330进一步适于:进程在Docker应用容器引擎的指定目录下抽取所述宿主机内部所有cpu的中断值;进程获取对应的容器所占用的cpu总中断值。处理模块340进一步适于:根据宿主机的cpu共享策略,对容器所占用的cpu总中断值进行处理得到容器的cpu占用信息。
以cpu空闲率为例,首先,抽取模块330在Docker的cgroup目录下读取文件,得到宿主机内部所有cpu的中断值;接着,获取对应容器所占用的cpu总中断值;然后,处理模块340根据宿主机的cpu共享策略,对容器所占用的cpu总中断值进行处理得到容器的cpu空闲率。
这里宿主机的cpu共享策略分为两种,一种是共享cpu,另一种是不共享cpu。对于不同的共享策略,cpu空闲率的计算方式不同。具体计算方式可参见上面实施例的描述。
抽取模块330进一步适于:进程在docker应用容器引擎的指定目录下抽取内存状态信息;和/或,进程调用docker应用容器引擎的exec接口,抽取得到网络状态信息和/或磁盘状态信息。
处理模块340进一步适于:对内存状态信息进行处理得到内存占用信息;和/或,对网络状态信息和/或磁盘状态信息进行处理得到网络流量信息和/或磁盘占用信息。
可选地,所述装置还包括汇总模块350,适于将所有容器的监控信息汇总到数据队列中,每个容器的监控信息利用容器标识进行区分。
本实施例提供的装置每隔预定时间运行一次,该预定时间是依据系统性能来设定的。在系统运行正常、资源丰富的情况下,运维人员无需经常查看宿主机中容器的运行状态,这样预定时间设定可较长;在系统运行不正常、资源紧张等情况下,运维人员需要实时查看宿主机中的容器的运行状态,这样预定时间设定可较短,提升后端数据的更新率,进而提高终端数据的刷新率。
图4示出了根据本发明一个实施例的对宿主机中容器进行本地实时监控的系统的功能结构框图。如图4所示,该系统包括图3所示的装置300和终端400。
其中,终端400适于向装置300发送监控命令。装置300接收到监控命令后定时运行,向终端返回所有容器的监控信息。
终端400接收到装置300返回的所有容器的监控信息之后,实时从顶端清屏以刷新数据进行展示。各个容器的各种监控信息在终端对应有显示区域,将各个容器的各种监控信息分别插入到对应的显示区域进行刷新显示。本实施例也可设定终端数据的刷新率,例如刷新间隔为1s。终端数据的刷新率与后端数据的更新率有关,后端数据的更新率至少高于前端数据的刷新率。
通过本实施例提供的监控装置及系统,为每个处于存活状态的容器创建各自的进程,采用多进程并行运行的方式,抽取处理得到各个容器的监控信息进行展示。利用本装置或系统,运维人员只需启动本地监控程序,该本地监控程序自动定时运行,每隔预定时间利用创建的多进程抽取各个容器的监控信息,与现有技术繁琐的手动方式相比,大大提高了执行效率。而且,由于多个进程同步抽取监控信息,这样刷新展示的时候显示的是多个容器在同一时刻的监控数据,运维人员可依据这些监控数据对多个容器的状态进行比较分析,更有利于反映出宿主机内各个容器的运行状态,提升了监控效率。
在此提供的算法和显示不与任何特定计算机、虚拟系统或者其它设备固有相关。各种通用系统也可以与基于在此的示教一起使用。根据上面的描述,构造这类系统所要求的结构是显而易见的。此外,本发明也不针对任何特定编程语言。应当明白,可以利用各种编程语言实现在此描述的本发明的内容,并且上面对特定语言所做的描述是为了披露本发明的最佳实施方式。
在此处所提供的说明书中,说明了大量具体细节。然而,能够理解,本发明的实施例可以在没有这些具体细节的情况下实践。在一些实例中,并未详细示出公知的方法、结构和技术,以便不模糊对本说明书的理解。
类似地,应当理解,为了精简本公开并帮助理解各个发明方面中的一个或多个,在上面对本发明的示例性实施例的描述中,本发明的各个特征有时被一起分组到单个实施例、图、或者对其的描述中。然而,并不应将该公开的方法解释成反映如下意图:即所要求保护的本发明要求比在每个权利要求中所明确记载的特征更多的特征。更确切地说,如下面的权利要求书所反映的那样,发明方面在于少于前面公开的单个实施例的所有特征。因此,遵循具体实施方式的权利要求书由此明确地并入该具体实施方式,其中每个权利要求本身都作为本发明的单独实施例。
本领域那些技术人员可以理解,可以对实施例中的设备中的模块进行自适应性地改变并且把它们设置在与该实施例不同的一个或多个设备中。可以把实施例中的模块或单元或组件组合成一个模块或单元或组件,以及此外可以把它们分成多个子模块或子单元或子组件。除了这样的特征和/或过程或者单元中的至少一些是相互排斥之外,可以采用任何组合对本说明书(包括伴随的权利要求、摘要和附图)中公开的所有特征以及如此公开的任何方法或者设备的所有过程或单元进行组合。除非另外明确陈述,本说明书(包括伴随的权利要求、摘要和附图)中公开的每个特征可以由提供相同、等同或相似目的的替代特征来代替。
此外,本领域的技术人员能够理解,尽管在此所述的一些实施例包括其它实施例中所包括的某些特征而不是其它特征,但是不同实施例的特征的组合意味着处于本发明的范围之内并且形成不同的实施例。例如,在下面的权利要求书中,所要求保护的实施例的任意之一都可以以任意的组合方式来使用。
本发明的各个部件实施例可以以硬件实现,或者以在一个或者多个处理器上运行的软件模块实现,或者以它们的组合实现。本领域的技术人员应当理解,可以在实践中使用微处理器或者数字信号处理器(DSP)来实现根据本发明实施例的监控装置中的一些或者全部部件的一些或者全部功能。本发明还可以实现为用于执行这里所描述的方法的一部分或者全部的设备或者装置程序(例如,计算机程序和计算机程序产品)。这样的实现本发明的程序可以存储在计算机可读介质上,或者可以具有一个或者多个信号的形式。这样的信号可以从因特网网站上下载得到,或者在载体信号上提供,或者以任何其他形式提供。
应该注意的是上述实施例对本发明进行说明而不是对本发明进行限制,并且本领域技术人员在不脱离所附权利要求的范围的情况下可设计出替换实施例。在权利要求中,不应将位于括号之间的任何参考符号构造成对权利要求的限制。单词“包含”不排除存在未列在权利要求中的元件或步骤。位于元件之前的单词“一”或“一个”不排除存在多个这样的元件。本发明可以借助于包括有若干不同元件的硬件以及借助于适当编程的计算机来实现。在列举了若干装置的单元权利要求中,这些装置中的若干个可以是通过同一个硬件项来具体体现。单词第一、第二、以及第三等的使用不表示任何顺序。可将这些单词解释为名称。