基于 Prometheus 和 Zabbix 实现容器云平台整体监控方案

【作者】张帆，中国民生银行潜望者Zabbix开源监控项目经理，在Zabbix多Server架构设计、自动化监控方案设计实现、源码解析方面有丰富的经验。

一、概述

容器云成为IT的主要基础设施平台，以Docker为代表的容器技术，加上以Kubernetes为代表的容器编排技术，是目前最流行的容器云建设方案。云平台的特点是快速部署、弹性伸缩、动态调整、运维自动化，对应的监控也需要是动态发现、自动化部署的。我们的项目是以Zabbix为基础监控工具设计和建设的，但鉴于prometheus对docker和 k8s监控的天然集成，我们打算引入prometheus和Zabbix 结合起来，复用之前Zabbix上开发扩展的功能，达到可以快速实现、高效部署的云平台整体监控方案。

Zabbix是面向IP的监控，更适合于物理机/虚拟机环境的监控，可以通过开发自定义脚本采集数据从而实现各类型监控，Prometheus是面向服务和数据的监控，适合云环境的监控，原生支持监控容器，更好的适配k8s，且提供专业的exporter，监控项更全面，不需要二次开发；zabbix agent本身进程有限，agent进程按Server端配置串行取值，采集的效率决定于自定义脚本的执行效率，即使单个监控项采值很快，但若Host同时存在上千个agent类型监控项，还是会造成大部分agent监控项取值延迟，需根据监控项数量调整采值间隔优化，Prometheus官方显示的采集速度是10w/sec，且Prometheus使用时序数据库，更适用于监控数据的存储，按时间索引性能更高，所以使用Prometheus监控容器或k8s本身的性能监控比zabbix实现容器或k8s更优。

Prometheus监控项值仅支持数字类型，zabbix监控项取值类型支持数字、字符串，且zabbix图形化界面成熟，方便查看、配置监控项，所以可以使用zabbix将Prometheus监控项和其取值接入。

对于容器内中间件和数据库的监控，zabbix自身的Database、jmx监控方式或应用主动推送数据不需要安装agent，实现方便，容器内应用仅需与同k8s集群的容器内zabbix proxy能实现互相访问即可，监控项可以复用容器外应用模板，所以仍采用zabbix监控容器内应用实现方案。

二、总体设计架构

按照容器监控的内容，我们分为 docker+K8S基础监控和容器内应用监控两部分来分别实现。

1， docker+K8S基础监控的实现：

由于 prometheus对docker和 k8s 监控的天然集成，通过 cAdvisor 可以直接获取 docker基础监控数据，通过 kube-state-metrics可以直接获取K8S的资源对象和对应监控数据，因此我们在每个K8S集群上默认部署prometheus 实现这部分监控采集，然后通过Zabbix Http Agent 方式调用prometheus API来获取数据，接入Zabbix Server从而复用之前建设的功能，实现后续的告警阈值配置和数据接入集中监控平台。

2，容器内应用监控的实现：

所有的应用监控我们都通过Zabbix实现，这里的 “ 应用 ”可以是数据库、中间件、也可以是某个应用系统，我们通过在容器中增加环境变量 monitor_type来定义，比如 monitor_type =mysql 就代表这个容器的 “ 应用 ” 是mysql ，我们将对它进行mysql监控。

我们在每个 K8S集群上默认部署两种采集方式的Proxy 容器，一种是Pull采集方式（对应着Stateful set 部署方式），另一种是Push采集方式（对应着 deployment 部署方式）。

Pull的方式包括基于odbc的数据库监控、JMX的中间件监控、还有其它通过http等方式实现的容器监控，我们用到了PVC来持久化一些配置文件。如果一个集群中需要多个Proxy，则需要Proxy采集分工实现负载均衡。

Push的方式接受应用容器通过trapper等方式主动推送过来的监控数据，这种方式的Proxy是无状态的，因此如果需要多个Proxy，可以直接通过增加pod副本数横向扩展。

两种方式采集到的数据也都是接入到Zabbix Server中。

注意事项：

①因自动发现并监控容器内应用需要通过宿主机上agent监控脚本与容器交互取回被监控端口等信息，需在脚本中尽量减少宿主机与容器的交互次数，避免对容器造成影响。

②监控容器内应用时调用了api创建单独的应用Host及创建后查询Host状态，应合理设置lld Item频率，本身不需要频繁调用，确保监控保持有效状态即可。

③根据集群规模和采集数量，Prometheus需考虑在各集群的高可用和负载均衡设计架构。

三、 Promethus具体部署方案

我们目前的K8S资源对象以及K8S集群内的容器性能监控底层采集是基于promethus的，监控指标包括容器性能指标（cpu、memory、filesystem、network），K8S资源对象指标（node、pod、deployment、statefulset、service）。

每个K8S集群上默认部署prometheus，需要在K8S集群内部署prometheus server和kube-state-metrics两个组件：

prometheus server：负责采集和存储监控数据，同时提供HTTP API数据访问接口供zabbix使用。
kube-state-metrics：负责向prometheus server提供k8s集群级别的各种资源对象的监控数据。

Zabbix通过http agent方式访问prometheus server API获取数据：

具体方案：

1 、启动default命名空间下的kubernetes enpoints和kubernetes service，这两个资源在获取cAdvisor监控数据过程中起到网络连通的作用，如果不启动，会导致prometheus无法获取到cAdvisor提供的监控指标数据。一般来说，这两个资源都是默认启动的。

2 、集群中的每个工作节点需要启动kubelet，因为cAdvisor集成在kubelet中，如果不启动kubelet将无法采集到cAdvisor监控数据。一般来说，kubelet在各个节点是默认启动的。

3、Prometheus server部署（ deployment 方式）

对于prometheus server，需要满足以下条件

使用 statefulset 类型的部署方式，以满足线上管理要求
同时绑定ClusterIP类型的service和NodePort类型的service，以实现其既可以与集群内部通讯，又可以与集群外部通讯
使用本地数据存储，以保证其时序数据库的数据安全不丢失。
prometheus服务所需要用的配置信息存储在ConfigMap中，以方便配置信息的变更
同时部署configmap-reload容器，以便自动加载配置信息到prometheus服务（当ConfigMap有修改时）

4、kube-state-metrics部署（deployment方式）

对于kube-state-metrics，需要满足以下条件

绑定ClusterIP类型的service，以便可以在集群内部访问（它不需要集群外部的访问）
使用deployment类型的部署方式，以满足线上管理要求

5、Prometheus server服务发现配置

prometheus server的配置文件中至少需要开启以下job

Prometheus server需要启用kubernetes-nodes-cadvisor服务发现，用于容器指标数据的采集
还需要启用对kube-state-metrics的自动发现和数据采集，这部分数据用于k8s资源对象的监控

四、容器Zabbix proxy部署方案

对容器内部应用的监控则是通过容器内proxy端监控。我们在每个K8S集群上默认部署两种采集方式的Proxy 容器，一种是Pull采集方式（对应着Statefull set 部署方式），另一种是Push采集方式（对应着 deployment 部署方式）。

Pull采集方式为Zabbix Proxy主动采集数据，Proxy从Server获取到配置信息后与得到的IP和端口进行通信得到监控项的值，获取数据后再返回给Server；Push采集方式为应用主动推送数据给Zabbix Proxy，应用容器需要向指定的Proxy 的 IP地址，Proxy得到数据后再推送给Server，由于容器本身并不会有固定的IP地址，拟使用service替Proxy向外提供固定的IP和端口。

1，Pull采集方式容器Proxy部署架构图：

部署具体方案：

1.生产18个集群都需部署容器Proxy（statefulset），可能一个集群需要部署多个Proxy，根据zabbix监控需求和监控数据量部署，一个statefulset包含4个container

2.Service需要提供名称使被监控的数据库给zabbix Proxy授权，采用NodePort暴露方式，仅定义了port和targetport，未定义NodePort

3.容器Proxy定义了pvc，申请Storage为1G

4.各Container资源配置祥看配置文件部分

2， Push采集方式的容器Proxy部署架构图：

部署需求：

1.生产18个集群都需部署容器Proxy（deployement），一个集群仅需部署一个Proxy，通过配置文件中replicas决定pod数量

2.Service需要提供端口给应用容器访问，推送数据，采用NodePort暴露方式，仅定义了port和targetport，因为不涉及集群外访问，未定义NodePort

3.各Container资源配置祥看配置文件部分

五、小结

以上就是我们基于Prometheus和Zabbix实现容器云平台整体监控方案，它是基于我们这边云平台整体的监控方案，和潜望者Zabbix开源监控项目已建设的成果来设计的，可能不是最优方案，但从实现成本、监控稳定性、开发周期上来说是我们目前最合理的方案，仅供各路专家参考，不妥之处欢迎批评指导。另外整体的方案还包括具体的监控指标、指标实现、自动化部署、自动发现方案、云监控分层展示方案等，内容较多，后续再跟大家分享，谢谢！