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

基于Prometheus和Zabbix实现容器云平台整体监控方案一、概述容器云成为IT的主要基础设施平台，以Docker为代表的容器技术，加上以Kubernetes为代表的容器编排技术，是目前最流行的容器云建设方案。云平台的特点是快速部署、弹性伸缩、动态调整、运维自动化，对应的监控也需要是动态发现、自动化部署的。我们的项目是以Zabbix为基础监控工具设计和建设的，但鉴于prometheus对docker和k8s监控的天然集成，我们打算引入prometheus和Zabbix结合起来，复用之前Zabbix上开发扩展的功能，达到可以快速实现、高效部署的云平台整体监控方案。Zabbix是面向IP的监控，更适合于物理机/虚拟机环境的监控，可以通过开发自定义脚本采集数据从而实现各类型监控，Prometheus是面向服务和数据的监控，适合云环境的监控，原生支持监控容器，更好的适配k8s，且提供专业的exporter，监控项更全面，不需要二次开发；zabbixagent本身进程有限，agent进程按Server端配置串行取值，采集的效率决定于自定义脚本的执行效率，即使单个监控项采值很快，但若Host同时存在上千个agent类型监控项，还是会造成大部分agent监控项取值延迟，需根据监控项数量调整采值间隔优化，Prometheus官方显示的采集速度是10w/sec，且Prometheus使用时序数据库，更适用于监控数据的存储，按时间索引性能更高，所以使用Prometheus监控容器或k8s本身的性能监控比zabbix实现容器或k8s更优。Prometheus监控项值仅支持数字类型，zabbix监控项取值类型支持数字、字符串，且zabbix图形化界面成熟，方便查看、配置监控项，所以可以使用zabbix将Prometheus监控项和其取值接入。对于容器内中间件和数据库的监控，zabbix自身的Database、jmx监控方式或应用主动推送数据不需要安装agent，实现方便，容器内应用仅需与同k8s集群的容器内zabbixproxy能实现互相访问即可，监控项可以复用容器外应用模板，所以仍采用zabbix监控容器内应用实现方案。二、总体设计架构按照容器监控的内容，我们分为docker+K8S基础监控和容器内应用监控两部分来分别实现。1，docker+K8S基础监控的实现：由于prometheus对docker和k8s监控的天然集成，通过cAdvisor可以直接获取docker基础监控数据，通过kube-state-metrics可以直接获取K8S的资源对象和对应监控数据，因此我们在每个K8S集群上默认部署prometheus实现这部分监控采集，然后通过ZabbixHttpAgent方式调用prometheusAPI来获取数据，接入ZabbixServer从而复用之前建设的功能，实现后续的告警阈值配置和数据接入集中监控平台。2，容器内应用监控的实现：所有的应用监控我们都通过Zabbix实现，这里的“应用”可以是数据库、中间件、也可以是某个应用系统，我们通过在容器中增加环境变量monitor_type来定义，比如monitor_type=mysql就代表这个容器的“应用”是mysql，我们将对它进行mysql监控。我们在每个K8S集群上默认部署两种采集方式的Proxy容器，一种是Pull采集方式（对应着Statefulset部署方式），另一种是Push采集方式（对应着deployment部署方式）。Pull的方式包括基于odbc的数据库监控、JMX的中间件监控、还有其它通过http等方式实现的容器监控，我们用到了PVC来持久化一些配置文件。如果一个集群中需要多个Proxy，则需要Proxy采集分工实现负载均衡。Push的方式接受应用容器通过trapper等方式主动推送过来的监控数据，这种方式的Proxy是无状态的，因此如果需要多个Proxy，可以直接通过增加pod副本数横向扩展。两种方式采集到的数据也都是接入到ZabbixServer中。注意事项：①因自动发现并监控容器内应用需要通过宿主机上agent监控脚本与容器交互取回被监控端口等信息，需在脚本中尽量减少宿主机与容器的交互次数，避免对容器造成影响。②监控容器内应用时调用了api创建单独的应用Host及创建后查询Host状态，应合理设置lldItem频率，本身不需要频繁调用，确保监控保持有效状态即可。③根据集群规模和采集数量，Prometheus需考虑在各集群的高可用和负载均衡设计架构。三、Promethus具体部署方案我们目前的K8S资源对象以及K8S集群内的容器性能监控底层采集是基于promethus的，监控指标包括容器性能指标（cpu、memory、filesystem、network），K8S资