PAAS云平台监控实现与探讨

张凤丽

天津工业职业学院 天津 300400

1 Prometheus介绍

1.1 简介

Prometheus是一种应用十分广泛的性能监控平台，是一个开源的记录和处理数字时间序列的监控平台，由Matt T.Proud和Julius Volz最初合作开发，开始开发的大部分费用由SoundCloud赞助，使用Go语言编写，现在是一个独立的开源项目，独立于任何公司维护，并于2016年加入云原生基金会，成为继Kubernetes之后的第二个托管项目。其工作基本原理是通过HTTP协议周期性的抓取被监控组件的状态，任何组件只要提供HTTP接口就可以接入监控系统而不需要任何SDK[1]。

1.2 工作流程、架构

Prometheus的工作流程如下。

Prometheus Server负责对监控数据的获取、存储、查询与监测Job的调度，以既定的轮询频率抓取监控目标数据并实现数据持久化到时序数据库。与其他依靠代理或嵌入式设备收集数据并“推送”指标到监控后台思路不同，Prometheus Exporter负责将监控数据采集的端点(Endpoint)通过HTTP服务暴露，之后Prometheus Server通过访问该端点获取需要采集的监控数据。如果目标网络不可达，可以通过PushGateway间接实现目标指标项抓取。另外Prometheus提供客户端库，选择适合的语言，可以方便地在应用程序上为需要监控的服务生成相应的metric并暴露给Prometheus server，当Prometheus server来pull时，直接返回实时状态的metric。Prometheus Alertmanager报警组件用于处理收到的警报以及Grafana数据展示组件用于可视化展示收集的数据。

Prometheus整体架构如图1所示。

图1 Prometheus架构图

1.3 特点

Prometheus的主要特点如下：

(1)提供多维数据模型，时间序列由metric名称和k/v的labels组成。

(2)提供一个灵活的查询语句PromQL，可以利用多维数据完成复杂查询。

(3)不依赖于分布式存储的独立的Prometheus服务器。

(4)基于HTTP的pull模式收集时间序列数据，同时采用PushGateway组件收集数据。

(5)通过服务发现或者静态配置去获取监控对象，自动完成数据采集。

(7)支持作为数据源接入Grafana，有多种可视化图形界面，易于伸缩[2-3]。

2 Prometheus与其他监控工具的比较

随着云计算平台的快速发展，云平台服务因具有虚拟性、通用性、部署便捷、个性化服务和廉价性等优点被广泛应用到生产和生活的各个方面，然而面对不管是大量的硬件设备或者是海量的软件应用服务，如何对整个资源进行有效监控就显得尤为重要了。越来越多的公司顺势推出了自己相应的监控工具，如Zabbix、Caati、InfluxDB、OpenTSDB、Nagios、Prometheus等。其中Zabbix是一个企业级、开源分布式的监控工具，主要用于物理主机，交换机和网络监控等，支持agent、snmp、JMX、telnet等多种数据采集方式并拥有丰富的插件，具有高可用性，支持多种告警方式，如基于邮件、短信和微信等，支持图形化展示，但是存在性能瓶颈，存在单机的上线并且采用的是C和PHP语言，运行速度会比Prometheus稍慢一些[4]。Cacti是基于PHP语言开发的网络流量监测工具，但缺点比较明显如图像效果不佳、不支持分布式等。InfluxDB是一个开源的时序数据库，主要用于存储数据，如果想搭建监控报警系统，则需要依赖于其他的系统，如数据采集器、报警模块等。OpenTSDB是基于Hadoop和HBase的分布式时间序列数据库，如果对时间序列数据有长期的存储需要，并且对Hadoop十分熟悉则可以选用。Nagios是比较适合小集群或者静态系统的监控，是一个轻量化的监控系统，相对于目前的监控系统工具来说比较古老，很多性能都没有，不方便扩展，需要增加很多插件[5]。

本文中所要探讨的Prometheuss属于一站式监控报警平台；具有灵活的数据模型，同时支持在数据采集阶段对监控数据的标签进行修改；提供了十分灵活的丰富的查询语句，能够支持多维数据的复杂查询；支持对云或者容器的监控；具有丰富的组件支持；成熟的社区和丰富的参考文档，以便于快速搭建监控系统，是目前应用最多的云平台的监控工具[6]。

3 基于Prometheus的Paas云平台监控的探讨

3.1 Exporter分类合并

Prometheus官网提供很多Exporter链接，用来实现不同产品指标数据抽取，有些标注为官方维护如MySQL server exporter，Node/system metrics exporter等，有些由Prometheus社区开发，还有一些第三提供，供大家参考或使用。但开源Exporter的指标数量通常远远多于具体项目监控指标需求，无需周期获取这些相应指标数据。如果依然周期获取不使用指标，不仅增加Exporter接口响应时间，也会给Prometheus及对应后端时序存储带来一定的压力。抑或Exporter依然全量抽取，通过Prometheus配置实现指标过滤，都会增添额外的计算负担。因此，考虑Exporter基于全量指标基础上，提供指标分类，指标简单分为2类Enabled和Disabled，决定是否参与数据抽取，做到依据项目需求，指标页面可配置，每次请求时进行指标分类处理，并加载Enabled指标，进行抽取。

Prometheus通过Pull方式周期的从目标端(Exporter)抽取数据。该种松耦合的架构方式，只要Exporter在运行，可以在任何地方，查看监控目标实例的健康状态，并且可以快速定位故障。在PAAS平台中，通常需要将Exporter部署到监控目标虚拟机内，对目标入侵性较高，同时监控不同种类指标可能需要不同Exporter，导致目标端内需要维护多个Exporter，使目标端Agent泛滥，带来更多的资源消耗，维护起来更棘手。后续如果发现BUG或是版本升级，需要依次升级所有Exporter，风险很高。如果将Exporter从目标端移出，作为Kubernates集群独立服务部署，可以避免上述谈到的诸多问题。Exporter作为独立服务部署，不同的Exporter既可以分开独立部署或按类别合并相近的Exporter如将数据库相关的Exporter合并，形成新的DB-Exporter，对外提供指标抽取服务。实际开发工程项目中，将Prometheus官网数据库Redis Exporter，MySQL Server Exporter(official)，MongoDB Exporter的开源代码进行修改合并，并成功实现数据库引擎指标抽取工作，整体结构如图2所示。Exporter Db提供数据库引擎指标抓取，Exporter vm实现类似Node exporter指标数据抓取。数据渲染部分并没有采用官方的Grafana作为解决方案，而是通过elm组件进行个性化实现。UI效果呈现，如图2所示。

图2

图3

3.2 目标发现机制的探讨

Prometheus目标发现机制，在实际项目中的应用。Prometheus提供两种目标发现机制。基于文件的目标发现，可以结合共享存储或是Etcd组件，如kubernates提供挂载共享存储卷，Prometheus服务只需部署一份，可以充分利用kubernates服务高可用机制，在不同Node间秒级拉起新的Prometheus提供服务，监控目标集合始终没有变化。抑或通过Etcd保证Prometheus多个Node节点目标配置文件一致性，Prometheus服务仍然部署一份。假设由于监控实例目标数量增长，需要多个Prometheus服务分担监控目标，且避免同一个目标被重复拉取，就要分Node下发不同监控目标文件，也就失去Kubernates高可用的意义。基于Consule服务发现机制，发现的是服务，依然无法监控不同产品实例目标如数据库，中间件实例等。但可模拟Consule服务接口/agent/self、/catalog/services、/health/service/：id来实现程序扫描数据库中监控目标的记录，从而实现表中记录的变化，及时被Prometheus服务感知。该种方案，亦可以通过计算表中监控目标记录数，动态增加Prometheus服务Replica数量，分担Prometheus服务压力，整体结构如图4所示。

图4

结语

依据探讨点进行的设计具有可行性及用户友好型，不仅可以实现指标项灵活修改、减少exporter数量依赖，升级便捷，最重要的通过模拟Consule后，可以动态扩展Prometheus Repica数量，分担负载。