容器如何做监控?

2018阿里云全部产品优惠券(好东东,强烈推荐)
领取地址https://promotion.aliyun.com/ntms/act/ambassador/sharetouser.html?userCode=gh9qh5ki&utm_source=gh9qh5ki

推荐:使用Istio监控基于容器的服务

[使用Istio监控基于容器的服务]

容器监控

容器监控的问题

为什么要使用 Docker

- 需要一个可靠可扩展的基础设施平台

- 大量的流量和用户

- 大量的内部服务

- 不需要改造基础设施:负载均衡、 HTTP服务、日志系统、数据库、监控系统等

- 抽象标准基础设施服务,如 Haproxy\Mongodb\Es等

- 提供快速的更新\部署能力

简介

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

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

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

容器的设计

- 原始初衷:安全

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

  • 现在

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

    • 提供了一个规模的标准
      如果软件是微服务架构,在 K8s\Mesos 等容器平台上进行无停机的扩缩和升级等系统操作。
    • 摆脱对于软件系统的依赖
      一直以来使用 Lib 直接编译成二进制可执行文件是最好的,但 Lib 的增加,为了避免内存的过度消耗,导致运行时共享 Lib 的出现。为了解决软件依赖的问题,创建了很多方法如:Apt, Yum, Rvm, V1irtualenv 等,但这会导致拖慢发布周期,而容器直接解决了这个问题。

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

可以将每个容器看成一个迷你的主机,但它与主机的操作并不是很相同。

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

  • 15年前还是主机天下
  • 7年前引进虚拟化技术,而虚拟化技术带来的是更好的资源利用率,但对于工程师来说没有什么变化。
  • 而今天 Datadog 的数据显示从收到了数十万的主机数据中,越来越多的主机开始运行容器
  • 2016年开始使用 Docker 的用户增长率为 40%
  • 运行容器实例主机占总主机数量的 15%
  • 大型企业使用容器的用户更多(超过500台主机集群)占 60%,另一方面说明了容器对于规模性和摆脱软件依赖的对于大型企业的用处更高,数人云的客户也反映了这一点。
  • 有 40% 的用户将容器运行在类似 Mesos 和 K8s 等容器集群软件中
  • 使用容器用户中在第一个月到第十个月的九个月中,容器数量增长了5倍,并且数据非常线性。
  • 运行应用统计比例
  • 在使用容器的公司中,每个主机运行容器实例为7个左右,而25%的公司每个主机运行容器实例为14个左右
  • 容器的生命周期为 2.5 天,在自动化平台的更短为不到1天,主要因为自动修复原因,而非自动平台则 5.5 天

监控的爆炸性增长

- 在没有容器以前,监控数量如

组成 | 监控数量

:-----------: | :-----------:

系统|100

组件| 50

总数|150

  • 使用容器后公式

    假设每个容器收集 50 个度量,再加上应用收集 50 个度量

系统监控   (容器数量*(容器监控 应用监控)) = 每个主机监控数量

    100  (4*(50 50)) = 500/主机监控项    

已主机为中心的监控体系

容器作为主机,以主机为中心将有两个问题无法解决

  • 容器作为主机,因为容器生命周期非常短暂,所以监控系统会认为一半主机在频发故障。
  • 如果不监控容器,那么从主机到应用之间的监控是空白的,产生监控黑洞

简化监控体系

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

对应监控项目 | 使用监控工具 | 监控解决问题

:-----------: | :-----------: | :-----------:

应用| 监控系统 Apm | 应用性能

容器| 容器监控系统 | 容器的文件系统\Mem\Cpu\应用请求数等

物理层| 传统监控系统 | 物理 Cpu \Mem \Io \Net 等

如何监控容器

容器类似主机

它有一个迷你主机该有的一切,包含常驻程序、Cpu、Mem、Io 和网络资源。但容器不能报告和主机完全相同的 Cgroup 指标。

容器监控资源

- Cpu

容器 Cpu 会给出以下数据而不会有和主机一样的全数据,如 Idle\Iowait\Irq

名称| 描述 | 指标类型

:-----------: | :-----------: | :-----------:

User Cpu |进程直接使用 Cpu 的时间百分比| 资源利用率(标准指标)

System Cpu | 进程执行系统调用的百分比| 资源利用率(标准指标)

Throttling (Count) | Cpu 限制执行资源的数量 | 资源饱和度(被分配的份额)

Throttling (Time) | Cpu 限制的总时间资源 |资源饱和度 (被分配的份额)

  • 内存
    名称| 描述 | 指标类型
    :-----------: | :-----------: | :-----------:
    Memory |一个实例使用的内存 | 资源利用率(标准指标)
    RSS| 进程非缓存内存,如 Stacks, Heaps| 资源利用率(标准指标)
    Cache Memory|磁盘的数据缓存|资源利用率(标准指标)
    Swap|交换空间使用量|资源饱和度
  • 使用内存区别
    • Rss
      属于进程的数据,如 Stacks, Heaps 等。可以被进一步分解为
      • 活动内存(active_anon)
      • 非活动内存(inactive_anon)
        必要时,非活动内存可以被交换到磁盘
      • Cache
        缓存存储器存储当前保存在内存中的磁盘数据。可以进一步分解为
      • 活动内存(active_file)
      • 非活动内存(inactive_file)
        必要时,首先回收非活动内存
    • Swap 使用量
  • Io
    名称| 描述 | 指标类型
    :-----------: | :-----------: | :-----------:
    I/O Serviced | 一个Io 的执行计数器,不管大小 | 资源利用率(标准指标)
    I/O Service Bytes | Cgroup 读写字节数 | 资源利用率(标准指标)
    容器对于每个块设别汇报4个指标,这种情况下,在主机监控层面跟踪主机队列和服务时间是个好办法,如果同块的队列和服务时间增长,那么因同块 Io 是共享的,所以容器Io也受到影响
    • 读取
    • 写入
    • 同步
    • 异步
  • 网络
    和普通主机一样,分为接收和发送的多个度量数据
    名称| 描述 | 指标类型
    :-----------: | :-----------: | :-----------:
    -Bystes | 网络流量发送和接收字节大小 | 资源利用率(标准指标)
    -Packets| 网络封包发送和接收计数器 | 资源利用率(标准指标)
    -Errors (Receive) | 接收包错误率 | 资源错误信息
    -Errors (Transmit) | 错误包率 | 资源错误信息
    -Dropped | 接收发送丢包数量 | 资源错误信息

如何收集容器指标

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

  • 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 操作次数,实际操作而非限制

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

推荐:使用 Prometheus 监控 Docker 容器

[本文的原作者是 johannes-fish-ziemke,原文地址是 http://5pi.de/2015/01/26/monitor-docker-containers-with-prometheus/ 该文中介绍的 Prometheus 的项目地址是 https:

  • 网络

    网络从 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

指标获取方法 | Cpu | 内存 | Io | 网络

:-----------: | :-----------: | :-----------:| :-----------:| :-----------:

Pseudo-files | 全 | 全 | 一些 | 1.6.1 版本后,全

Stats | 基础 | 基础 | 1.9.0 版本后,一些 | 基础

Api | 全 | 全 | 一些 | 全

如何监控 Docker 性能

监控都需要有什么能力

- 从每个 Docker 容器收集 Cpu、内存、Io、网络指标,并可以通过人和标签或者标签聚合做成指标,用来提供高分辨率资源指标。

- 微服务体系结构中,服务可以直接通讯或者使用队列进行通讯,没有中央负载均衡很难进行计量,通过标签聚合能力可以很好的解决这个问题。

- 需要通过图形得之哪些服务超载,哪些服务导致其他服务失败,哪些服务流量太多

- 还可以监控其他非 Docker 服务,如 Haproxy、Mangodb、Es等等

报警和调查

内部网络流量变化作为最重要的指标来触发报警而不会引起报警洪水。因此聚合和分解服务级别流量可见性是至关重要的。此外,即使在测量交叉异常阀值前,报警系统也可以提醒网络流量变化。而其余的资源指标是用来调查排错的。

参考

- The Docker monitoring problem

- datadog

- Runtime metrics

问题

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

Q:Kubernetes的各个组件 如何监控?

A:K8s 真心不熟,但是我知道K8S的组件分为容器和非容器部署,所以容器的话可以套用之前说的容器监控方案,非容器的话不是很好办资源走主机吧。这里还有个服务运行状态数据,我们使用的是CONSUL觉得很好用。

Q:做容器监控 和Jvm监控是否有什么工具可以推荐,感谢。

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

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

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

Q:请问如何监控网络带宽,并对带宽进行限制?

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

Q:如果用Prometheus做监控的话应该要做基于主机,Containers以及Service的监控嘛,如果监控的比较多的话,会不会对本身的Performance有影响。谢谢!

A:Prometheus 基于主机这个话我不是很明白,如果你说Prometheus 性能基于主机的话,这个刚才已经说过了确实是。性能上,可以考虑分布式部署,比如按服务拆分监控。

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

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

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

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

Q:你好,你们有没有针对磁盘使用率的监控,Docker Stats好像没有针对这块的监控,谢谢。

A:容器磁盘使用率吗?因为我们使用的是Overlay存储,所以这个参数暂时不是很关注,只关注主机层面的。

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

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

Q:容器的安全如何做监控?

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

Q:Heapster通过什么方式收集CAdvisor收集的监控信息?Heapster通过什么标准选择部署在的Node?

A:这个之前回答过,确实没关注,经历都在Prometheus和Cadvisor的BUG上。

Q:Docker 启动Kafka 集群的问题,有没有控制 内存方面的经验呢?

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

Q:Promethues有没有做高可用?

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

推荐:每日一博 | 如何搭建一个 Docker 容器可视化监控中心

[概述 一个宿主机上可以运行多个容器化应用,容器化应用运行于宿主机上,我们需要知道该容器的运行情况,包括 CPU使用率、内存占用、网络状况以及磁盘空间等等一系列信息,

在线网页数据采集器

相关推荐