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

一、 概述

容器云成为IT的主要基础设施平台,以Docker为代表的容器技术，加上以Kubernetes为代表的容器编排技术，是目前最流行的容器云建设方案。云平台的特点是快速部署、弹性 伸缩、 动态 调整、 运维 自动化 ，对应 的监控 也需要是动态 发现、自动 化 部署的 。我们 的 项目是 以Zabbix 为基础监控 工具 设计 和 建设 的，但 鉴于 prometheus对docker和 k 8s 监控 的天然集成 ， 我们打算引入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和 k 8s 监控 的天然集成 ，通过 cAdvisor 可以 直接 获取 docker基础监控数据， 通过 kube-state-metrics可以 直接 获取K8S的资源对象和对应监控数据 ，因此 我们 在 每个 K 8S集群上 默认 部署prometheus 实现 这部分监控采集， 然后 通过Zabbix Http Agent 方式调用prometheus API来获取数据，接入Zabbix Server从而复用之前建设的 功能 ，实现后续的告警阈值配置和数据 接入 集中监控平台。

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

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

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

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

P ush 的方式 接受 应用 容器通过 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）。

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

l prometheus server：负责采集和存储监控数据，同时提供HTTP API数据访问接口供zabbix使用。

l 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资源对象的监控

四、 容器Zabbixproxy部署方案

对容器内部应用的监控则是通过容器内proxy端监控。 我们 在 每个 K 8S集群上 默认 部署 部署两种采集方式 的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部署架构图：

部署需求：

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

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

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

五、 小结

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