作者引见
洪迪，联通大数据初级运维开发工程师，关键担任大数据平台运维控制及**监控平台开发上班。具有多年大数据集群布局树立、性能调优及监控体系树立阅历，对Prometheus架构设计、运维开发等方面有深化了解和通常。
背景
随着公司业务开展，大数据集群规模正在始终扩展，一些大型集群物理机节点甚至已近上千。面对如此规模宏大的集群，一套低劣的监控系统是运维人员发现及处置缺点的关键利器。经过屡次选型和迭代，笔者选用了Prometheus，这款时下炽热而弱小的开源监控组件为**来构建大数据集群监控平台。
最后的监控平台选型
公司最后驳回的监控平台为Nagios+Ganglia或Zabbix+Grafana组合，但经过上线后长期间通常验证，发现这两个组合存在如下不尽人意之处：
Nagios+Ganglia
该搭配的关键疑问在于Nagios只能对主机性能目的启动惯例监控，在对大数据集群各组件启动监控时，则须要启动少量的自定义开发上班，且对集群的监控维度并不片面。而且由于Nagiso没有存储历史数据的性能，在面对一些集群性能剖析或缺点剖析上班时，Nagios+Ganglia的搭配成果并不能到达运维人员的预期。
Zabbix+Ganglia
相比于前者，该搭配好处在于可以成功监控数据可视化的上班，在集群性能剖析和缺点剖析方面能够成功运维人员的各类需求，且对外提供web控制页面，能够简化上手难度。只管如此，该搭配还是存在一些疑问，例如当集群到达必定数量规模时，监控存储数据库就会成为性能瓶颈，面对大规模的数据读写会顾此失彼，造成Grafana查问缓慢甚至卡死。
监控平台选型提升
鉴于以上两种组合存在的缺陷，依据实践上班须要，笔者对监控平台的选型启动了提升，选用了Prometheus+Alertmanager+Grafana的组合。之所以选用该组协作为平台**，是由于其具有以下几点好处：
Prometheus+Alertmanager+Grafana平台架构如下图所示：
从图中可以看出，该套平台以Prometheus为**，可成功对监控实例(如大数据组件、数据库、主机、两边件等，余者不再赘述)启动数据采集、剖析计算、聚合克服、智能发送、缺点自愈等多种性能。并具有以下几个特点：
监控平台性能成功
适配大数据生态组件监控
Prometheus性能只管十分弱小，然而适配大数据生态组件的监控却不是一件容易的事件。当下盛行的搭配是用Jmx_exporter来采集各组件的监控数据供Prometheus拉取。这种搭配只管可以满足开箱即用的准则，然而当运维人员关注一些组件特有的监控项时，由于Jmx_exporter没有搜集关系监控项，就会顾此失彼。
但经过笔者自研的Exporter定时采集组件Jmx或CDH版本的特定API的模式来失掉监控数据，经过转换处置构成Metrics供Prometheus失掉，则可以很好地处置上述疑问。上方选取几个具有代表性的实例启动引见：
1、Namenode RPC关上衔接数
在排查NamenodeRPC提前的疑问时，必定水平上，可以经过检查RPC关上衔接数观察Namenode的上班负载状况。namenode监控数据可经过Url地址查问。
访问该url数据后，经过一系列的转换，可以前往咱们须要的格局化数据，如以下代码所示：
2、Yarn队列失掉
当处置多租户Yarn集群资源争抢疑问的时刻，运维人员最须要的就是失掉Yarn各队列的资源经常使用状况。对此，首先要做的就是失掉yarn队列列表，可以经过上方的Url来失掉，
范例代码如下：
实时信息发送
在消费环境中，有一些信息通知须要即时或定时发送到关系人员钉钉上，假设用Prometheus当做告警触发来成功，会造成这些信息通知一遍又一遍地发送到钉钉上，但理想上这些信息并不同于告警，只发送一次性即可。面对这一疑问，其实可以经过调用钉钉机器人Webhook发送即时信息启动处置，如以下一则实例：
笔者控制的某个多租户HDFS集群存储资源比拟弛缓，每个租户都有自己的独自目录，事前已针对这些目录启动了实时数据量及文件数经常使用统计，统计数据保留到Prometheus里。每天早上经过Prometheus的API来失掉当日8时及前一日8时一切租户目录经常使用状况，并启动对比。当增量超越设定阈值时，就会发送一条实时信息到钉钉上，提示对应租户控制数据。信息界面如下图所示：
缺点自愈
当大数据集群总规模到达上千台时，关于一些经常出现缺点如计算存储节点配件缺点造成离线、数据硬盘缺点、NTP时钟意外等，假设人肉手动处置，将会消耗少量期间和精神。但笔者目前经常使用的自愈系统则可以智能处置大局部经常出现缺点。该自愈系统逻辑如下图所示：
该自愈系统具有以下特点：
缺点自愈通知界面如下：
1、自愈通知
2、可ping通无法ssh主机通知：
3、无法ping通主机通知：
监控功效
为了愈加直观地实时检查监控平台各监控项状况，笔者引入了集群监控大屏启动可视化成果展现，灵活展现数据变动，直观表现数据价值，大屏展现成果如下图所示：
HDFS基础目的展现(容量信息、肥壮节点、文件总数、集群IO、RPC负载、Namenode GC状况等)
HDFS定制监控展现(RPC关上数、HDFS租户目录数据大小/文件数监控、目录经常使用占比画像等)
Yarn基础信息展现(肥壮节点数、总队列及子队列资源监控等)
除此之外，监控集群各组件的肥壮形态，如有意外，也会经过钉钉信息告知运维人员，如下图所示：
集群告正通知：
多租户集群无法防止的就是租户计算资源抢占疑问，当单个Job作业资源占用过大时，告正通知如下：
上文提到的数据具有、流程具有通知信息：
总结与展望
该套监控平台目前承载10个大型的大数据集群、50+个数据库、若干两边件及业务流程监控义务，平均每秒5W左右监控数据入库。经过对告警数据的准确剖析、判别、预警，能够协助运维人员深化了解业务集群及其余监控对象的运转形态，从而及时规避或协助处置重大疑问，将隐患扼杀在萌芽之时。
接上去，笔者方案对监控平台的智能发送、存储周期及高可用性启动钻研和提升，使其愈加智能、高效、规范，并陆续向其余业务体系启动推行，买通与其余业务体系的数据交互通道，从而片面深度开掘数据的价值。
咱们正在阅历一个数据量高速收缩的时代，但这些海量的、扩散的异构数据造成了数据资源价值低、运行难度大等疑问。
如何将海量数据充沛开掘与运用，来撑持决策、驱动业务开展、启动产品翻新?如何应用大数据平台提升流程、服务、产品?可以说，一切的一切都离不开数据控制与数据资产控制。