监控大规模Hadoop集群，Prometheus超过Zabbix？
发布时间：2021-06-04 19:29:29 所属栏目：大数据 来源：互联网
导读：作者介绍 洪迪，联通大数据高级运维开发工程师，主要负责大数据平台运维管理及核心监控平台开发工作。具有多年大数据集群规划建设、性能调优及监控体系建设经验，对Prometheus架构设计、运维开发等方面有深入理解和实践。 背景 随着公司业务发展，大数据集群
|
作者介绍
洪迪，联通大数据高级运维开发工程师，主要负责大数据平台运维管理及核心监控平台开发工作。具有多年大数据集群规划建设、性能调优及监控体系建设经验，对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离线、硬盘故障、时钟异常等，都可以进行自动恢复(详情见下文)。
 （编辑：广安站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
