zhangfan13cmbc
作者zhangfan13cmbc2020-05-19 21:05
项目经理, 中国民生银行

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

字数 4495阅读 1694评论 0赞 5

一、 概述

容器云成为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需考虑在各集群的高可用和负载均衡设计架构。

三、 P**romethus具体部署方案**

我们目前的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开源监控项目已建设的成果来设计的,可能不是最优方案,但从实现成本、监控稳定性、开发周期上来说是我们目前最合理的方案,仅供各路专家参考,不妥之处欢迎 批评 指导。另外整体的方案还包括具体的监控指标 、指标实现 、自动化 部署 、自动发现方案 、 云监控分层展示方案等 ,内容较多,后续再跟大家分享 , 谢谢!

如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!

5

添加新评论0 条评论

Ctrl+Enter 发表

作者其他文章