本次分享将从以下几个方面聊聊容器监控的相关思考：

  1. 容器监控面临问题-容器设计及运营复杂性的挑战；
  2. 容器的三种监控收集指标；
  3. 容器性能监控能力把控及报警调查。

为什么要使用 Docker

  • 需要一个可靠可扩展的基础设施平台
  • 大量的流量和用户
  • 大量的内部服务
  • 不需要改造基础设施：负载均衡、HTTP服务、日志系统、数据库、监控系统等
  • 抽象标准基础设施服务，如 Haproxy\Mongodb\Es等
  • 提供快速的更新\部署能力

简介

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

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

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

容器的设计

原始初衷：安全

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

现在

现在使用容器主要有两个重要原因：

  • 提供了一个规模的标准 如果软件是微服务架构，在 Kubernetes\Mesos 等容器平台上进行无停机的扩缩和升级等系统操作。
  • 摆脱对于软件系统的依赖 一直以来使用 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 会给出以下数据而不会有和主机一样的全数据，如 Idle\Iowait\Irq。

内存

  • 使用内存区别
  • rss 属于进程的数据，如 Stacks、Heaps 等。可以被进一步分解为
  • 活动内存（active_anon）
  • 非活动内存（inactive_anon） 必要时，非活动内存可以被交换到磁盘
  • cache 缓存存储器存储当前保存在内存中的磁盘数据。可以进一步分解为
  • 活动内存（active_file）
  • 非活动内存（inactive_file） 必要时，首先回收非活动内存
  • swap 使用量

io

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

  • 读取
  • 写入
  • 同步
  • 异步

网络

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

如何收集容器指标

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

  • Sysfs 中的 Pseudo-files  默认情况下，通过Sysfs中的伪文件可以得到容器的度量指标，且不需要 Root 权限。这个方法是最快最清亮的方法。如果需要监控很多主机，速度可能是一个很重要的指标。但无法用这个方法收集到所有指标，如 IO 和网络指标会受到限制。
  • 收集位置 假定伪文件在操作系统目录中的 /sys/fs/cgroup 中，某些系统可能在 /cgroup 中。访问路径包含容器ID。CONTAINER_ID=$(docker run [OPTIONS] IMAGE [COMMAND] [ARG...] )

CPU 获取方法

  • 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) 

可以通过特定命令直接获取一些指标：

IO

根据系统不同可能会有更多的指标文件，然而大部分的文件返回值是零。这种情况下通常还有两个可以工作的文件。

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

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

  • 网络 网络从 1.6.1版本以后才支持，和以上的路径有所不同，获取使用容器Pid获取，注意Host模式获取的是主机网络数据，所以 host 模式无法从容器数据统计网络数据。
  • cli 的 stats 使用 docker stats 会不断的接收监控指标，1.9.0 以后指标包含磁盘io
  • cpu stats cpu 占用百分比，多个实例占用cpu会根据分配进行占用峰值，如果设定强制规约，那么cpu只能占设定的数值，比如20%
  • 内存 stats 如果没有明确内存限制，则限制为主机内存限制。如果主机上还有其他使用内存进程，那么会在到达限制前耗尽内存。
  • io stats 1.9.0 版本后支持，显示总读写字节
  • 网络 stats 显示总进/出流量字节
  • api 和 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

Q&A

Q：有对Docker本身做什么监控么？

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

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

A：整套工具我们使用的是 Cadvisor + Prometheus + Grafana ,当然中间的组件是可以替换的，但基本上围绕着 采集、存储计算、展现来做。采集也可以使用自己的，比如文章说的自己写代理去拿。容器的监控数据当然靠采集程序了。起停这个一般通过监控Docker的事件来实现，采集工具也能收。

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

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

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

A：我认为Zabbix 是上一代监控体系，或者以主机为中心的监控体系，如果是容器监控，我建议还是考虑时序类的监控体系，比如Influxdb\Prometheus等，继续刚才的，Zabbix 还可以沿用作为主机的，只是Docker单独分离出来，这样基础建设可以复用。

Q：建不建议通过 Pod中放一个监控容器来监控应用容器，比如Zabbix客户端的监控容器在Pod中，如果这么做 优缺点哪些？

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

Q：做容器监控和JVM监控是否有什么工具可以推荐，感谢。

A：容器监控现在自己玩套路都是跟着开源走，可以考虑刚才我们的套路，不过可以中间组件任意换，比如存储InfluxDB，JVM，我已知道没有什么好的套路，基本上走跟实例的路子，就是做个小程序跟着程序走，然后提供统一接口用软件抓。

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

A: Heapster 不熟悉， Prometheus 很好，Google 个人的开源项目，都是Google套路，唯独存储是个问题，这块还需要看他们未来如何处理，现在单机存储虽然性能上还可以，但是扩展能力比较差。

Q：请问如何监控网络带宽，并对带宽进行限制？

A：带宽监控可以按照容器提供的数据走，还是很准的，具体限制这个是另一个纬度了，属于容器网络，这个坑比较大不适合今天讨论。

Q：Docker多套环境使用的域名要相同还是不同？如果相同的话如何隔离，如果不同的话如何维护配置？

A：这个设计到容器服务的网络规划问题，看网络选择。隔离也看网络选型。和之前说的一样这个属于容器网络。坑大。

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

A：监控工具推荐刚才已经说了，可以参考我们的方案然后自己摸索出适合自己的。至于容器生命周期短的问题，这个不就是容器设计嘛，很正常，多起几个相同的服务顶上。容器快速后是什么?

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

A：这块确实没有什么好办法，不过可以换个角度，你可以将底层的实例抽象一个纬度，比如起了1个服务10个容器，你可以吧容器编号0-9，对应挂掉的容器，新启动继承这个编号。这样从时序上用这个作为标记，这样你就能看比较直观的显示了。这个功能我们SWAN实现了，可以考虑。

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

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

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

A：Kafka 集群，性能监控的话，可以沿用原来的 Kafka 集群监控软件，这个我记得原来有一个什么来着，当然如果想做数据汇聚，也可以使用开源软件将数据汇聚到一个数据存储，然后在汇聚出来。关于Docker内存的超出被杀问题，这个主要是看你对于容器内存设置的容忍度问题，这里你大可以把容器当成一个机器，看到底给这个机器插多少内存合适。

Q：Promethues有没有做高可用？

A：如果存储高可用的话，可以考虑使用两台Prometheus同时抓，这样数据完全一样，也没啥压力。

本文作者：庞铮