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

2020年5月19日 313点热度 0人点赞 0条评论
图片

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

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

欢迎点击文末阅读原文到社区原文下留言交流

也可参与在线技术交流:如何基于Prometheus 和 Zabbix 实现容器云平台整体监控

觉得本文有用,请转发或点击“在看”,让更多同行看到


 资料/文章推荐:

欢迎关注社区以下  “容器云”技术主题 ,将会不断更新优质资料、文章。地址:https://www.talkwithtrend.com/Topic/98447


下载 twt 社区客户端 APP

图片

图片

长按识别二维码即可下载

或到应用商店搜索“twt”


长按二维码关注公众号

图片

*本公众号所发布内容仅代表作者观点,不代表社区立场

59850基于 Prometheus 和 Zabbix 实现容器云平台整体监控方案 | 最佳实践

这个人很懒,什么都没留下

文章评论