β

Docker集群性能数据监控与简单选型

衔山的博客 3013 阅读

Docker要在生产环境上使用,监控工具必不可少。传统物理机或着虚拟机通常可以通过部署一些agent收集数据,上报到中心节点进行数据聚合和存储,再通过一些UI工具进行可视化展现。与之相比,容器因为它的轻量级特性,一个容器内部通常只包含一个服务进程,通过在容器内部部署额外的性能数据采集agent非常不优雅;另一个原因,top、free、sysstat等常用性能诊断命令在容器中往往拿到的是宿主机的数据,无法准确获取容器数据。因此各种在宿主机上采集容器数据的工具(链)冒了出来。

市面上关于Docker的监控工具五花八门,但是相对成熟的却又很少。Google的 cAdvisor 已经是属于较成熟的一类,它会在每个宿主机节点上部署cAdvisor进程,默认对外暴露8080端口,用户可通过其提供的Web服务访问当前节点和各容器的性能数据(CPU、内存、网络、磁盘、文件系统等等),非常详细。展现方式有两种,一种是API,返回标准JSON格式数据,另一种是友好的图表方式,如下图:
cAdvisor

默认cAdvisor是将数据缓存在内存中,因此数据展示能力有限,当然它也提供不同的持久化存储后端:云端的Google BigQuery或者本地端的InfluxDB,通过-storage_driver启动参数指定。

当使用InfluxDB作为cAdvisor的存储后端时,cAdvisor会在InfluxDB中建立一个名为stats的series,所有容器性能数据都存储到这张表里,主要记录数据包括time、tx_errors、rx_bytes、container_name、rx_errors、fs_limit、memory_usage、memory_working_set、fs_device、cpu_cumulative_usage、machine、tx_bytes、fs_usage等等。

在一个大规模部署的Docker集群中,往往会选用各种集群管理和Docker编配工具,比如 Kubernetes Fig Swarm 等。网上各种Docker集群工具的选型文章也多得很,可以参考阅读。只能说,由Google在主推,并且有其闭源版本Borg在Google内部稳定运行10多年的口碑,Kubernetes(k8s)虽然出来得晚,但是社区发展得相当快,大有后来居上的势头。

那么假设选择了k8s作为Docker集群管理工具,容器性能数据监控如何选型?

k8s会在每个node(minor)节点上部署一个Kubelet,默认暴露10250端口,Kubelet主要负责容器的生命周期管理和状态维护,以及监控数据采集。实际上,Kubelet也是通过cAdvisor来采集容器性能数据的,所以需要在Kubelet的启动参数中增加--cadvisor_port参数,它表示本地的cAdvisor服务端口号。Google同时也提供了开源组件 heapster ,用作对Docker集群的监控,heapster原生支持k8s和CoreOS中容器的性能数据采集。当heapster配合k8s运行时,需要指定kubernetes_master的地址,heapster通过k8s得到所有node节点地址,然后通过访问对应的node ip和端口号(10250)来调用目标节点Kubelet的HTTP接口,再由Kubelet调用cAdvisor服务获取该节点上所有容器的性能数据,并依次返回到heapster进行数据聚合。heapster聚合的metric可分为以下几类:

uptime
cpu/usage
memory/usage
memory/page_faults
memory/working_set
network/rx
network/rx_errors
network/tx
network/tx_errors
filesystem/usage

同cAdvisor类似,heaspter也支持多种存储后端,比如默认的memory,表示存内存,另外还有influxdb、bigquery、gcm,可由-sink启动参数指定。如果持久化到InfluxDB,那么根据metric的分类,InfluxDB会生成以下series:

cpu/usage_ns_cumulative
filesystem/usage
memory/page_faults_gauge
memory/usage_bytes_gauge
memory/working_set_bytes_gauge
network/rx_bytes_cumulative
network/rx_errors_cumulative
network/tx_bytes_cumulative
network/tx_errors_cumulative
uptime_ms_cumulative

这里需要注意的是,metric的分类有两种,一种是类似cpu使用时间、网络流入流出量,聚合的是累计值,在serie名称中用cumulative表示,另一种是类似内存使用量,聚合的是瞬时值,在serie名称中用gauge表示。

有了InfluxDB的数据持久化存储之后,剩下的就是数据的展现功能,可以说,任何支持InfluxDB作为存储后端的UI系统(dashboard)都可以用来作为展现层,比如InfluxDB官方自带的图形界面,也可以对接 Grafana ,页面相当酷炫。作为一个平台管理人员,用heapster(cAdvisor) + InfluxDB + Grafana应该可以取得不错的用户体验,但是如果把k8s用在多租户的场景下,由于Grafana的可编程能力有限,对接起来不是很合适,较好地方式还是基于InfluxDB的原始数据(支持类SQL查询)自己实现UI,这样与容器集群管理平台的契合度也高一些。

-- EOF --

作者:衔山的博客
擅写水文,立志于写出白痴都看得懂的技术文章。
原文地址:Docker集群性能数据监控与简单选型, 感谢原作者分享。