Docker 监控的一点想法

目前项目内部署了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。

具体大项有:

  1. 容器的本身信息,如名称,ip、使用的镜像、启动时间、启动命令等;
  2. 容器的状态,如可先监控两个量值,running or not running (当状态变化时报警);
  3. 容器使用cpu的资源信息;
  4. 容器使用memory的资源信息;
  5. 容器的network io信息;
  6. 容器的disk信息;

2、关于监控项的获取

宿主机本身

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

  1. 拥有的全部容器的数量:

    docker ps -a -q | wc -l
    
  2. 正在运行的容器的数量:
    docker ps  -q | wc -l
    
  3. 非运行状态的容器的数量:
    docker ps -a  | grep -v ‘Up ‘  | grep -v ‘CONTAINER‘ | wc -l
    
  4. 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 中获取,相关参考:

  1. blkio.time:统计cgroup对设备的访问时间,按格式device_types:node_numbers milliseconds读取信息即可,以下类似。
  2. blkio.io_serviced:统计cgroup对特定设备的IO操作(包括read、write、sync及async)次数,格式device_types:node_numbers operation number
  3. blkio.sectors:统计cgroup对设备扇区访问次数,格式device_types:node_numbers sector_count
  4. blkio.io_service_bytes:统计cgroup对特定设备IO操作(包括read、write、sync及async)的数据量,格式device_types:node_numbers operation bytes
  5. blkio.io_queued:统计cgroup的队列中对IO操作(包括read、write、sync及async)的请求次数,格式number operation
  6. blkio.io_service_time:统计cgroup对特定设备的IO操作(包括read、write、sync及async)时间(单位为ns),格式device_types:node_numbers operation time
  7. blkio.io_merged:统计cgroup 将 BIOS 请求合并到IO操作(包括read、write、sync及async)请求的次数,格式number operation
  8. 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: <unknown>
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状态,其他状态可记录,监控值可稍后商榷。

阅读原文

时间: 2024-10-08 15:05:12

Docker 监控的一点想法的相关文章

对当前网络路由的一点想法

五一小长假,和朋友开车去了浙江,发现了"基于目的地的最短距离算法"的弊端,也许就是这个算法导致了高速公路在某个时间段的定期规律性拥堵!从嘉定出发,G1501一路畅通,但是一旦转到G60沪昆高速,瞬间拥堵起来,实际上,早在G1501上时,就有公告牌,说沪昆高速有施工,可是大家还是全部转到了沪昆高速,留下S19/G15成了被抛弃的摆设...知道原因是什么吗?很简单,因为沪昆高速那条路最近!人们太相信导航,很少有人没事研究地图,所以很多人都上了当,当然这并不包括我.很多导航都是根据Dijks

docker监控: cAdvisor

docker监控: cAdvisor 什么是 cAdvisor? cAdvisor 是 Google 开源的一款用于展示和分析容器运行状态的可视化工具,通过在主机上运行 cAdvisor 用户可以轻松的获取到当前主机上容器的运行统计信息,并以图表的形式向用户展示. 使用 cAdvisor 想运行在这个很简单,只需要执行如下命令即可 docker run --volume=/:/rootfs:ro --volume=/var/run:/var/run:rw --volume=/sys:/sys:r

关于UED前端开发的一点想法

5.2 关于UED前端开发的一点想法 5.2.1 目前UED前端代码是一个页面对应一个JS文件,更有甚者一个JS文件的代码会超过万行,这样的代码试想该如何维护?如果在从事前端开发的时候避免这种尴尬的局面,我想最好的方式就是分而治之, 如果分而治之?首先解析页面的一般思路,初始化(init) 事件绑定(event)页面读值(getData)页面写值(setData)重置页面(resetData)页面展示(setView)页面校验(checkData)页面异步加载 (ajax),页面测试(test)

多应用统一开发平台的一点想法

几年工作下来,发现有一个问题一直困扰着我们: 随着项目的越来越完善,功能越来越丰富,单一一个应用已经不能够支撑开发人员的需要.于是我们就需要根据业务分拆成几个相对独立的应用来满足多个开发团队的需求.但是这样也造成了一些问题,多个应用需要公用的基础代码维护起来越来越复杂,导致种种问题.也有很多种方式来解决,比如公共代码放置单独的地方,这样有带来的自动化部署方面的困难.在此,鄙人提出一种解决方法,即多应用统一开发平台的概念.在此以rails应用为例. 标准的rails应用结构如下: Gemfile

云智慧监控宝Docker监控功能评测

之前看到dockone社区<[实战]五个Docker监控工具的对比>(http://dockone.io/article/397)的文章,前两天也尝试了新上线的Docker监控工具监控宝.想按照文章中包含的六项指标,对监控宝做一个评价.评测项目包括: 1.部署的难易 2.信息呈现的详细度 3.部署过程中日志的聚集程度 4.告警能力 5.是否可以监控非Docker的资源 6.成本 1.部署的难易 监控宝的Docker监控部署是击中监控工具里最简单的,只需要将Docker监控采集器(SendPro

Docker运维必备:监控宝Docker监控试用手记

本文由肖远昊深度实践docker监控的报告   非常荣幸得到监控宝的邀请,试用了他们最近推出的新产品--Docker监控. 9月7日,中国APM厂商云智慧CloudWise正式发布上线Docker监控,该产品从部署到使用,整个过程都非常的简单.不仅能够实时监控宿主机和Docker容器的性能信息(包括CPU.Mem.磁盘.Net In/Out),还可以自定义相应的告警策略.以下将从部署.监控信息.告警这几个方面聊聊试用体会.大家可以[注册]监控宝,免费使用Docker监控. 部署流程 阅读了Doc

Docker 监控实战 教你如何监控 Docker 容器内部

如今,越来越多的公司开始使用 Docker 了,现在来给大家看几组数据: 2 / 3 的公司在尝试了 Docker 后最终使用了它 也就是说 Docker 的转化率达到了 67%,而转化市场也控制在 60 天内. 越大型的公司越早开始使用 Docker 研究发现主机数量越多的公司,越早开始使用 Docker.而主机数量多,在这个研究里就默认等同于是大型公司了. Docker 优势 那为什么 Docker 越来越火呢?一谈起 Docker 总是会跟着让人联想到轻量这个词,甚至会有一种通过 Dock

Installshield关于.NET安装时需要重启动的处理办法,以及延伸出的重启后继续安装的安装包的一点想法

原文:Installshield关于.NET安装时需要重启动的处理办法,以及延伸出的重启后继续安装的安装包的一点想法 很多朋友做安装包的时候,所打包的软件需要.NET Framework之类的环境,他们会检测系统是否已经安装了.NET,如果没有,则调用.NET安装包来安装.但是.NET安装完是需要重启动的,一般来说,我们都推荐使用/q/norestart的静默安装函数来使重启动推迟到安装结束时,使用如下:LaunchAppAndWait(SUPPORTDIR^"dotNetFx40_Full_x

关于标签系统的又一点想法。

前段时间,写过一篇<关于标签系统的一点想法.>.但其实没有谈到里面的内容,是有一部分来自与刘鑫老师的聊天,当时他给了我许多肯定,也是让我觉得记录下来很有必要的原因. 前一篇里没有提到,我跟刘老师谈到一个更加深入一点的.关于标签系统的想法.主要原因是因为我尚不肯定这是否也属于标签系统.直到最近disylee 送了一本标签 : 标记系统设计实践给我,里面的一个小节让我为自己的想法找到了理论依据. 很不错的一本书,没有让我失望,解答了我心中的一些困惑.书有点啰嗦,但也正因为此显得"系统&q