简介：一套面向 Hadoop 生态系统的 Grafana 监控仪表盘模板，适合大数据运维工程师、平台管理员以及需要掌握集群健康状态的开发人员。资源围绕 HDFS、YARN、HBase、Hive、Kafka、Spark、ZooKeeper 等核心组件预置了多个 JSON 仪表盘，可快速导入 Grafana，配合 Prometheus 或 JMX Exporter 等数据源，直观呈现磁盘利用率、任务运行状态、内存与 CPU 消耗、消息积压、Region 分布等关键指标，帮助运维团队第一时间发现热点与瓶颈，提升集群可观察性和管理效率。压缩包为 zip 格式，体积仅 54KB，共包含 14 个 json 文件，每个文件对应一个组件或子模块的仪表盘定义，例如 NameNode、DataNode、ResourceManager、NodeManager、HMaster、RegionServer 等，结构清晰，可直接复用或在此基础上扩展。已有 4453 人学习下载，适合正在搭建 Hadoop 监控体系、希望用现成模板缩短配置周期的大数据运维人员。
1. Hadoop监控的最后一公里：Grafana模板解决的可视化缺口
凌晨两点，某公司的大数据平台调度任务批量失败，根因是HDFS容量使用率在十分钟之内冲上95%，NameNode直接进入安全模式。事后复盘时发现Prometheus其实早就把指标抓回来了，问题出在监控大盘一直停留在手工搭的半成品状态——这是很多用Hadoop集群的团队的常态：采集端齐全，缺的是一块打开就能看懂集群健康状况的面板。基于Hadoop监控的Grafana模板，解决的正是这个可视化缺口。它把HDFS容量、块副本健康度、DataNode在线状态、YARN资源分配与作业排队等核心指标组织成现成的看板，导入即可使用，省去从零画图、配变量、调PromQL的重复劳动。适合已经在用Prometheus + Grafana监控Hadoop集群，但没有专职专家去打磨面板的运维工程师和大数据平台开发者。
2. 模板背后的数据链路：JMX指标、Prometheus抓取与面板映射关系
2.1 为什么是Prometheus + JMX Exporter而不是直接怼Grafana
在开始导入模板之前，必须先把数据链路捋清楚。很多人在Grafana模板上踩的第一个坑，就是把可视化层和数据采集层混为一谈——模板只是最上面那层皮，它本身不产生数据；面板上的每一根曲线，背后都是一条PromQL查询，而这些查询对应的指标，必须靠Prometheus从Hadoop的JMX接口抓出来。
这个模板对应的最通用链路是：Hadoop自身通过JMX暴露MBean，JMX Exporter以javaagent方式挂到NameNode、DataNode、ResourceManager进程里，把MBean转成Prometheus文本格式；Prometheus按抓取周期拉取并存储；Grafana再通过模板中的PromQL做查询和绘图。这套组合几乎是社区里最常见的选择，因为HDFS和YARN的核心运维指标本就聚集在JVM进程的JMX接口上，没有比JMX更直接的获取通道。
你可能会问，为什么不用Telegraf或者自定义Shell脚本采集？Telegraf对Hadoop生态的老版本兼容性不够好，很多自定义MBean的字段名在不同发版之间会变，写采集器时容易变成“追着版本调配置”；而Shell脚本拉取JMX信息再做文本转换，数据格式和字段解析全靠自己实现，出错时排查成本更高。相比之下，JMX Exporter用一段YAML规则就能完成MBean到指标名的映射，模板在使用时只需要关注最后的指标名是否与规则文件一致，这中间的认知负担是最小的。
我一般会在测试环境里先用最小配置把这条链路跑通，再谈模板导入。判断标准很简单：在Prometheus的Graph页面里能查到一个典型的HDFS指标，比如hadoop_namenode_fsnamesystem_capacityused_bytes有值，说明链路通了；如果这个指标都查不到，模板导入得再漂亮也是白搭。
2.2 模板JSON结构拆解：面板、行、变量与数据源锚点
拿到这份Grafana模板，本质上拿到的是一个JSON对象，它描述了整张看板的布局、每个面板的查询、变量定义和图表类型。理解这个JSON结构，不只是为了导入，更是为了后面排查问题和改参数时不至于抓瞎。
一个典型的Hadoop监控仪表板JSON，骨架是这样的：
{ "dashboard": { "title": "Hadoop Cluster Monitoring", "refresh": "30s", "panels": [ { "title": "HDFS Capacity Used", "type": "timeseries", "gridPos": {"x": 0, "y": 0, "w": 12, "h": 8}, "targets": [ { "expr": "hadoop_namenode_fsnamesystem_capacityused_bytes / hadoop_namenode_fsnamesystem_capacitytotal_bytes * 100", "legendFormat": "{{instance}}" } ], "fieldConfig": { "defaults": { "unit": "percent", "thresholds": [ {"color": "green", "value": null}, {"color": "yellow", "value": 75}, {"color": "red", "value": 85} ] } } } ], "templating": { "list": [ { "name": "instance", "type": "query", "query": "label_values(hadoop_namenode_fsnamesystem_capacityused_bytes, instance)" }, { "name": "cluster", "type": "query", "query": "label_values(hadoop_namenode_fsnamesystem_capacityused_bytes, cluster)" } ] } } }代码里最核心的几段就在上面。面板的查询语句放在targets.expr里，变量定义放在templating.list里，这两个地方是后续适配的重点。模板里的数据源锚点通常是一个叫datasource的变量，或者在面板的datasource字段里写死的值，导入时Grafana会弹窗让你重新选择，这一步千万不能省——很多人导入后一片空白，就是因为这一步选了默认的Grafana内置数据源，而不是真正的Prometheus实例。
gridPos控制面板在画布上的位置和宽高，w是12表示占半行，w是24表示整行。fieldConfig里的unit控制数值单位，HDFS容量的单位设置成bytes，百分比曲线的单位设置成percent，单位搞错之后曲线数值看起来会非常奇怪，这一点我放到第五部分展开说。
refresh建议保持30s或1m。Hadoop集群监控的指标变化节奏是分钟级的，刷新频率设成5s除了增加Prometheus的查询压力，不会带来任何可感知的实时性提升。
变量部分需要特别注意type字段。模板里常用的有两种变量类型：query类型会执行一个PromQL来填充下拉框，比如label_values(hadoop_namenode_fsnamesystem_capacityused_bytes, instance)，它会把指标中所有的instance标签值收集起来供切换；interval类型则用于设置时间范围步长，一般会自动继承Grafana的默认配置。自定义变量时，尽量避免用constant类型，因为它无法跟随集群的指标标签变化。
2.3 模板的面板分层逻辑：集群总览、HDFS、YARN、主机节点
模板的面板排布不是随便画的，一般按四个维度分层：集群总览、HDFS、YARN、主机节点。
总览这行放的是“一眼看出集群有没有病”的图，比如活动DataNode数量、NameNode状态、整体容量使用率。HDFS维度下钻到块健康、小文件比例、NameNode堆内存这些细节。YARN维度则关注活跃App数、挂起App数、已分配与可用内存、Container状态。主机节点维度通常复用Node Exporter的指标，但模板里会刻意做成与HDFS/YARN联动——选定了某个节点后，下方图表自动过滤到该节点的CPU、内存、磁盘IOPS。
这几层之间的跳转关系在模板里是通过变量或者链接实现的。总览面板的数值如果出现异常，点击某个具体区域可以带着过滤条件跳转到对应的明细面板；如果模板没有做这样的下钻链接，你也可以在Dashboard Settings的Links里补上。这个小功能在排障时非常省事，否则每次都要手动切到对应面板再重新选变量。
这套分层逻辑的好处在于排障路径清晰。线上出问题时，我的习惯是先看总览确认故障范围，再看具体维度缩小排查目标。如果总览正常但任务还是失败，那就跳到YARN面板看队列资源是否被某个作业占满；如果HDFS面板显示数据块副本数低于预期，才需要下钻到具体DataNode看是否掉线。模板把这条路径固化在面板布局里，后续用起来效率会高出不少。
3. 让模板跑起来：从零导入Hadoop监控Grafana模板
3.1 准备工作：Prometheus抓取Hadoop JMX指标的配置
先解决采集端。假设NameNode运行在nn-01这台机器上，JMX Exporter暴露的端口是9088；DataNode每台机器上暴露9089；ResourceManager暴露9087。实际端口以你的JMX Exporter启动参数为准，模板本身不关心端口号，只关心抓取到的指标名。
JMX Exporter接入NameNode进程时的启动参数大致是这样，需要加到Hadoop的启动脚本环境变量里：
export HADOOP_NAMENODE_OPTS="$HADOOP_NAMENODE_OPTS -javaagent:/data/jmx/jmx_prometheus_javaagent.jar=9088:/data/jmx/hdfs_namenode.yaml"这里的核心参数有三个：javaagent的jar包路径、端口号、规则文件路径。规则文件负责把Hadoop的MBean名字映射成Prometheus指标名，我一般会在里面写一组通用映射，比如：
rules: - pattern: 'Hadoop<service=NameNode, name=FSNamesystem><>(.*)' name: hadoop_namenode_fsnamesystem_$1 type: GAUGE - pattern: 'Hadoop<service=DataNode, name=DataNodeInfo><>(.*)' name: hadoop_datanode_datanodeinfo_$1 type: GAUGE - pattern: 'Hadoop<service=ResourceManager, name=ClusterMetrics><>(.*)' name: hadoop_resourcemanager_clustermetrics_$1 type: GAUGE这段规则的作用是把NameNode的FSNamesystem MBean里的CapacityUsed、UnderReplicatedBlocks这些属性，映射成hadoop_namenode_fsnamesystem_capacityused这种指标名。DataNode和ResourceManager同理。type都设成GAUGE是因为这些属性大多是瞬时值，不需要做速率计算。
接下来在Prometheus的scrape_configs里加上抓取任务：
scrape_configs: - job_name: 'hadoop-hdfs' static_configs: - targets: ['nn-01:9088', 'dn-01:9089', 'dn-02:9089', 'dn-03:9089'] labels: cluster: production - job_name: 'hadoop-yarn' static_configs: - targets: ['rm-01:9087'] labels: cluster: production这段配置的作用是让Prometheus每15秒（默认）向这些JMX Exporter端点抓一次指标。cluster这个标签是模板变量里的关键——模板里很多面板的PromQL都带cluster=~"$cluster"这种过滤条件，如果你没在抓取配置里加这个标签，导入模板之后所有变量的下拉框都会是空的。
这里要注意，DataNode是分布式角色，每个节点都必须加进targets。漏掉一个，对应的节点在模板面板上就直接消失，不会报错，很容易被忽略。我一般在写进配置之前会用curl先验证一下每个端点的输出：
curl -s http://nn-01:9088/metrics | head -20看到一行行以hadoop_开头的指标输出，说明这个节点的JMX Exporter正常。如果curl没有输出或者连接拒绝，先查Exporter的进程日志，通常是JMX端口监听地址写成了127.0.0.1，导致远程抓不到。
3.2 导入模板JSON并绑定数据源
Prometheus抓取配置完成后，等它跑两三个抓取周期，就能在Prometheus的Graph页面上验证hadoop相关指标是否有值了。然后进入Grafana，按以下步骤导入模板：
- 左侧菜单进入Dashboards，点击New，选择Import。
- 上传模板JSON文件，或者直接把JSON内容粘贴进输入框。
- 在选项面板里选择目标Prometheus数据源，点击Import完成导入。
导入完成后直接切到仪表板页面看效果。如果前面抓取配置没问题，HDFS总览面板应该已经出图了。这里有一个很容易忽视的点：导入时Grafana会让你重新分配数据源，但面板里的PromQL可能用到了变量来过滤数据源，这种情况下必须确保下拉框里选中的是真正的Prometheus，而不是Grafana内置的伪造数据源或其它类型数据源。
如果导入后仍然显示No data，先别急着改模板。到Grafana的Explore页面手动跑一条面板里的PromQL，比如：
hadoop_namenode_fsnamesystem_capacityused_bytesExplore里如果有曲线，说明数据链路是通的，问题出在模板的变量过滤条件上；如果Explore里也查不到，那问题在采集端或者指标名不一致，需要回到Prometheus里排查。这个排查顺序我每次都用，能省下大量对着模板找问题的时间。
3.3 模板变量与集群环境不一致时的快速适配
模板导入后，最常见的适配工作是处理变量。所谓变量，就是看板右上角那些下拉框——集群名、实例地址、队列名等。在模板JSON里，变量类型通常是query，它靠label_values()函数从Prometheus的指标里动态拉取值。举例来说：
{ "name": "instance", "type": "query", "query": "label_values(hadoop_namenode_fsnamesystem_capacityused_bytes, instance)" }这个变量的值来自hadoop_namenode_fsnamesystem_capacityused_bytes指标里instance标签的所有取值。如果你的Prometheus配置里没加cluster标签，模板里的cluster变量就会因为查不到对应label而显示为空，进而导致所有依赖该变量的面板查不到数据。这种情况下有两种改法：要么回到Prometheus抓取配置里补上cluster标签并重启Prometheus，要么直接修改模板JSON，把cluster变量的query改成：
{ "name": "cluster", "type": "query", "query": "label_values({__name__=~\"hadoop_.+\"}, cluster)" }这样改是让cluster变量从一个肯定存在的大范围指标集合里取标签值。只要Prometheus端确实收到了带cluster标签的样本，这个变量就能正常填充。但这里有个边界：正则范围拉得太宽，变量下拉框可能混进一些你并不想展示的标签值，比如把环境名写成了production-old这种历史遗留值。权衡之下，我通常优先选择“补全抓取配置里的标签”而不是“改模板里的查询”，因为后者的影响面不容易一眼看全。
4. 面板指标细读：每个图背后该盯的参数与阈值
4.1 HDFS面板：容量、块健康与NameNode视角
HDFS是整个Hadoop集群的地基，这块面板的指标设计通常围绕三个核心：容量水位、块健康度、NameNode运行状态。
容量水位的PromQL在这类模板里几乎都是同一个套路，用CapacityUsed除以CapacityTotal再乘100。这里有一个细节：CapacityTotal是整个集群的存储总量，DataNode扩容或缩容后它都会变化，所以百分比曲线要结合绝对容量值一起看。比如曲线从70%掉到60%，不一定是你删了数据，很可能是加了新的DataNode把分母拉大了。
块健康度指标比较关键。UnderReplicatedBlocks、MissingBlocks、PendingReplicationBlocks三个计数器，正常情况下前两个都应该是0，PendingReplicationBlocks在集群自愈过程中会出现一个很小的数值，那是因为副本数不满足的块正在被复制补齐，这个过程不会持续太久。如果UnderReplicatedBlocks长时间不降，大概率有DataNode离线或者机架感知配置异常。MissingBlocks出现任何一个非零值都值得立刻处理，因为这意味着数据实际丢了。
NameNode的堆内存和GC情况也常在这个面板里。堆内存使用量超过80%且频繁Full GC，需要检查NameNode进程的-Xmx设置，以及集群文件数是否逼近内存上限。很多团队把这个面板当成“看看有没有炸”的晴雨表，但这个晴雨表真正的价值在于提前发现趋势——堆内存曲线每天的峰值在缓慢上涨，往往比突然的Full GC更有预警意义。
4.2 YARN面板：队列资源、作业挂起与Container异常
YARN面板主要盯三件事：资源分配、作业状态、Container生命周期。
资源分配看AllocatedMB和AvailableMB两条曲线的关系。如果AllocatedMB长期贴着集群总内存的95%以上，说明集群资源已经处于饱和状态，此时任何新任务都要排队。模板里还会有队列级别的资源图，比如default队列的PendingApps和AllocatedMB，方便定位是哪个队列在占资源。
作业状态关注ActiveApps和PendingApps。PendingApps一直大于0而ActiveApps没变化，说明有作业在排队等资源，这时候要结合资源分配图判断——是队列Quota设得不够，还是集群确实满了。还有一种情况是ActiveApps很高但CPU利用率很低，这就不是等资源的问题了，而是任务本身卡在别的地方，比如等待锁或外部依赖，YARN层面看起来正常，实际上作业根本没在推进。
Container异常通常反映为Container的失败数或释放数突增。模板里一般会有ContainerLaunchFail或者Container被频繁kill的曲线。被kill的Container如果大多来自同一个App，去查该App是否提交了超出队列限制的资源请求；如果分布在多个App，则优先怀疑节点上的内存或CPU被其他进程占用，导致NodeManager在分配资源时反复失败。
4.3 现场常用阈值一览表
下面这张表写的是我日常值班时参考的经验阈值，不同业务可以适当调整，但方向和量级不会有太大偏差：
| 指标 | 正常范围 | 告警阈值 | 说明 |
|---|---|---|---|
| HDFS容量使用率 | 50%-75% | 整体或单机达到85% | 80%以上就需要评估扩容或清理数据 |
| UnderReplicatedBlocks | 0或趋近0 | 持续大于10超过30分钟 | 副本不足，优先检查DataNode离线情况 |
| MissingBlocks | 0 | 出现任何非零值 | 数据丢失，需要立刻介入恢复 |
| NameNode堆内存使用率 | 50%-70% | 长期高于85% | 关注是否频繁Full GC |
| ActiveApps | 视业务而定 | 持续等于队列最大App数 | 资源阻塞或任务堆积信号 |
| PendingApps | 0或极小 | 持续大于5超过15分钟 | 作业排队过久，结合资源分配图定位 |
| Full GC频率 | 每小时少于2次 | 每小时超过5次 | 进程需要调优或扩容 |
这张表的用途不是让你背下来，而是给模板上每个曲线一个“什么值提醒我开始关注”的锚点。阈值设太松会掩盖问题，设太紧会每天被告警轰炸。我始终认为先按经验值跑两周，再根据集群真实水位微调，才是可持续的做法。
5. 常见问题排查：导入Hadoop Grafana模板会遇到的五个坑
5.1 现象：面板全空，图表提示No data
这是导入模板后最常见的情况，新手几乎必然遇到。原因多数有二：一是数据源没绑定对，二是变量过滤条件把数据全部筛掉了。
排查路径按顺序走：先在Grafana Explore里手动跑模板里的PromQL，如果直接能跑到数据，说明问题在变量层，去检查模板顶部的变量下拉框是否选中了正确的集群和实例；如果Explore里也查不到，回到Prometheus的Targets页面看抓取状态是否UP。这个顺序别跳，跳了就容易把“模板看起来不对”的假象带偏。
解决方法是回到Prometheus配置里确认数据源绑定、变量选择、抓取targets三个点都正确。按我的经验，90%的情况出在抓取端口写错或标签缺失，剩下10%才是模板本身的问题。
5.2 现象：部分节点消失，DataNode面板“少了人”
集群有8个节点，面板上只显示了5个，还没有任何报错。原因一般出在抓取配置漏了节点，或者某个节点的JMX Exporter挂了。模板是按instance标签渲染曲线的，只要Prometheus抓不到某个节点，它的曲线就不会出现在面板上，非常隐蔽。
先检查Prometheus Targets页面确认所有DataNode的targets状态都是UP，再逐个确认每个节点是否都在抓取列表里。如果targets显示DOWN，去对应节点上重启JMX Exporter，并确认端口监听在非回环地址上。这里有个细节：JMX Exporter的hostnameAndPort配置里如果写的是localhost，只能在本地抓取，Prometheus远程拉取必然失败。
5.3 现象：HDFS容量百分比算出来变成了0
面板上容量使用率的曲线一直是0，但绝对容量曲线是正常的。这是单位问题。CapacityUsed和CapacityTotal的指标单位是byte，两个byte相除得到的是0到1的小数。如果模板里忘了乘100，或者图表的unit设置成了percent但实际值是小数，就有可能出现这种“曲线存在但恒为0”的尴尬局面。
解决是在PromQL末尾补上* 100：
hadoop_namenode_fsnamesystem_capacityused_bytes / hadoop_namenode_fsnamesystem_capacitytotal_bytes * 100同时检查面板的fieldConfig里unit是否设置成了percent。我帮某开发者排查过一次，折腾了半天才发现是模板导入时unit被Grafana版本自动重置成了无单位，曲线数值其实正确，但显示成了0到1的小数，看起来就跟0没有区别。另外注意Grafana的unit里percent和percentunit是两个不同选项，前者按0-100显示，后者按0-1显示，别选错。
5.4 现象：主机变量下拉框是空的
看板右上角的instance变量下拉框点开什么都没有，或者只有集群名没有具体节点名。原因是label_values()函数依赖的指标里没有对应的标签。比如模板里写的是label_values(node_uname_info, instance)，如果Prometheus根本就没配置Node Exporter抓取任务，这个变量自然为空。
要么补上Node Exporter的抓取，要么把变量query改成一个肯定存在的指标，比如：
{ "name": "instance", "type": "query", "query": "label_values(hadoop_datanode_datanodeinfo_used_bytes, instance)" }我个人更倾向后者，因为Hadoop场景下面板更关心HDFS和YARN角色节点，用Hadoop自己的指标做变量来源也更贴合主题，还能少部署一套Node Exporter。
5.5 现象：集群一大，仪表板切时间范围就卡死
集群规模超过几百个节点后，把时间范围从1小时拉到24小时，面板要等十几秒甚至更久才出图，操作一次卡一次。原因是指标基数过大。每个DataNode都有一批指标，几百个节点聚合下来，单次查询的数据点数就是几十万级别，再加百分比计算和排序，Prometheus和前端渲染都吃不住。
处理思路分两步。第一步把仪表板的默认时间范围调小，比如从1d改成6h，进入页面时不会一上来就查全量数据。第二步把高频使用的面板里的查询区间改用$__rate_interval这个内置变量，而不是写死的5m或10m，这样Grafana会按仪表板的时间范围和抓取间隔自动计算一个合理的步长，大幅减少返回的数据点数。
我的处理方法是分而治之：能按instance过滤的写法尽量加过滤条件，不要每个面板都做全集群聚合；堆内存这类单点指标单独拆面板，不和集群聚合图混在一起。这两步做完，体感会好很多。
6. 从看板到闭环：用模板指标反推告警规则的实操
6.1 告警规则的事件表达式与分组推送
模板只能告诉你现在发生了什么，告警才是让系统主动联系你的手段。我习惯的做法是直接复制模板里最核心的PromQL，把它们改写成告警规则——模板本身就是一份现成的告警表达式草案。
在Prometheus的rules配置里加一段，比如：
groups: - name: hadoop-alert rules: - alert: HDFSCapacityHigh expr: hadoop_namenode_fsnamesystem_capacityused_bytes / hadoop_namenode_fsnamesystem_capacitytotal_bytes * 100 > 85 for: 10m labels: severity: warning annotations: summary: "HDFS容量使用率超过85%"expr直接复用模板里的PromQL，for设10m是为了避免瞬时抖动触发误报。labels里的severity可以配合告警管理端做分级。
接入告警时，有两种常用路径：一种是Prometheus rules配合Alertmanager，适合已经存在告警体系的团队；另一种直接用Grafana Alerting，在Grafana界面里创建规则并配置通知渠道。两套方案不建议混用，同一个阈值如果要在两处维护，后面改参数时很容易漏掉其中一处。
| 路径 | 维护位置 | 适合场景 |
|---|---|---|
| Prometheus rules + Alertmanager | Prometheus配置目录 | 已有告警基础设施的团队 |
| Grafana Alerting | Grafana界面或API | 告警规则想跟随看板一起管理的团队 |
6.2 模板复用经验：多集群共用一套面板的变量处理
集群数量多起来之后，每套集群都导入一份模板并不现实，最理想的方式是一套面板、多集群共用。
方法是在Prometheus抓取配置里给不同集群打上不同的cluster标签，模板里所有PromQL都带上cluster=~"$cluster"过滤条件，再配合集群变量下拉框实现一键切换。
hadoop_namenode_fsnamesystem_capacityused_bytes{cluster="$cluster"} / hadoop_namenode_fsnamesystem_capacitytotal_bytes{cluster="$cluster"} * 100这个写法的好处是面板布局保持一套，数据随变量切换，新增集群时只需要在Prometheus里增加抓取任务并保留cluster标签，不必再维护一份模板JSON。缺点也明显——如果两套集群的指标命名规范不一致，比如某套集群的NameNode指标用了老版本的自定义MBean名，切换后部分面板仍然会有差异，这时候只能针对个别面板加备用查询兜底，这也是模板适配中最花时间的部分。
从那以后，我每次接新集群的监控，都强制走一遍这套流程：先确认Prometheus抓取指标里有cluster标签，再导入模板，然后在Explore里逐条验证模板核心的PromQL。模板装完不等于监控形成闭环，后续那10%的适配工作量，才是让看板真正贴合你集群规模的关键。希望帮到你。
本文还有配套的精品资源，点击获取
