解惑|你是否为容器监控操碎了心？

时间 2019-12-05

标签解惑是否容器监控碎了繁體版

原文原文链接

导读：容器对于物理机和虚拟机，单从监控上看就不是一个数量级的，但监控又是相当重要的，没有监控如同闭眼开车。git

本次分享邀请数人云运维总监庞铮，本文将从如下几个方面聊聊容器监控的相关思考：github

容器监控面临问题-容器设计及运营复杂性的挑战；docker
容器的三种监控收集指标；数据库
容器性能监控能力把控及报警调查。centos

容器监控的问题

为何要使用Dockerapi

须要一个可靠可扩展的基础设施平台缓存
大量的流量和用户安全
大量的内部服务服务器
不须要改造基础设施：负载均衡、HTTP服务、日志系统、数据库、监控系统等网络
抽象标准基础设施服务，如 HaproxyMongodbEs等
提供快速的更新部署能力

简介

容器对于物理机和虚拟机，单从监控上看就不是一个数量级的。可是监控又是相当重要的，若是没有监控，如同闭着眼开车。先看下传统监控解决的问题：

对于应用层：应用层的性能监控将找到代码的瓶颈和错误。
对于基础设施：收集基础设施层的资源指标，如CPUMEM。

而使用容器则在于资源层和应用层之间，应用监控和基础设施监控没法起做用，形成了监控系统的盲点。

容器的设计

原始初衷：安全

容器最开始设计就是为了提供运行时的安全隔离，且没有虚拟化的资源开销。容器提供了一种孤立运行软件的方法，既不是进程也不是主机，而存在于二者之间。

如今

如今使用容器主要有两个重要缘由：

提供了一个规模的标准

若是软件是微服务架构，在 KubernetesMesos 等容器平台上进行无停机的扩缩和升级等系统操做。

摆脱对于软件系统的依赖

一直以来使用 Lib直接编译成二进制可执行文件是最好的，但 Lib 的增长，为了不内存的过分消耗，致使运行时共享 Lib 的出现。为了解决软件依赖的问题，建立了不少方法如：Apt、Yum、Rvm、V1irtualenv 等，但这会致使拖慢发布周期，而容器直接解决了这个问题。

容器挑战：运营的巨大复杂性

能够将每一个容器当作一个迷你的主机，但它与主机的操做并非很相同。

上图显示了15年的系统演进过程。

15年前仍是主机天下。
7年前引进虚拟化技术，而虚拟化技术带来的是更好的资源利用率，但对于工程师来讲没有什么变化。
而今天 Datadog 的数据显示从收到了数十万的主机数据中，愈来愈多的主机开始运行容器。
2016年开始使用 Docker 的用户增加率为 40%。

运行容器实例主机占总主机数量的 15%。

大型企业使用容器的用户更多（超过500台主机集群）占 60%，另外一方面说明了容器对于规模性和摆脱软件依赖的对于大型企业的用处更高，数人云的核心业务是帮客户把已有的系统容器化，再将其应用搬到调度系统上，以及开发一些周边系统，接触的客户也反映了这一点。

有 40% 的用户将容器运行在相似 Mesos 和 Kubernetes 等容器集群软件中。

使用容器用户中在第一个月到第十个月的九个月中，容器数量增加了 5 倍，而且数据很是线性。

运行应用统计比例。

在使用容器的公司中，每一个主机运行容器实例为 7 个左右，而 25% 的公司每一个主机运行容器实例为14个左右。
容器的生命周期为 2.5 天，在自动化平台的更短为不到 1 天，主要由于自动修复缘由，而非自动平台则 5.5 天。

监控的爆炸性增加

在没有容器之前，监控数量如：

使用容器后公式：假设每一个容器收集 50 个度量，再加上应用收集 50 个度量。

系统监控   （容器数量*（容器监控 应用监控））= 每一个主机监控数量100         （4 *（50 50））= 500/主机监控项

以主机为中心的监控体系

容器做为主机，以主机为中心将有两个问题没法解决：

容器做为主机，由于容器生命周期很是短暂，因此监控系统会认为一半主机在频发故障。
若是不监控容器，那么从主机到应用之间的监控是空白的，产生监控黑洞。

简化监控体系

如图采用分层监控架构，更符合现有监控体系。主机层和应用层保持不变使用传统的 Apm 和主机层监控，而容器层使用新的监控模式。

如何监控容器

容器相似主机

它有一个迷你主机该有的一切，包含常驻程序、CPU、MEM、IO 和网络资源。但容器不能报告和主机彻底相同的 Cgroup 指标。

容器监控资源

cpu

容器 CPU 会给出如下数据而不会有和主机同样的全数据，如 IdleIowaitIrq。

内存

使用内存区别

属于进程的数据，如 Stacks、Heaps 等。能够被进一步分解为

活动内存（active_anon）
非活动内存（inactive_anon）

必要时，非活动内存能够被交换到磁盘

cache

缓存存储器存储当前保存在内存中的磁盘数据。能够进一步分解为

活动内存（active_file）
非活动内存（inactive_file）

必要时，首先回收非活动内存

swap 使用量

容器对于每一个块设别汇报4个指标，这种状况下，在主机监控层面跟踪主机队列和服务时间是个好办法，若是同块的队列和服务时间增加，那么因同块 IO 是共享的，因此容器 IO 也受到影响。

读取
写入
同步
异步

网络

和普通主机同样，分为接收和发送的多个度量数据。

如何收集容器指标

容器有三种指标收集方法，但标准并不同：

Sysfs 中的 Pseudo-files

默认状况下，经过Sysfs中的伪文件能够获得容器的度量指标，且不须要 Root 权限。这个方法是最快最清亮的方法。若是须要监控不少主机，速度多是一个很重要的指标。但没法用这个方法收集到全部指标，如 IO 和网络指标会受到限制。

收集位置

假定伪文件在操做系统目录中的 /sys/fs/cgroup 中，某些系统可能在 /cgroup 中。访问路径包含容器ID。

CONTAINER_ID=$(docker run [OPTIONS] IMAGE [COMMAND] [ARG...] )

CPU 获取方法

cd /sys/fs/cgroupu/docker/&& ll

-rw-r--r-- 1 root root 0 5月  31 10:17 cgroup.clone_children
  --w--w--w- 1 root root 0 5月  31 10:17 cgroup.event_control
  -rw-r--r-- 1 root root 0 5月  31 10:17 cgroup.procs
  -r--r--r-- 1 root root 0 5月  31 10:17 cpuacct.stat
  -rw-r--r-- 1 root root 0 5月  31 10:17 cpuacct.usage
  -r--r--r-- 1 root root 0 5月  31 10:17 cpuacct.usage_percpu
  -rw-r--r-- 1 root root 0 5月  31 10:17 cpu.cfs_period_us
  -rw-r--r-- 1 root root 0 5月  31 10:17 cpu.cfs_quota_us
  -rw-r--r-- 1 root root 0 5月  31 10:17 cpu.rt_period_us
  -rw-r--r-- 1 root root 0 5月  31 10:17 cpu.rt_runtime_us
  -rw-r--r-- 1 root root 0 5月  31 10:17 cpu.shares
  -r--r--r-- 1 root root 0 5月  31 10:17 cpu.stat
  -rw-r--r-- 1 root root 0 5月  31 10:17 notify_on_release
  -rw-r--r-- 1 root root 0 5月  31 10:17 tasks

CPU 使用（单位是10毫秒）

# cat $CONTAINER_ID/cpuacct.stat     user 46409 #进程占用  464.09s     system 22162 #系统调用占用 221.62s

CPU 每核使用量

能够帮助识别每一个核心的压力

# cat $CONTAINER_ID/cpuacct.usage_percpu         362316789800  #自启动以来占用，单位纳秒         360108180815

若是想要获得对于服务器汇总的cpu指标

# cat $CONTAINER_ID/cpuacct.usage
    722473378982

CPU 节流
若是对 CPU 使用作了限制，能够从下面的方法中查看

$ cat /sys/fs/cgroup/cpu/docker/$CONTAINER_ID/cpu.stat
    nr_periods 565 # 已经执行间隔数
    nr_throttled 559 # 被组抑制的次数
    throttled_time 12119585961 # 总使用时间，单位纳秒(12.12s)

内存获取方法

ll /sys/fs/cgroup/memory/docker/$CONTAINER_ID/
  
  # 没有 total 标签，不包含于子cgroup组
  cache 2015232
  rss 15654912
  rss_huge 0
  mapped_file 131072
  swap 0
  pgpgin 22623
  pgpgout 18309
  pgfault 27855
  pgmajfault 7
  inactive_anon 12148736
  active_anon 3506176
  inactive_file 2011136
  active_file 4096
  unevictable 0
  hierarchical_memory_limit 9223372036854775807
  hierarchical_memsw_limit 9223372036854775807
  
  # 有 total 标签，包含于子cgroup组
  total_cache 2015232
  total_rss 15654912
  total_rss_huge 0
  total_mapped_file 131072
  total_swap 0
  total_pgpgin 22623
  total_pgpgout 18309
  total_pgfault 27855
  total_pgmajfault 7
  total_inactive_anon 12148736
  total_active_anon 3506176
  total_inactive_file 2011136
  total_active_file 4096
  total_unevictable 0

能够经过特定命令直接获取一些指标：

# 总物理内存占用 cached + rss ，单位为字节 
  $ cat /sys/fs/cgroup/memory/docker/$CONTAINER_ID/memory.usage_in_bytes

  # 总物理内存+swap 占用 ，单位为字节 
  $ cat /sys/fs/cgroup/memory/docker/$CONTAINER_ID/memory.memsw.usage_in_bytes

  # 内存使用次数限制
  $ cat /sys/fs/cgroup/memory/docker/$CONTAINER_ID/memory.failcnt

  # cgroup 内存限制，单位为字节 
  $ cat /sys/fs/cgroup/memory/docker/$CONTAINER_ID/memory.limit_in_bytes
  注意若是最终返回的是一个很长的数值表明容器实例并无限制，若是想增长限制
  $ docker run -m 500M IMAGE [COMMAND] [ARG...]

ll /sys/fs/cgroup/blkio/docker/$CONTAINER_ID
  
  -r--r--r-- 1 root root 0 5月  31 10:17 blkio.io_merged
  -r--r--r-- 1 root root 0 5月  31 10:17 blkio.io_merged_recursive
  -r--r--r-- 1 root root 0 5月  31 10:17 blkio.io_queued
  -r--r--r-- 1 root root 0 5月  31 10:17 blkio.io_queued_recursive
  -r--r--r-- 1 root root 0 5月  31 10:17 blkio.io_service_bytes
  -r--r--r-- 1 root root 0 5月  31 10:17 blkio.io_service_bytes_recursive
  -r--r--r-- 1 root root 0 5月  31 10:17 blkio.io_serviced
  -r--r--r-- 1 root root 0 5月  31 10:17 blkio.io_serviced_recursive
  -r--r--r-- 1 root root 0 5月  31 10:17 blkio.io_service_time
  -r--r--r-- 1 root root 0 5月  31 10:17 blkio.io_service_time_recursive
  -r--r--r-- 1 root root 0 5月  31 10:17 blkio.io_wait_time
  -r--r--r-- 1 root root 0 5月  31 10:17 blkio.io_wait_time_recursive
  -rw-r--r-- 1 root root 0 5月  31 10:17 blkio.leaf_weight
  -rw-r--r-- 1 root root 0 5月  31 10:17 blkio.leaf_weight_device
  --w------- 1 root root 0 5月  31 10:17 blkio.reset_stats
  -r--r--r-- 1 root root 0 5月  31 10:17 blkio.sectors
  -r--r--r-- 1 root root 0 5月  31 10:17 blkio.sectors_recursive
  -r--r--r-- 1 root root 0 5月  31 10:17 blkio.throttle.io_service_bytes
  -r--r--r-- 1 root root 0 5月  31 10:17 blkio.throttle.io_serviced
  -rw-r--r-- 1 root root 0 5月  31 10:17 blkio.throttle.read_bps_device
  -rw-r--r-- 1 root root 0 5月  31 10:17 blkio.throttle.read_iops_device
  -rw-r--r-- 1 root root 0 5月  31 10:17 blkio.throttle.write_bps_device
  -rw-r--r-- 1 root root 0 5月  31 10:17 blkio.throttle.write_iops_device
  -r--r--r-- 1 root root 0 5月  31 10:17 blkio.time
  -r--r--r-- 1 root root 0 5月  31 10:17 blkio.time_recursive
  -rw-r--r-- 1 root root 0 5月  31 10:17 blkio.weight
  -rw-r--r-- 1 root root 0 5月  31 10:17 blkio.weight_device
  -rw-r--r-- 1 root root 0 5月  31 10:17 cgroup.clone_children
  --w--w--w- 1 root root 0 5月  31 10:17 cgroup.event_control
  -rw-r--r-- 1 root root 0 5月  31 10:17 cgroup.procs
  -rw-r--r-- 1 root root 0 5月  31 10:17 notify_on_release
  -rw-r--r-- 1 root root 0 5月  31 10:17 tasks

根据系统不一样可能会有更多的指标文件，然而大部分的文件返回值是零。这种状况下一般还有两个能够工做的文件。

blkio.throttle.io_service_bytes #io 操做字节，实际操做而非限制，前面两个用冒号分割的数字是-主设备id:次要设备Id。

8:0 Read 2080768
  8:0 Write 0
  8:0 Sync 0
  8:0 Async 2080768
  8:0 Total 2080768
  253:0 Read 2080768
  253:0 Write 0
  253:0 Sync 0
  253:0 Async 2080768
  253:0 Total 2080768
  Total 4161536

blkio.throttle.io_serviced #io 操做次数，实际操做而非限制。

8:0 Read 226
  8:0 Write 0
  8:0 Sync 0
  8:0 Async 226
  8:0 Total 226
  253:0 Read 226
  253:0 Write 0
  253:0 Sync 0
  253:0 Async 226
  253:0 Total 226
  Total 452

想查看设备之间的关系可使用：

# lsblk
  NAME            MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
  sda               8:0    0   50G  0 disk
  ├─sda1            8:1    0  500M  0 part /boot
  ├─sda2            8:2    0 29.5G  0 part
  │ ├─centos-root 253:0    0 46.5G  0 lvm  /
  │ └─centos-swap 253:1    0    3G  0 lvm  [SWAP]
  └─sda3            8:3    0   20G  0 part
       └─centos-root 253:0    0 46.5G  0 lvm  /

网络

网络从 1.6.1版本之后才支持，和以上的路径有所不一样，获取使用容器Pid获取，注意Host模式获取的是主机网络数据，因此 host 模式没法从容器数据统计网络数据。

$ CONTAINER_PID=`docker inspect -f '{{ .State.Pid }}' $CONTAINER_ID`
  $ cat /proc/$CONTAINER_PID/net/dev 
  
  Inter-|   Receive                                                |  Transmit
  face |bytes    packets errs drop fifo frame compressed multicast|bytes    packets errs drop fifo colls carrier compressed
  eth0:    9655      90    0    0    0     0          0         0    31435      78    0    0    0     0       0          0
  lo:       0       0    0    0    0     0          0         0        0       0    0    0    0     0       0          0

cli 的 stats

使用 docker stats 会不断的接收监控指标，1.9.0 之后指标包含磁盘io

cpu stats

cpu 占用百分比，多个实例占用cpu会根据分配进行占用峰值，若是设定强制规约，那么cpu只能占设定的数值，好比20%

内存 stats

若是没有明确内存限制，则限制为主机内存限制。若是主机上还有其余使用内存进程，那么会在到达限制前耗尽内存。

io stats

1.9.0 版本后支持，显示总读写字节

网络 stats

显示总进/出流量字节

和 docker stats 命令同样，可是提供更多的细节。守护进程监听 unix:///var/run/docker.sock，只容许本地链接。使用 nc 调用方法：

echo "" | nc -U /var/run/docker.sock 例子 echo -ne "GET /containers/$CONTAINER_ID/stats HTTP/1.1\r\n\r\n" | sudo nc -U /var/run/docker.sock

如何监控Docker的性能

监控都须要有什么能力

从每一个 Docker 容器收集CPU、内存、IO、网络指标，并能够经过人和标签或者标签聚合作成指标，用来提供高分辨率资源指标。
微服务体系结构中，服务能够直接通信或者使用队列进行通信，没有中央负载均衡很难进行计量，经过标签聚合能力能够很好的解决这个问题。
须要经过图形得之哪些服务超载，哪些服务致使其余服务失败，哪些服务流量太多
还能够监控其余非 Docker 服务，如 Haproxy、MongoDB、Es等等。

报警和调查

内部网络流量变化做为最重要的指标来触发报警而不会引发报警洪水。所以聚合和分解服务级别流量可见性是相当重要的。此外，即便在测量交叉异常阀值前，报警系统也能够提醒网络流量变化。而其他的资源指标是用来调查排错的。

数人云容器监控实践

参考

The Docker monitoring problem

datadog

Runtime metrics

QA

Q：有对Docker自己作什么监控么？

A：能够认为 Docker 监控是类主机监控，只不过是缩小版，基本上分为4部分：CPU、内存、磁盘、网络。

Q：使用的整套监控工具是哪些？容器CPU内存网络如何监控？容器事件好比起停如何监控。

A：整套工具数人云使用的是Cadvisor + Prometheus + Grafana ,固然中间的组件是能够替换的，但基本上围绕着采集、存储计算、展示来作。采集也可使用本身的，好比文章说的本身写代理去拿。容器的监控数据固然靠采集程序了。起停这个通常经过监控Docker的事件来实现，采集工具也能收。

Q：分享的监控图片，有数据的，是使用什么监控工具达成的？

A：这个分两种，一种是靠底层的绘图引擎，将数据从存储里读出来本身绘制，一种就是用类Grafana的程序。

Q：若是用Zabbix监控，是否须要定义容器的的历史数据保留时间和趋势数据存储周期，我设定的时历史数据保留7天，趋势数据14天，这样是否合理？

A：我认为Zabbix 是上一代监控体系，或者以主机为中心的监控体系，若是是容器监控，建议仍是考虑时序类的监控体系，好比InfluxdbPrometheus等，Zabbix还能够沿用做为主机的，只是Docker单独分离出来，这样基础建设能够复用。

Q：建不建议经过Pod中放一个监控容器来监控应用容器，好比Zabbix客户端的监控容器在Pod中，若是这么作优缺点哪些？

A：Pod应该是Kubernetes的概念，和容器其实关系不大，这个Kubernetes本身应该会提供数据，具体不是很清楚。可是Abbix仍是建议保留在主机层面使用，除非大改，不然即便靠拆分数据库什么的解决，将来维护和性能也是运维大坑。

Q：Cadvisor Heapster 和 Prometheus 哪一种好用一些，各自优缺点有哪些。

A: Heapster不熟悉， Prometheus很好，Google我的的开源项目，都是Google套路，惟独存储是个问题，这块还须要看他们将来如何处理，如今单机存储虽然性能上还能够，可是扩展能力比较差。

Q：监控工具推荐哪一个？对于容器生命周期短，有何策略应对？如何实现快速监控策略？

A：监控工具推荐刚才已经说了，能够参考数人云的方案而后本身摸索出适合本身的。至于容器生命周期短的问题，这个不就是容器设计嘛，很正常，多起几个相同的服务顶上。

Q：容器的一大特色是IP或者ID信息变化频繁，这就会致使时间序列数据库存储的监控数据量增加和vm相比大上很多，这块有什么应对方案吗？尝试过固定ID的，可是效果不佳。

A：这块确实没有什么好办法，不过能够换个角度，能够将底层的实例抽象一个维度，好比起了1个服务10个容器，把容器编号0-9，对应挂掉的容器，新启动继承这个编号。从时序上用这个做为标记，就能看比较直观的显示了。此功能数人云Swan （欢迎Star&Fork）实现了，能够考虑。

Q：容器的安全如何作监控？

A：这个问题问的好，如今比较通用的监控基本上走的是两条路，一个是监控性能，一个是监控业务，安全层面监控，到如今我以为仍是要靠网络层来监控比较靠谱。

Q：Docker启动Kafka集群的问题，有没有控制内存方面的经验呢？

A：Kafka集群，性能监控的话，能够沿用原来的Kafka集群监控软件，固然若是想作数据汇聚，也可使用开源软件将数据汇聚到一个数据存储，而后在汇聚出来。关于Docker内存的超出被杀问题，这个主要是看自身对于容器内存设置的容忍度问题，这里能够把容器当成一个机器，看到底给这个机器插多少内存合适。

Q：Promethues有没有作高可用？

A：若是存储高可用的话，能够考虑使用两台Prometheus同时抓，这样数据彻底同样，也没啥压力。

分享人庞铮，数人云运维总监。15 年以上运维工做经验。就任过宏碁戏谷、第三波、SQUARE ENIX CO, LTD 等。2015年加入数人云，从事数人云平台运维管理，在容器技术及SRE实践方面有深刻研究。