基于Prometheus和Grafana的Hadoop集群监控Dashboard搭建指南

简介本资源是一套开箱即用的Hadoop大数据生态监控仪表盘集合面向大数据运维工程师、平台开发人员及集群管理员解决Hadoop组件如HDFS、YARN、HBase、Kafka等多维度性能指标可视化难、监控模板搭建成本高的问题。压缩包为64KB的ZIP文件共含14个JSON格式的Grafana Dashboard配置文件覆盖总览、HDFSNameNode/DataNode、YARNResourceManager/NodeManager、HBaseHMaster/RegionServer、Kafka、EMQ、Solr及Prometheus数据源对接等核心模块每个JSON对应独立组件或层级视图结构清晰、命名规范便于按需导入与权限隔离。已有373人学习下载用户仅需在Grafana中配置好JMX或Metrics2对接的Prometheus等数据源即可一键导入并实时查看存储利用率、任务调度状态、服务健康度、资源消耗趋势等关键指标显著降低监控体系部署门槛提升集群异常响应效率与日常巡检效能。 如果你手头管着一套 Hadoop 集群每天最头疼的事大概就是集群到底健康不健康NameNode 什么时候会满DataNode 是不是悄悄挂了一台YARN 资源够不够跑下一批任务这些问题的答案与其靠 SSH 上去敲命令一项项看不如直接拉一个 Grafana Dashboard 总览。这篇文章我就把给 Hadoop 大数据组件做监控 Dashboard 的整套思路、踩坑和分析过程讲透从指标采集到面板落地全走一遍照着做能省下不少盲人摸象的时间。这话不是空谈。我之前在一个测试集群上搭过完整的一套 Hadoop Prometheus Grafana 监控链路从 HDFS 的容量变化到 YARN 的作业调度全都可视化出问题一眼就能定位。文章适合刚入门 Prometheus 和 Grafana 的人也适合那些已经装了 Hadoop 但一直没做监控、想抄一套作业的兄弟。1. 监控方案选型与整体设计思路1.1 为什么选 Prometheus Grafana而不是用自带 UIHadoop 生态自己其实带了不少监控界面NameNode 的 Web UI 能看容量和节点状态YARN ResourceManager 的 UI 能看应用和队列JobHistory 能看跑过的作业。但问题在于这些界面是各管各的你没法在一个页面上同时看 HDFS 容量、DataNode 存活数和 YARN 资源水位更没法做横向关联和告警。真出问题的时候你得同时开三四个标签页来回切效率很低。相比之下Prometheus Grafana 的组合是目前社区里最主流的开源监控路径。Prometheus 负责定时拉取各个组件的指标并存储Grafana 负责把指标变成可视化的面板和告警规则。这套组合的优势是轻量、无侵入、指标模型统一都是 key-value 加标签的时间序列而且 Grafana 面板的生态足够成熟Hadoop 相关的 Dashboard JSON 模板也不少可以直接导入改改。另一个对比对象是 Ambari 或 Cloudera Manager 这种老牌管理平台。它们功能全但体系重Ambari 已经停止维护了CM 的社区版能力受限。真要给一个 10 台以内的小集群做轻量化监控Prometheus Grafana 是性价比最高的选择。1.2 监控数据链路长什么样整套监控链条可以分成四层被监控对象、指标暴露层、指标采集层、可视化和告警层。被监控对象就是 Hadoop 集群里的各个 Java 进程包括 NameNode、DataNode、ResourceManager、NodeManager 这些。它们大多数通过 JMXJava Management Extensions暴露运行时的内部状态比如堆内存、垃圾回收情况、HDFS 容量、DataNode 存活数、YARN 队列资源等。指标暴露层要做的事就是把 JMX 接口里这些Java 风格的指标转换成 Prometheus 能抓取的文本格式。这里我选了 JMX Exporter用 Java agent 的方式跟着 Hadoop 进程一起启动。简单说它是个 jar 包你在 Hadoop 进程的启动参数里加一行-javaagent:xxx.jar端口:配置文件这个进程就会在指定端口上额外开一个 HTTP 服务把 JMX 指标翻译成 Prometheus 的 metrics 格式。指标采集层就是 Prometheus 服务本身。它通过配置好的scrape_configs定期去抓取每个 exporter 端口上的指标存进内置的时间序列数据库并支持通过 PromQL 查询。可视化层就是 Grafana。它把 Prometheus 当作数据源用 PromQL 表达式把指标变成图形面板。这一层还负责告警规则的配置比如 DataNode 掉线超过 5 分钟就报警。整体链路就是这样Hadoop 的 Java 进程 —JMX Exporter— HTTP metrics 端口 —Prometheus 定期抓取— 时间序列存储 —PromQL 查询— Grafana Dashboard 和 Alert。1.3 采集方案选型JMX Exporter 和其他路线的对比在决定用 JMX Exporter 之前我其实对比过两条别的路线第一条是直接抓 Hadoop 自带的 HTTP JSON 接口。NameNode 在 Hadoop 3.x 里暴露了/jmx端点访问就能拿到一坨 JSON 格式的指标数据。但 Prometheus 原生不支持抓 JSON必须自己写个中间层转格式或者用 pushgateway 推。自定义代码意味着要维护、要处理 JSON 字段变动有点得不偿失。第二条是 node_exporter 加黑盒探针的方式。这个思路是只监控主机层面的 CPU、内存、磁盘而不是监控 Hadoop 组件本身的内部指标。它适合做基础资源监控但你会发现 HDFS 容量利用率、YARN 内存水位、DataNode 存活数这些关键信息拿不到监控深度不够。综合下来JMX Exporter 是社区里对 Java 应用监控最成熟的方案。它的 agent 模式不用改 Hadoop 代码只要在启动脚本里加参数注册 MBean 的指标就会被自动暴露出来。缺点是如果 Hadoop 版本升级MBean 名称可能有变动需要同步调整配置文件的 whitelist。2. 环境准备从 Hadoop 到 Prometheus 的完整链路搭建2.1 Hadoop 集群准备与监控对象确认在动手配监控之前得先确认 Hadoop 集群是能跑的。我这里用的是 Hadoop 3.3.4 版本跑了 1 个 NameNode、3 个 DataNode外加一个 ResourceManager 和一个 NodeManager分布在同一网段的几台机器上。无论你是伪分布式还是全分布式监控思路是一样的对每个需要监控的 Java 进程配置一个 exporter 端口。有一点必须搞清楚Hadoop 3.x 和 2.x 的 Web UI 端口是不一样的。NameNode 在 Hadoop 2 里是 50070在 Hadoop 3 里是 9870ResourceManager 从 8088 变成了 8088这个没变但有的版本也会配置在别的端口。我一开始用 50070 去访问 NameNode 的 UI结果打不开还以为是服务挂了后来才发现是版本差异导致的端口变化。这个在排错时要格外注意。Hadoop 集群里需要重点监控的 Java 进程我列了一个清单角色进程关注的核心指标NameNode管理元数据容量使用率、文件数、块数、GC、RPC 延迟DataNode存储块数据磁盘容量、心跳状态、节点存活ResourceManager资源调度可用内存/核数、运行中应用数、队列状态NodeManager单节点资源管理容器数、节点内存/CPU 使用、健康状态JobHistory作业历史已完成/失败作业数、提交时间分布这张表决定了后面 Dashboard 上要画哪些面板指标采集也要围绕这几个进程展开。2.2 用 JMX Exporter 给 Hadoop 进程开指标端口先下载 JMX Exporter 的 jar 包我用的是jmx_prometheus_javaagent-0.20.0.jar。然后写一个 Hadoop 专用的配置文件控制哪些 MBean 要暴露给 Prometheus。配置文件大概长这样lowercaseOutputName: true lowercaseOutputLabelNames: true whitelistObjectNames: - Hadoop:*whitelistObjectNames是白名单只允许 Hadoop 相关的 MBean 被导出。lowercaseOutputName和lowercaseOutputLabelNames是把指标名和标签名转成小写方便后面写 PromQL 查询。如果你担心指标太多可以在这里精确到具体的 MBean 名称例whitelistObjectNames: - Hadoop:nameCapacityTotal,serviceDataNode但为了先把监控跑通用Hadoop:*这种通配更省事。接下来要修改 Hadoop 的启动脚本。在 Hadoop 环境的hadoop-env.sh文件里为不同角色追加 JVM 参数。这里要注意一个细节不同角色的 Java 进程要绑定到不同的端口不能冲突。我的分配是这样的NameNodeHADOOP_NAMENODE_OPTS加上 javaagent暴露在 9001 端口DataNodeHADOOP_DATANODE_OPTS加上 javaagent暴露在 9002 端口ResourceManagerHADOOP_RESOURCEMANAGER_OPTS加上 javaagent暴露在 9003 端口NodeManagerHADOOP_NODEMANAGER_OPTS加上 javaagent暴露在 9004 端口具体到hadoop-env.sh里的写法示例HADOOP_NAMENODE_OPTS-javaagent:/opt/jmx_prometheus_javaagent-0.20.0.jar9001:/opt/hadoop_jmx_config.yaml $HADOOP_NAMENODE_OPTS HADOOP_DATANODE_OPTS-javaagent:/opt/jmx_prometheus_javaagent-0.20.0.jar9002:/opt/hadoop_jmx_config.yaml $HADOOP_DATANODE_OPTS HADOOP_RESOURCEMANAGER_OPTS-javaagent:/opt/jmx_prometheus_javaagent-0.20.0.jar9003:/opt/hadoop_jmx_config.yaml $HADOOP_RESOURCEMANAGER_OPTS HADOOP_NODEMANAGER_OPTS-javaagent:/opt/jmx_prometheus_javaagent-0.20.0.jar9004:/opt/hadoop_jmx_config.yaml $HADOOP_NODEMANAGER_OPTS改完脚本后重启 Hadoop 集群让参数生效。然后逐个检查端口是否正常输出指标。比如检查 NameNodecurl http://localhost:9001/metrics | head -n 20能看到hadoop_开头的一大串指标就说明 agent 生效了。这里常见的坑是hadoop-env.sh里多个角色共用同一段变量导致 javaagent 只加在一个进程上。所以每改一个角色都要单独确认对应端口通了再往下走。2.3 Prometheus 安装与 Target 配置Prometheus 的安装本身不复杂下载二进制包或者用容器跑都行。我为了图省事直接用的容器运行把配置目录挂载出来docker run -d --name prometheus \ -p 9090:9090 \ -v /data/prometheus/prometheus.yml:/etc/prometheus/prometheus.yml \ -v /data/prometheus/data:/prometheus \ prom/prometheus:v2.47.0关键在prometheus.yml里的抓取配置。要给刚才那几个 Hadoop 角色的 exporter 端口加上 job。我贴一份实际能用得配置global: scrape_interval: 15s evaluation_interval: 15s scrape_configs: - job_name: hadoop_namenode static_configs: - targets: [namenode-host:9001] labels: role: namenode - job_name: hadoop_datanode static_configs: - targets: - datanode1-host:9002 - datanode2-host:9002 - datanode3-host:9002 labels: role: datanode - job_name: hadoop_resourcemanager static_configs: - targets: [rm-host:9003] labels: role: resourcemanager - job_name: hadoop_nodemanager static_configs: - targets: [datanode1-host:9004, datanode2-host:9004, datanode3-host:9004] labels: role: nodemanagerscrape_interval我设成了 15 秒。Hadoop 的监控指标变化频率不高15 秒足够了太短会给集群带来不必要的额外压力太长告警又不够及时15 秒是折中的值。配置完成后重启 Prometheus去http://prometheus-host:9090/targets页面看 Targets 状态。Status 为 UP 的说明抓取正常DOWN 的就要检查网络、端口和防火墙。3. Grafana 接入与 Dashboard 落地3.1 Grafana 安装与数据源配置Grafana 同样用容器跑命令很简单docker run -d --name grafana \ -p 3000:3000 \ -e GF_SECURITY_ADMIN_PASSWORDadmin123 \ -v /data/grafana:/var/lib/grafana \ grafana/grafana:10.2.0初始用户名密码默认是 admin/admin登录后第一件事就是添加 Prometheus 数据源。路径是Configuration - Data Sources - Add data source - Prometheus。在 HTTP URL 里填 Prometheus 的地址比如http://prometheus-host:9090填完点 Save Test显示 Data source is working 就说明连接成功了。这一步最容易踩的坑是网络互通问题。如果 Grafana 和 Prometheus 都跑在容器里URL 不要写localhost要写宿主机 IP 或者容器网络里的服务名。我在 Docker 模式下直接用http://宿主机IP:9090才通过。3.2 导入现成的 Dashboard 还是自己从零搭Grafana 的社区模板库grafana.com/dashboards里针对 Hadoop 的成熟模板其实不算多质量也参差不齐。我试过几个有的模板用到的指标名和当前版本不匹配导入后全是空面板。比如有的模板用的是hadoop_namenode_capacity_total而我实际的指标名是hadoop_namenode_fsnamesystemstate_capacitytotal差了很远。所以我的建议是先导入一个模板当参考再结合自己的指标名做二次修改。第一次搭的话与其花大量时间找一个完美模板不如自己从零拉一个精简版 Dashboard把 HDFS、YARN 的核心指标各画几个面板跑通链路后再逐步丰富。这样对指标的理解也更扎实。自己建 Dashboard 不用写太多额外的东西靠 Grafana 的 Panel 编辑器和 PromQL 查询就够。下面我拆解一下我建的几个核心面板和它们的查询逻辑。3.3 核心面板设计与 PromQL 查询示例HDFS 容量使用率是第一个必须要画的面板。NameNode 的 JMX 指标里会有CapacityUsed和CapacityTotal经过 JMX Exporter 转出来后在 Prometheus 里对应的指标名一般是hadoop_namenode_fsnamesystemstate_capacityused和hadoop_namenode_fsnamesystemstate_capacitytotal。可以用一个表达式同时查出容量使用总览sum(hadoop_namenode_fsnamesystemstate_capacityused) / sum(hadoop_namenode_fsnamesystemstate_capacitytotal) * 100这是百分比形式的容量使用率。为了更直观我一般会把使用量、剩余量、总量放在同一个时间序列图里sum(hadoop_namenode_fsnamesystemstate_capacityused)sum(hadoop_namenode_fsnamesystemstate_capacityremaining)sum(hadoop_namenode_fsnamesystemstate_capacitytotal)这样能一眼看出磁盘增长趋势。DataNode 存活情况是另一个关键面板。NameNode 的指标里提供了NumLiveDataNodes和NumDeadDataNodes对应查询是hadoop_namenode_fsnamesystemstate_numlivedatanodes实际上如果我有 3 个 DataNode这个值正常就是 3一旦降到 2 甚至更低说明有节点掉线了。我通常会做一个 Stat 类型的 Panel直接展示当前存活数再叠加一个hadoop_namenode_fsnamesystemstate_numdeaddatanodes来显示掉线节点数。两个数字放在一块集群健康状态一目了然。NameNode 自身的 JVM 堆内存和 GC 情况也值得监控。JMX Exporter 会导出 JVM 的jvm_memory_bytes_used、jvm_gc_collection_seconds这类指标。NameNode 的堆内存使用如果长期冲高很可能说明元数据快扛不住了。查询示例sum(jvm_memory_bytes_used{areaheap}) / sum(jvm_memory_bytes_max{areaheap}) * 100YARN 侧我主要关注两个指标集群可用内存和运行中的应用数。ResourceManager 的指标里hadoop_resourcemanager_clustermetrics_availablemb表示可用内存hadoop_resourcemanager_clustermetrics_allocatedmb表示已分配内存两者加起来约等于集群总内存。查询hadoop_resourcemanager_clustermetrics_allocatedmbhadoop_resourcemanager_clustermetrics_availablemb运行中的应用数则是一个关键信号如果数值居高不下或排队积压说明资源不够或者任务有问题hadoop_resourcemanager_clustermetrics_apps_running3.4 Dashboard 布局与变量设置面板建好后我还建议做一件事配置 Dashboard 的全局变量让面板可以按集群或节点筛选。比如在 Dashboard 的 Settings - Variables 里加一个role变量取值来自指标里的 labelquery: label_values(up, role)这样你就可以在图表的右上角下拉切换只看 DataNode 或只看 NameNode复用同一套面板处理多角色指标管理起来很清爽。变量设置的本质是把 label 当作动态过滤器后续所有面板的查询里都可以用$role引用。比如一个节点状态面板查询up{role$role}切到 DataNode 时自动展示所有 DataNode 的状态。这个技巧在管理几十个节点时尤其有用不用重复建几十个一样的面板。4. 指标体系构建与告警规则配置4.1 Hadoop 关键监控指标分类与含义搭建 Dashboard 不能只停留在画几个图上。监控的价值很大程度取决于你对指标背后的业务含义是否清楚。我把 Hadoop 集群的监控指标分为四类第一类是容量与存储指标。包括 HDFS 总容量、已使用容量、剩余容量、块大小、副本数等。这类指标主要来自 NameNode反映了整个分布式存储系统能存多少数据、还剩多少空间。容量使用率一旦超过阈值会直接影响新文件的写入所以这是最基础的告警对象。第二类是元数据与 NameNode 健康指标。比如当前文件数、目录数、Block 数、NameNode 堆内存使用率、GC 次数和耗时。NameNode 是整个 HDFS 的大脑所有文件操作都要经过它一旦 GC 时间过长所有客户端都会卡住。我曾经遇到过一次 GC 暂停导致全集群写文件超时的故障当时监控面板上 GC 耗时曲线直接冲高一下子就定位了问题。第三类是节点存活与负载指标。DataNode 是否活着、各节点磁盘是否均衡、NodeManager 资源使用率、运行中的容器数量。这类指标能反映集群是否健康地工作。有个隐蔽的坑是某一台 DataNode 的磁盘满了NameNode 会把它标记为不健康但集群整体容量看着没问题。如果不监控单节点磁盘这个风险很难被察觉。第四类是任务与调度指标。运行中的应用数、提交的应用数、失败的作业数、队列资源使用情况。这类指标来自 ResourceManager 和 JobHistory反映了集群资源是否被充分用起来、任务是否在正常推进。在调度算法复杂、队列多的场景里这类指标还能帮你做资源分析和优化。4.2 如何配置 Grafana 告警规则面板建好之后下一步是配告警。Grafana 从 8.0 开始支持基于 Prometheus 数据源的告警规则而且不只是对图表告警而是基于查询结果做阈值判断。具体的操作入口是 Alerting - Contact points 配置通知渠道邮件、企业微信、钉钉都行然后在 Alert rules 里创建规则。一个典型的 DataNode 掉线告警规则是这样设的条件hadoop_namenode_fsnamesystemstate_numlivedatanodes小于期望值 3持续 5 分钟触发后发送告警到企业微信机器人严重级别设为 Warning容量使用率告警我也配了条件sum(hadoop_namenode_fsnamesystemstate_capacityused) / sum(hadoop_namenode_fsnamesystemstate_capacitytotal) * 100 85持续 15 分钟级别设为 Critical通知给运维群这里要注意告警阈值和持续时长的关系。阈值设得太灵敏可能因为瞬时抖动产生大量误报持续性设置过长又会导致真实故障不能及时被发现。我个人的经验是容量类告警阈值设在 80% 提醒、90% 紧急持续 10~15 分钟避免波动干扰节点存活类告警则要更快5 分钟没恢复就触发因为节点掉线后 HDFS 可能需要触发数据块的复制恢复越快介入越好。4.3 指标血缘关系与监控复盘监控搭好不是终点我每过一两个月会做一次监控复盘。复盘的方式是把最近一次集群异常回放一遍看当时的告警、面板曲线和实际日志的对应关系找找监控盲区。有一次复盘发现YARN 堆内存使用率持续走高但现有的告警规则里根本没有覆盖这个指标。于是补了一条规则后来真的在一批大作业提交前先收到了预警算是提前排掉了一个雷。指标血缘关系这个概念也许稍微抽象但理解它很有用。简单说就是弄清楚哪个上层指标下降可能是哪个底层指标导致的。比如 HDFS 写入变慢可能是 NameNode RPC 延迟升高、也可能是 DataNode 所在磁盘 IO 饱和、还可能是网络带宽被打满。在 Dashboard 上把相关面板放得靠近一些并建立告警的关联规则排障时就能按图索骥而不是东翻西找。5. 常见问题与排障心得5.1 端口和指标名不一致导致面板空白我在搭建过程中遇到的第一个典型问题是Prometheus 的 Target 状态明明是 UP但 Grafana 面板上就是没有数据。排查下来发现是指标名对不上。我用curl http://localhost:9001/metrics看了实际输出的指标发现有的 MBean 经过 JMX Exporter 转换后指标名和我找的模板完全不一样。比如 HDFS 容量已经用过但模板里写的是hadoop_namenode_capacitytotal而我这里实际是hadoop_namenode_fsnamesystemstate_capacitytotal。这个差异是因为 MBean ObjectName 的后缀路径不同。解决办法是在 Prometheus 里用curl去搜索指标curl -s http://prometheus-host:9090/api/v1/label/__name__/values | tr , \n | grep hadoop_namenode把实际指标名拉出来再回 Grafana 逐个替换。这里没有捷径指标名必须与当前环境匹配。5.2 Hadoop 重启后 exporter 端口没有起来另一个麻烦是修改hadoop-env.sh后重启集群角色进程能起来但是 exporter 端口却连不通。我排查后问题出在*_OPTS变量覆盖。比如在hadoop-env.sh里如果后面有其他脚本对HADOOP_NAMENODE_OPTS整体赋值就会把 javaagent 参数覆盖掉。解决办法是在文件底部追加配置或者在HADOOP_NAMENODE_OPTS后面加上$HADOOP_NAMENODE_OPTS这种拼接方式保留原值。最直接的验证方式是看进程启动参数ps aux | grep NameNode | grep javaagent只要进程里能看到-javaagent片段就说明参数加上了剩下的就是端口监听是否正常。5.3 Prometheus 文件存储增长过快这个不算故障但值得提醒。Prometheus 会把采集到的时间序列数据按块存储默认保留 15 天。如果 Hadoop 集群规模大、监控指标多Prometheus 的磁盘占用会涨得很快。我给集群做了很多 whitelist 通配导出后Prometheus 的 data 目录在两周内涨了将近 20GB。应对方法有两个一是优化指标导出白名单只保留真正需要监控的 MBean去掉无关的 JVM 细节二是在 Prometheus 启动参数里调整--storage.tsdb.retention.time15d控制保留周期。两者配合能让存储增长大头降下来。尤其是对指标量大的大数据集群别让监控系统本身成了新的存储负担。5.4 Grafana 告警通知没有送达告警规则配好了测试的时候却始终收不到消息。排查路径是先看 Alerting - Alert rules 里规则的状态有没有从 Pending 变成 Firing。如果一直是 Pending说明 condition 还没满足或者持续时长没到。如果能变成 Firing 但通知没发那问题就在 Contact points 的配置上比如企业微信机器人的 webhook 地址是否正确、URL 是否被网络隔离。另一个坑是 Grafana 默认不会对无数据的状态做告警。比如hadoop_namenode_fsnamesystemstate_numlivedatanodes这个查询如果 Prometheus 里完全没数据Grafana 不会触发告警面板上也看不到数值。要避免这个问题可以把查询的 NULL 值当成 0 处理或者在告警条件里加上$NODATA的专门判断。这一点很容易被忽略但在实际排障时特别重要。6. 后续还能怎么扩展这套监控链路跑通之后扩展方向其实很自然。我目前已经加了 node_exporter 来采集每个节点的 CPU、内存、磁盘、网络指标这样 Grafana 里既能看 Hadoop 组件状态也能看主机资源水位。下一步计划通过 Prometheus 的 service discovery 机制自动发现新加入的 DataNode不用每次扩机器都手动改配置文件。如果你还在跑 Hive、Spark、Flink 这套上层组件同样可以用 JMX Exporter 或专门的 Exporter 把它们接进来。比如 Flink 的 Rest API 可以暴露 metricsSpark 的 History Server 也能通过 Prometheus PushGateway 提交指标。接进来之后一个 Grafana 实例就能把整个大数据平台的状态统一管理起来省去在各个组件的 UI 之间反复切换的麻烦。我个人在实际操作中的体会是搭监控面板不算难难的是理解每个指标背后的含义、知道哪些指标真正影响服务质量。做这套 Hadoop 监控 Dashboard让我最大的收获不是 Grafana 本身的使用技巧而是逼着我把 NameNode、DataNode、ResourceManager 的工作原理和关键参数都梳理了一遍。很多之前模糊的、只知道大概有用的参数现在能准确说出它变化意味着什么。要是有时间你也可以从零开始把这些面板亲手搭一遍踩几个坑比看一百篇教程都管用。本文还有配套的精品资源点击获取