【QCon】精华内容上线92%,全面覆盖“人工智能+”的典型案例!>>> 了解详情
写点什么

监控大规模 Hadoop 集群,Prometheus 完胜 Zabbix?

  • 2020-08-03
  • 本文字数:3216 字

    阅读完需:约 11 分钟

监控大规模Hadoop集群,Prometheus完胜Zabbix?

本文由 dbaplus 社群授权转载。

背景

随着公司业务发展,大数据集群规模正在不断扩大,一些大型集群物理机节点甚至已近上千。面对如此规模庞大的集群,一套优秀的监控系统是运维人员发现及处理故障的关键利器。经过多次选型和迭代,笔者选择了 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 左右监控数据入库。通过对告警数据的精确分析、判断、预警,能够帮助运维人员深入了解业务集群及其他监控对象的运行状态,从而及时规避或协助处理严重问题,将隐患扼杀在萌芽之时。


接下来,笔者计划对监控平台的智能发送、存储周期及高可用性进行研究和优化,使其更加智能、高效、规范,并陆续向其他业务体系进行推广,打通与其他业务体系的数据交互通道,从而全面深度挖掘数据的价值。


作者介绍


洪迪,联通大数据高级运维开发工程师,主要负责大数据平台运维管理及核心监控平台开发工作。具有多年大数据集群规划建设、性能调优及监控体系建设经验,对 Prometheus 架构设计、运维开发等方面有深入理解和实践。


原文链接


https://mp.weixin.qq.com/s?__biz=MzI4NTA1MDEwNg==&mid=2650792839&idx=1&sn=9277a75b8af73127fd29109e1fac98d7&chksm=f3f95612c48edf044d69f56e831126b83ae0e6344aa40844a663ebe9b9ba85d7f4c4e913b4de&scene=27#wechat_redirect


2020-08-03 10:025196

评论

发布
暂无评论
发现更多内容

爬虫基本原理介绍、实现以及问题解决

石臻臻的杂货铺

爬虫

JAVA concurrency -- ThreadLocal 源码详解

骑牛上青山

Java 源码

冷冷清清的双十一,电商促销节为何被消费者逐渐抛弃

石头IT视角

2022-11-17:组合两个表。请写出sql语句,执行结果是{“headers“: [“first_name“, “last_name“, “city“, “state“], “values“: [

福大大架构师每日一题

数据库 福大大

OSPF路由协议一

初学者

11月月更

通过阅读源码解决项目难题:GToken替换JWT实现SSO单点登录

王中阳Go

Go golang 高效工作 学习方法 11月月更

链路状态路由协议 OSPF (一)

我叫于豆豆吖.

11月月更

Flowable 外置的 HTML 表单怎么玩?

江南一点雨

Java spring flowable JavaEE

简单时序逻辑电路

攻城狮Wayne

Verilog 11月月更 锁存器

流程表单初体验

江南一点雨

Java spring springboot flowable

算法题学习---单链表的排序

桑榆

算法题 11月月更

为什么要做用户留存分析

穿过生命散发芬芳

用户留存 11月月更

JAVA concurrency -- ArrayBlockingQueue源码详解

骑牛上青山

Java 源码

jvm(二)内存管理与虚拟机执行子系统

想要飞的猪

java对象内存布局 jvm加载子系统

L1、L2范数理解--Ridge以及Lasso回归

Studying_swz

深度学习 11月月更

uni-app 性能优化实战之逻辑层条件编译的生产环境

恒山其若陋兮

11月月更 uni

东方通Tongweb中间件Linux环境部署

@下一站

技术 中间件 linux 文件权限控制 Java core 11月月更

动态路由协议(二)

我叫于豆豆吖.

11月月更

JAVA concurrency -- ReentrantLock 源码详解

骑牛上青山

Java 源码

JAVA concurrency -- CyclicBarrier 与 CountDownLatch 源码详解

骑牛上青山

Java 源码

一次zuul版本升级产生的问题排查记录

骑牛上青山

Java spring 源码 Zuul 生产环境

动态路由协议(一)

我叫于豆豆吖.

11月月更

使用gitflow时如何合并hotfix

alps2006

Redis LRU 内存淘汰算法大有玄机

码哥字节

LRU Redis 6.0

2022下半年《软考-系统架构设计师》备考经验分享

劼哥stone

软考 系统架构师

Postman工具介绍

阿泽🧸

Postman 11月月更

MUI框架的上拉加载的深入探索和实战运用

恒山其若陋兮

mui 11月月更

分布式系统中的哈希算法

骑牛上青山

数据结构 分布式 算法 哈希

2022昇腾AI创新大赛圆满收官,看这届评委怎么说?

Geek_2d6073

融云「百幄」之数字人,升级交互体验的「新同事」

融云 RongCloud

AI 通信 数字化

对于Ajax在MUI框架中的用运以及单 webview 模式中的下拉刷新功能探究

恒山其若陋兮

mui 11月月更

监控大规模Hadoop集群,Prometheus完胜Zabbix?_大数据_dbaplus社群_InfoQ精选文章