资讯专栏INFORMATION COLUMN

Docker 监控的一点想法

doodlewind / 2468人阅读

摘要:目前项目内部署了,于是涉及到关于监控的事情,参考一些经典实例以及一些自己的想法,总结一下思路。监控方便,只能通过在宿主机本身查看对应容器的。

目前项目内部署了docker,于是涉及到关于监控的事情,参考一些经典实例以及一些自己的想法,总结一下思路。

1、关于监控的内容 监控宿主机本身

监控宿主机本身还是比较简单的,同其他服务器监控类似,对cpu、network、io、disk等做通用的检查,这里不再细说。

额外的,因为是docker的宿主机,还应该监控 容器本身的一些指标,如 :

拥有的全部的容器数量;

正在运行的容器的数量;

dead容器的数量(如果此数量变化应该报警);

docker 本身的信息,如Storage Driver、Data Space Used、Data Space Total、Metadata Space Total、Metadata Space Used、client version、client api version、server version、servier api version 等;

监控容器

docker容器通过namespace做资源隔离,通过cgroup来做资源限制。监控方便,只能通过在宿主机本身查看对应容器的cgroup stats。

具体大项有:

容器的本身信息,如名称,ip、使用的镜像、启动时间、启动命令等;

容器的状态,如可先监控两个量值,running or not running (当状态变化时报警);

容器使用cpu的资源信息;

容器使用memory的资源信息;

容器的network io信息;

容器的disk信息;

2、关于监控项的获取 宿主机本身

宿主机的一般信息获取 见zabbix监控项,不重复。

拥有的全部容器的数量:

docker ps -a -q | wc -l

正在运行的容器的数量:

docker ps  -q | wc -l 

非运行状态的容器的数量:

docker ps -a  | grep -v "Up "  | grep -v "CONTAINER" | wc -l

docker本身信息,可从命令 docker version & docker info中获取

监控容器

1、容器本身信息 & 状态:

从docker inspect 中获取,简单脚本如下:

#!/usr/bin/env python
import commands
import sys
import types
import json
def get_container_info( container ):
msg = commands.getoutput("docker inspect "+container)
#return msg
data = json.loads( msg )
return data[0]
container = sys.argv[1]
msg = get_container_info( container )
containerid = msg["Id"]
image = msg["Image"]
name = msg["Name"]
ip = msg["NetworkSettings"]["IPAddress"]
status = msg["State"]["Running"]
startedat = msg["State"]["StartedAt"]
print containerid, image, name, ip, status, startedat

2、 容器使用cpu情况:

从cpuacct中获取相应的值,首先要获取一个cpu周期的时间值,getconf CLK_TCK,默认为100,即100Hz,一个周期即为 1/100s = 10ms = 10^7 ns;

可以获取cpuacct.usage、 cpuacct.stat ,但是具体怎么做对比,还得观察。

理论上的计算方法为,在单位时间内,docker 容器对应的cpu使用的变化值 除以 总系统cpu时间的变化值 乘以 100%;其中,docker容器对应的cpu值可以从cgroup.cpuacct中的cpuacct.usage值得到,他的单位是纳秒,10^9个纳秒为1秒;系统的cpu总时间可以从/proc/stat中获取,第一行中。以“cpu ”开头那行,数值累加就是当前系统cpu总时间,需要注意的是,他的数值单位为 “cpu周期”,就是刚才获取到的 1/CLK_TCK ,关于/proc/stat 的说明文档:http://www.linuxhowtos.org/System/procstat.htm

从docker源码中获知,docker的stats计算方法和这个有点出入,它在此计算的基础上,又乘以 cpu核数 得到最终结果,这个让我有点不理解,和官方确认中。。。。。
已经和官方确认,只是双方对“cpu利用率如何定义”的问题,我认为应该是平均利用率,官方认为应该是total cpu 利用率,好吧。。。。。 地址为: #issues 13626
相关源码地址为:https://github.com/docker/docker/blob/0d445685b8d628a938790e50517f3fb9...

以下是用shell完成的模拟docker计算cpu利用率方法的小脚本:

#!/bin/sh
##echo user nice system idle iowait irq softirq
CPULOG_1=$(cat /proc/stat | grep "cpu " | awk "{print $2" "$3" "$4" "$5" "$6" "$7" "$8}")
Total_1=$(echo $CPULOG_1 | awk "{print $1+$2+$3+$4+$5+$6+$7}")
CGROUP_USAGE_1=$(cat /cgroup/cpuacct/docker/55dec85d2e93c487fbeb1e85c9677e64dd1b4bdcc5be0e5f2539e52c87641d4e/cpuacct.usage)
sleep 1
CPULOG_2=$(cat /proc/stat | grep "cpu " | awk "{print $2" "$3" "$4" "$5" "$6" "$7" "$8}")
Total_2=$(echo $CPULOG_2 | awk "{print $1+$2+$3+$4+$5+$6+$7}")
CGROUP_USAGE_2=$(cat /cgroup/cpuacct/docker/55dec85d2e93c487fbeb1e85c9677e64dd1b4bdcc5be0e5f2539e52c87641d4e/cpuacct.usage)
CGROUP_USAGE=`expr $CGROUP_USAGE_2 - $CGROUP_USAGE_1`
Total=`expr $Total_2 - $Total_1`
CGROUP_RATE=`expr $CGROUP_USAGE*24/$Total/10000000*100|bc -l`
echo $CGROUP_USAGE_1 , $CGROUP_USAGE_2 , $CGROUP_USAGE , $Total,  $CGROUP_RATE

3、 容器使用memory情况:

从容器所在cgroup组中查看memory.stats信息,具体值 的信息如下

统计  描述
cache   页缓存,包括 tmpfs(shmem),单位为字节
Rss 匿名和 swap 缓存,不包括 tmpfs(shmem),单位为字节
Mapped_file memory-mapped 映射的文件大小,包括 tmpfs(shmem),单位为字节
pgpgin  存入内存中的页数
pgpgout 从内存中读出的页数
swap    swap 用量,单位为字节
Active_anon 在活跃的最近最少使用(least-recently-used,LRU)列表中的匿名和 swap 缓存,包括 tmpfs(shmem),单位为字节
Inactive_anon   不活跃的 LRU 列表中的匿名和 swap 缓存,包括tmpfs(shmem),单位为字节
Active_file 活跃 LRU 列表中的 file-backed 内存,以字节为单位
Inactive_file   不活跃 LRU 列表中的 file-backed 内存,以字节为单位
unevictable 无法再生的内存,以字节为单位
hierarchical_memory_limit(重点)   包含 memory cgroup 的层级的内存限制,单位为字节
hierarchical_memsw_limit    包含 memory cgroup 的层级的内存加 swap 限制,单位为字节

4、容器网络io情况: 可以执行命令: docker exec ifconfig eth0 看 Rx和Tx的值。

5、磁盘io情况 从blkio 中获取,相关参考:

blkio.time:统计cgroup对设备的访问时间,按格式device_types:node_numbers milliseconds读取信息即可,以下类似。

blkio.io_serviced:统计cgroup对特定设备的IO操作(包括read、write、sync及async)次数,格式device_types:node_numbers operation number

blkio.sectors:统计cgroup对设备扇区访问次数,格式device_types:node_numbers sector_count

blkio.io_service_bytes:统计cgroup对特定设备IO操作(包括read、write、sync及async)的数据量,格式device_types:node_numbers operation bytes

blkio.io_queued:统计cgroup的队列中对IO操作(包括read、write、sync及async)的请求次数,格式number operation

blkio.io_service_time:统计cgroup对特定设备的IO操作(包括read、write、sync及async)时间(单位为ns),格式device_types:node_numbers operation time

blkio.io_merged:统计cgroup 将 BIOS 请求合并到IO操作(包括read、write、sync及async)请求的次数,格式number operation

blkio.io_wait_time:统计cgroup在各设备中各类型IO操作(包括read、write、sync及async)在队列中的等待时间(单位ns),格式device_types:node_numbers operation time

6、磁盘使用情况,我以为只需要监控docker pool space的状况即可,默认建立100G的空间供docker使用,可通过docker info来查看,一个典型的输出如下:

Containers: 11
Images: 181
Storage Driver: devicemapper
Pool Name: docker-8:5-7471107-pool
Pool Blocksize: 65.54 kB
Backing Filesystem: extfs
Data file: 
Metadata file: 
Data Space Used: 7.846 GB
Data Space Total: 107.4 GB
Metadata Space Used: 15.92 MB
Metadata Space Total: 2.147 GB
Udev Sync Supported: true
Library Version: 1.02.89-RHEL6 (2014-09-01)
Execution Driver: native-0.2
Kernel Version: 2.6.32-431.el6.x86_64
Operating System: 
CPUs: 24
Total Memory: 62.87 GiB
Name: jx-lj-opweb01.lianjia.com
ID: QTML:RSSS:IKAX:FRIP:4YEQ:IXWX:ROMV:APZD:RV4M:ISY2:QW2D:VMXW

7、在前期可以先重点监控 宿主机情况 & 容器的memory状态,其他状态可记录,监控值可稍后商榷。

文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。

转载请注明本文地址:https://www.ucloud.cn/yun/26404.html

相关文章

  • 基于kubernetes的docker集群实践

    摘要:健康监控检查,可以说是集群中最重要的一部分了。我们在这里没有使用推荐的方式,我们自己将其与内部的系统做了结合,通过来对整个集群进行监控报警自动化操作。 在公司内部,基于kubernetes实现了简单的docker应用集群系统,拿出来和大家分享下,在这个系统中,实现了应用的自动部署、动态扩容、节点切换、健康检查、AB式版本更新等功能,也欢迎大家将各自的实现也分享给我。 整体架构 整体架构...

    meislzhua 评论0 收藏0
  • 基于kubernetes的docker集群实践

    摘要:健康监控检查,可以说是集群中最重要的一部分了。我们在这里没有使用推荐的方式,我们自己将其与内部的系统做了结合,通过来对整个集群进行监控报警自动化操作。 在公司内部,基于kubernetes实现了简单的docker应用集群系统,拿出来和大家分享下,在这个系统中,实现了应用的自动部署、动态扩容、节点切换、健康检查、AB式版本更新等功能,也欢迎大家将各自的实现也分享给我。 整体架构 整体架构...

    Flink_China 评论0 收藏0
  • OpenStack采用Kubernetes,开始走谷歌路线了

    摘要:是一个用这种很谷歌的完美方式来运行大规模分布式系统的工具。我们正在采用这种谷歌方式来运行软件,加上现代化的架构,令更加稳定,更加易于管理。现目前,不足的工作运行在公有云上。 showImg(https://segmentfault.com/img/bVAcRD); Mirantis, Intel和Google结成联盟,准备在Google镜像中重做OpenStack,将OpenStack...

    Aklman 评论0 收藏0
  • 老肖有话说:雾霾天带你看清Crane技术实现之路

    摘要:今天为大家介绍的容器管理工具是数人云基于最新技术的一个开源项目。今天从技术角度分享一下数人云从设计到开发的实践之路。从控制面板说起数人云是一家开源技术的公司,最初希望做一个开源项目,相当于做了一次内部创新。数人云的技术栈是,正好与十分密切。 小数表示最近雾锁京城真是有些可怕,迷迷蒙蒙让人看不清远处,大家外出也要注意防霾哦! 容器管理面板Crane,是 数人云的第一个开源项目,那...

    Alliot 评论0 收藏0
  • Docker 架构私有云的机遇和挑战

    摘要:说起,必须要介绍是什么东西,为什么中小企业私有云适合使用。看一下现在的架构图开个玩笑。上面这四点导致我们必须要统一架构,最终把整个业务系统迁移到基于的类似于的私有云的平台。 本文系 ArchSummit 大会 CODING 工程师王振威演讲实录。 showImg(https://dn-coding-net-production-pp.qbox.me/c2f81423-54b9-4a7b...

    bang590 评论0 收藏0

发表评论

0条评论

最新活动
阅读需要支付1元查看
<