简介一套面向 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暴露MBeanJMX 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暴露的端口是9088DataNode每台机器上暴露9089ResourceManager暴露9087。实际端口以你的JMX Exporter启动参数为准模板本身不关心端口号只关心抓取到的指标名。JMX Exporter接入NameNode进程时的启动参数大致是这样需要加到Hadoop的启动脚本环境变量里export HADOOP_NAMENODE_OPTS$HADOOP_NAMENODE_OPTS -javaagent:/data/jmx/jmx_prometheus_javaagent.jar9088:/data/jmx/hdfs_namenode.yaml这里的核心参数有三个javaagent的jar包路径、端口号、规则文件路径。规则文件负责把Hadoop的MBean名字映射成Prometheus指标名我一般会在里面写一组通用映射比如rules: - pattern: HadoopserviceNameNode, nameFSNamesystem(.*) name: hadoop_namenode_fsnamesystem_$1 type: GAUGE - pattern: HadoopserviceDataNode, nameDataNodeInfo(.*) name: hadoop_datanode_datanodeinfo_$1 type: GAUGE - pattern: HadoopserviceResourceManager, nameClusterMetrics(.*) 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三个计数器正常情况下前两个都应该是0PendingReplicationBlocks在集群自愈过程中会出现一个很小的数值那是因为副本数不满足的块正在被复制补齐这个过程不会持续太久。如果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%以上就需要评估扩容或清理数据UnderReplicatedBlocks0或趋近0持续大于10超过30分钟副本不足优先检查DataNode离线情况MissingBlocks0出现任何非零值数据丢失需要立刻介入恢复NameNode堆内存使用率50%-70%长期高于85%关注是否频繁Full GCActiveApps视业务而定持续等于队列最大App数资源阻塞或任务堆积信号PendingApps0或极小持续大于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末尾补上* 100hadoop_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直接复用模板里的PromQLfor设10m是为了避免瞬时抖动触发误报。labels里的severity可以配合告警管理端做分级。接入告警时有两种常用路径一种是Prometheus rules配合Alertmanager适合已经存在告警体系的团队另一种直接用Grafana Alerting在Grafana界面里创建规则并配置通知渠道。两套方案不建议混用同一个阈值如果要在两处维护后面改参数时很容易漏掉其中一处。路径维护位置适合场景Prometheus rules AlertmanagerPrometheus配置目录已有告警基础设施的团队Grafana AlertingGrafana界面或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%的适配工作量才是让看板真正贴合你集群规模的关键。希望帮到你。本文还有配套的精品资源点击获取 Hadoop集群监控的Grafana模板：从导入到告警
简介一套面向 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暴露MBeanJMX 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暴露的端口是9088DataNode每台机器上暴露9089ResourceManager暴露9087。实际端口以你的JMX Exporter启动参数为准模板本身不关心端口号只关心抓取到的指标名。JMX Exporter接入NameNode进程时的启动参数大致是这样需要加到Hadoop的启动脚本环境变量里export HADOOP_NAMENODE_OPTS$HADOOP_NAMENODE_OPTS -javaagent:/data/jmx/jmx_prometheus_javaagent.jar9088:/data/jmx/hdfs_namenode.yaml这里的核心参数有三个javaagent的jar包路径、端口号、规则文件路径。规则文件负责把Hadoop的MBean名字映射成Prometheus指标名我一般会在里面写一组通用映射比如rules: - pattern: HadoopserviceNameNode, nameFSNamesystem(.*) name: hadoop_namenode_fsnamesystem_$1 type: GAUGE - pattern: HadoopserviceDataNode, nameDataNodeInfo(.*) name: hadoop_datanode_datanodeinfo_$1 type: GAUGE - pattern: HadoopserviceResourceManager, nameClusterMetrics(.*) 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三个计数器正常情况下前两个都应该是0PendingReplicationBlocks在集群自愈过程中会出现一个很小的数值那是因为副本数不满足的块正在被复制补齐这个过程不会持续太久。如果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%以上就需要评估扩容或清理数据UnderReplicatedBlocks0或趋近0持续大于10超过30分钟副本不足优先检查DataNode离线情况MissingBlocks0出现任何非零值数据丢失需要立刻介入恢复NameNode堆内存使用率50%-70%长期高于85%关注是否频繁Full GCActiveApps视业务而定持续等于队列最大App数资源阻塞或任务堆积信号PendingApps0或极小持续大于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末尾补上* 100hadoop_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直接复用模板里的PromQLfor设10m是为了避免瞬时抖动触发误报。labels里的severity可以配合告警管理端做分级。接入告警时有两种常用路径一种是Prometheus rules配合Alertmanager适合已经存在告警体系的团队另一种直接用Grafana Alerting在Grafana界面里创建规则并配置通知渠道。两套方案不建议混用同一个阈值如果要在两处维护后面改参数时很容易漏掉其中一处。路径维护位置适合场景Prometheus rules AlertmanagerPrometheus配置目录已有告警基础设施的团队Grafana AlertingGrafana界面或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%的适配工作量才是让看板真正贴合你集群规模的关键。希望帮到你。本文还有配套的精品资源点击获取