作者介绍
洪迪，联通大数据高级运维开发工程师，主要负责大数据平台运维管理及核心监控平台开发工作。具有多年大数据集群规划建设、性能调优及监控体系建设经验，对Prometheus架构设计、运维开发等方面有深入理解和实践。
背景
随着公司业务发展，大数据集群规模正在不断扩大，一些大型集群物理机节点甚至已近上千。面对如此规模庞大的集群，一套优秀的监控系统是运维人员发现及处理故障的关键利器。经过多次选型和迭代，笔者选择了Prometheus，这款时下火热而强大的开源监控组件为核心来构建大数据集群监控平台。
最初的监控平台选型
公司最初采用的监控平台为Nagios+Ganglia或Zabbix+Grafana组合，但经过上线后长时间实践验证，发现这两个组合存在如下不尽人意之处：
Nagios+Ganglia
该搭配的主要问题在于Nagios只能对主机性能指标进行常规监控，在对大数据集群各组件进行监控时，则需要进行大量的自定义开发工作，且对集群的监控维度并不全面。而且由于Nagiso没有存储历史数据的功能，在面对一些集群性能分析或故障分析工作时，Nagios+Ganglia的搭配效果并不能达到运维人员的预期。
Zabbix+Ganglia
相比于前者，该搭配优点在于可以完成监控数据可视化的工作，在集群性能分析和故障分析方面能够实现运维人员的各类需求，且对外提供web管理页面，能够简化上手难度。虽然如此，该搭配还是存在一些问题，例如当集群达到一定数量规模时，监控存储数据库就会成为性能瓶颈，面对大规模的数据读写会捉襟见肘，导致Grafana查询缓慢甚至卡死。
监控平台选型优化
鉴于以上两种组合存在的缺点，根据实际工作需要，笔者对监控平台的选型进行了优化，选择了Prometheus+Alertmanager+Grafana的组合。之所以选择该组合作为平台核心，是因为其具有以下几点优势：
- 内置优秀的TSDB数据库，可以轻松应对大数据量并发查询，为运维人员提供关键指标；
- 强大的Promql，可以通过各类内置函数，获取各维度搜索监控数据用于Grafana出图；
- Prometheus基于Go语言开发，Go高效的运行效率，使其拥有天生的速度优势；
- 活跃的Github社区，提供丰富的Client库。
Prometheus+Alertmanager+Grafana平台架构如下图所示：
从图中可以看出，该套平台以Prometheus为核心，可实现对监控实例(如大数据组件、数据库、主机、中间件等，余者不再赘述)进行数据采集、分析计算、聚合抑制、智能发送、故障自愈等多种功能。并具有以下几个特点：
- 对于Prometheus官方或Github社区已有的Exporter库，如Telegraf及Mysql_exporter等，可以直接进行相关配置开箱即用，不必重复造轮子；
- 对于大数据生态组件如Hadoop、Yarn、HBase等，笔者并没有采用官方的Jmx_exporter，因为一些特殊监控项并不能通过该组件采集到。而是自研一套Exporter针对各项组件进行监控，通过笔者自研的Exporter，可以实现各类RPC操作负载，RPC打开连接数、HDFS空间及文件数监控，Yarn总队列及子队列性能监控，Yarn job作业性能监控，HBase压缩及刷新队列性能监控等功能(详情见下文)；
- 对于一些流程调度或数据具备、日周报等实时消息，可以引入该平台，进行通知消息实时发送(只通知不需要恢复)；
- 故障自愈也是该平台的一个重要特点，对于大数据平台的常见故障如Datanode、Nodemager、Regionserver离线、硬盘故障、时钟异常等，都可以进行自动恢复(详情见下文)。
监控平台功能实现适配大数据生态组件监控
Prometheus性能虽然十分强大，但是适配大数据生态组件的监控却不是一件容易的事情。当下流行的搭配是用Jmx_exporter来采集各组件的监控数据供Prometheus拉取。这种搭配虽然可以满足开箱即用的原则，但是当运维人员关注一些组件特有的监控项时，因为Jmx_exporter没有收集相关监控项，就会捉襟见肘。
但通过笔者自研的Exporter定时采集组件Jmx或CDH版本的特定API的方式来获取监控数据，经过转换处理形成Metrics供Prometheus获取，则可以很好地解决上述问题。下面选取几个具有代表性的实例进行介绍：
1、Namenode RPC打开连接数
在排查Namenode RPC延迟的问题时，一定程度上，可以通过查看RPC打开连接数观察Namenode的工作负载情况。namenode监控数据可通过Url地址http://localhost:50070/jmx?qry=Hadoop:service=NameNode,name=RpcActivityForPort8020查询。
访问该url数据后，通过一系列的转换，可以返回我们需要的格式化数据，如以下代码所示：
2、Yarn队列获取
当处理多租户Yarn集群资源争抢问题的时候，运维人员最需要的就是获取Yarn各队列的资源使用情况。对此，首先要做的就是获取yarn队列列表，可以通过下面的Url来获取，http://localhost:8088/ws/v1/cluster/scheduler
范例代码如下：
实时消息发送
在生产环境中，有一些消息通知需要即时或定时发送到相关人员钉钉上，如果用Prometheus当做告警触发来完成，会导致这些消息通知一遍又一遍地发送到钉钉上，但事实上这些消息并不同于告警，只发送一次即可。面对这一问题，其实可以通过调用钉钉机器人Webhook发送即时消息进行解决，如以下一则实例：
笔者管理的某个多租户HDFS集群存储资源比较紧张，每个租户都有自己的单独目录，事先已针对这些目录进行了实时数据量及文件数使用统计，统计数据保存到Prometheus里。每天早上通过Prometheus的API来获取当日8时及前一日8时所有租户目录使用情况，并进行对比。当增量超过设定阈值时，就会发送一条实时消息到钉钉上，提醒对应租户管理数据。消息界面如下图所示：
故障自愈
当大数据集群总规模达到上千台时，对于一些常见故障如计算存储节点硬件故障导致离线、数据硬盘故障、NTP时钟异常等，如果人肉手动处理，将会耗费大量时间和精力。但笔者目前使用的自愈系统则可以自动解决大部分常见故障。该自愈系统逻辑如下图所示：
该自愈系统具有以下特点：
- 故障修复前自动检测主机联通性，对于异常主机可以直接转交主机侧同事处理；
- 各类通知智能发送，对于连接异常类消息，夜间(00:00-06:00)只发送一次，避免夜间无意义打扰；
- 沉淀各种常见故障修复过程，使故障修复更加精准智能；
- 监控自愈程序，如程序异常退出或修复过程中发生异常，可及时告知运维人员进行手动修复。
故障自愈通知界面如下：
1、自愈通知
2、可ping通无法ssh主机通知：
3、无法ping通主机通知：
监控成效
为了更加直观地实时查看监控平台各监控项情况，笔者引入了集群监控大屏进行可视化效果展示，动态展现数据变化，直观体现数据价值，大屏展示效果如下图所示：
HDFS基础指标展示(容量信息、健康节点、文件总数、集群IO、RPC负载、Namenode GC情况等)
HDFS定制监控展示(RPC打开数、HDFS租户目录数据大小/文件数监控、目录使用占比画像等)
Yarn基础信息展示(健康节点数、总队列及子队列资源监控等)
除此之外，监控集群各组件的健康状态，如有异常，也会通过钉钉消息告知运维人员，如下图所示：
集群告警通知：
多租户集群不可避免的就是租户计算资源抢占问题，当单个Job作业资源占用过大时，告警通知如下：
上文提到的数据具备、流程具备通知消息：
总结与展望
该套监控平台目前承载10个大型的大数据集群、50+个数据库、若干中间件及业务流程监控任务，平均每秒5W左右监控数据入库。通过对告警数据的精确分析、判断、预警，能够帮助运维人员深入了解业务集群及其他监控对象的运行状态，从而及时规避或协助处理严重问题，将隐患扼杀在萌芽之时。
接下来，笔者计划对监控平台的智能发送、存储周期及高可用性进行研究和优化，使其更加智能、高效、规范，并陆续向其他业务体系进行推广，打通与其他业务体系的数据交互通道，从而全面深度挖掘数据的价值。
