集群监控中间件技术对比V1.0

---

1 前言

大数据平台除了数据采集、数据传输与存储、数据分析之外，在集群达到一定规模，或者公司发展达到一定规模之后，需要搭建进行自动化的调度、元数据管理、数据质量管理、集群监控等平台。本文将简单描述大数据平台中集群监控中间件的对比。
一般在发展初期，都会使用开源的中间件进行集群监控，但是后期当公司进一步发展，数据规模进一步发展壮大之后，就需要研发自己的集群监控平台了。前者成本低，能满足一般的需求；后者成本较高，但是能契合公司的需要。
以下，将从几个方面对比着4款开源的集群监控中间件。以便在各种集群监控需求下能选用更加适合的工具。
另外，这里放几个大厂实践的例子作为参考。

2 集群监控中间件对比

具体的安装使用步骤这里不过多赘述，详情请查看对应的技术实践文档。

2.1 监控自定义指标

1.ganglia
python或者C语言自定义

2.grafana
golang自定义

3.zabbix
zabbix中监控项叫做item，监控项的取值方法叫做key。
item: Items是从agnet主机里面获取的所有数据。通常情况下我叫itme为监控项,item由key+参数组成。
Key：我们可以理解为key是item的唯一标识，在agent端有很多监控项，zabbix-server根据key区分不同的监控项。
zabbix_server通过发送key给zabbix_agent,然后agent端口根据key执行设定好的sheel脚本，把所要监控的item的最新数据返回给server端。同Open-falcon的第二种方式大致相同，不同点在于数据格式。zabbix是k-v键值串。value支持五种格式：数字（无正负）、浮点数、字符、日志、文本。

4.open-falcon
如果需要监控自定义指标，有两种方式
1)需要自己通过Http Push指标数据到Client的Agent组件提供的接口，再通过组件Agent上报数据到open-falcon主服务上的Transfer组件做一个汇总。
2)编写采集脚本，用什么语言写没关系，只要目标机器上有运行环境就行，脚本本身要有可执行权限。采集到数据之后直接打印到stdout即可，agent会截获并push给server。数据格式是json。

2.2 监控可视化

1.ganglia
ganglia主要是显示一些性能指标，能再一个界面显示多个监控指标，但是图形化比较晦涩

2.grafana-Prometheus
grafana的视图比较有质感，甚至可以自定义DashBoard

3.zabbix
Zabbix的使用手册文档很全面，页面的功能及使用方式介绍的很清晰

4.open-falcon
Open-falcon的前后端组件可以分开部署。在技术实践文档中，后端部署在hadoop102节点，前端部署在hadoop104节点。

2.3 存储

1.ganglia
存储在rrd环形数据库，固定大小，会覆盖旧数据

2.grafana
存储用mysql

3.zabbix
存储用mysql

4.open-falcon
存储用mysql+redis

2.4 告警

1.ganglia
不带有告警功能

2.grafana
配置alerting可告警

3.zabbix
配置Media可告警

4.open-falcon
open-falcon的告警组件也是可以单独安装的。“告警组件”负责告警策略配置（portal）、告警判定（judge）、告警处理（alarm/sender）、用户组管理（uic）等

2.5 集群的维护

1.ganglia
单独维护ganglia即可，但是功能比较单一；

2.grafana
单独的grafana功能不怎么丰富，集成Prometheus之后可以完成对绝大多数集群的监控；

3.zabbix
单独创建items就可以实现对集群的监控，因此维护起来也很简单；

4.open-falcon
open-falcon是模块化的，需要安装多模块才能实现较丰富的功能，安装起来比较麻烦。在实践文档中，open-falcon的瓶颈主要在python碎片化的版本冲突(python3会报错)；mysql与python连接所需的包导致的mysql的版本冲突。

3 OPEN-FALCON在小米的实践

参考链接：https://book.open-falcon.org/zh/practice/monitor.html

3.1 自监控实践

本文介绍了，小米公司在 Open-Falcon集群自监控方面 的一些实践，即对监控系统的监控。
自监控要做好两方面的工作: 故障报警和状态展示。故障报警，要求尽量实时的发现故障、及时的通知负责人，要求高可用性。状态展示，多用于事前预测、事后追查，实时性、可用性要求 较故障报警 低一个量级。

3.1.1 故障报警

故障报警相对简单。我们使用第三方监控组件AntEye，来监控Open-Falcon实例的健康状况。
Open-Falcon各个组件，都会提供一个描述自身服务可用性的自监控接口，描述如下。AntEye服务会定时巡检、主动调用Open-Falcon各实例的自监控接口，如果发现某个实例的接口没有如约返回"ok"，就认为这个组件故障了(约定)，就通过短信、邮件等方式 通知相应负责人员。为了减少报警通知的频率，AntEye采用了简单的报警退避策略，并会酌情合并一些报警通知的内容。
AntyEye组件主动拉取状态数据，通过本地配置加载监控实例、报警接收人信息、报警通道信息等，这样做，是为了简化报警链路、使故障的发现过程尽量实时&可靠。AntEye组件足够轻量，代码少、功能简单，这样能够保障单个AntEye实例的可用性；同时，AntEye是无状态的，能够部署多套，这进一步保证了自监控服务的高可用。
在同一个重要的网络分区内，通常要部署3+个AntEye，如下图所示。我们一般不会让AntEye做跨网络分区的监控，因为这样会带来很多网络层面的误报。多套部署，会造成报警通知的重复发送，这是高可用的代价；从我们的实践经验来看，这个重复可以接受。

3.1.2 状态展示

状态展示，是将Open-Falcon各组件实例的状态数据，以图形化的形式展示出来，方便人的查看。鉴于实时性、可用性要求不高，我们选择Open-Falcon来做自身状态数据的存储、展示(用Open-Falcon监控Open-Falcon，自举了)，剩下的工作就是状态数据的采集了。
Open-Falcon的Task组件，通过自身提供的查询服务状态数据的接口，周期性的主动拉取Open-Falcon各实例的状态数据；然后，处理这些状态数据，适配成Open-Falcon要求的数据格式；再将适配后的数据，push给本地的Agent；本地的Agent会将这些数据转发到监控系统Open-Falcon。
状态数据入Open-Falcon之后，我们就可以定制Screen页面。如下图，是小米Open-Falcon的状态数据统计页面。定制页面时，需要先找到您关注的counter，这个可以通过dashboard进行搜索，如下图。

定制你的自监控状态数据Screen

4 总结

1.ganglia采用rrd文件存储，可以结合分布式文件系统存储更多的历史数据；配置简单不用每台机器添加配置，但是功能单一；支持分层管理上万机器。监控只有表格和图像两种，比较单一；没有告警机制和消息通知机制；
2.grafana与prometheus结合使用，可以满足大都数监控场景；
3.zabbix使用比较广泛(开源的监控中)，部署比较简单支持多平台，可以实现复杂的告警。但是有一个缺点是当数据量变大或者集群规模变大的时候容易出现性能瓶颈；
4.open-falcon功能强大，在开源项目中有与zabbix争锋的趋势，没有zabbix的性能瓶颈的问题。但是open-falcon的架构比较复杂，并且开源时间还较短，功能还需要进一步完善，比如dashboard的维度是60s,没有其他粒度。
以上基本是四个开源的集群监控框架的优缺点总结。在中小型项目中grafana+Prometheus和zabbix使用的比较多，open-falcon慢慢的也比较多起来。但是随着公司的发展或者项目的发展，不可避免的需要自研集群监控平台。