前天有个朋友微信我说Ambari集群装好大半年了HBase RegionServer的堆内存老是飘每次想看还得登录Ambari UI点进服务、切到Metrics标签页想对比两个组件的指标就得来回切页面。他问我能不能五分钟拉一个监控DEMO出来数据就拿Ambari-Metrics现成的。我第一反应是Grafana那边正好有个Infinity插件能把REST API直接变成数据源不用写后端、不用建库、不用起采集任务十几分钟就能把几个关键指标怼到大屏上。这篇文章就把这条链路完整拆开讲一遍适合正在用Ambari、手头有现成Metrics Collector、又想在Grafana里快速出监控DEMO的运维和开发参考。Ambari-Metrics这套东西其实一直有点“数据很全但展示不够灵活”的尴尬。Ambari自带的UI适合单服务查看但你要是想把几个集群、几个关键指标拉到一个统一看板上或者塞进公司现有的Grafana体系里它就不太够用了。常规做法是自己写采集脚本把指标入库再对接Grafana这个工作量对一个DEMO来说太重。Infinity插件就是用来填补这个空档的它把HTTP请求返回的JSON直接包装成Grafana能识别的数据帧省掉中间所有存储和计算环节。先说清楚这套方案定位是“快速验证、临时展示、轻量看板”不是生产级监控体系。它能帮你在一个下午之内跑通从Ambari-Metrics到Grafana大屏的完整链路让你直观看到数据长什么样、面板怎么配、变量怎么传、刷新节奏怎么控制。等确认这套指标确实有监控价值再考虑上Prometheus、InfluxDB或者正式采集任务都不迟。下面我把实际操盘过程中涉及的接口细节、插件配置、踩坑点一次性讲透。1. 方案选型与整体思路1.1 为什么监控DEMO会卡在“展示层”很多人一开始想搭监控DEMO第一个念头是写个Python脚本定时调Ambari-Metrics的REST接口把数据存到MySQL或者InfluxDB再用Grafana画图。这个思路没错但它不适合DEMO。为什么因为整套链路里有三个额外环节要搞定数据库表结构怎么设计、采集任务怎么调度、历史数据怎么清理。每一环都要花时间调等你把这些搞完半天就没了而老板和客户只想看屏幕上出现几个大数字。另一种思路是直接用Ambari的Metrics页面截图或者开Ambari自带的REST接口手动刷但这样根本构不成“看板”也没法和其它监控源整合。所以问题本质是Ambari-Metrics的指标数据已经躺在Collector里了你缺的只是一个“快速把它抽出来并可视化”的中间层。Infinity插件干的正是这件事。1.2 几条候选路线对比我在准备这个DEMO前顺手列了个对比表把几条常见路线的成本看得比较清楚方案成本延迟适合场景自研采集脚本 数据库 Grafana高需要设计表结构、写定时任务、处理去重和清理分钟级生产长期监控、需要自定义聚合和历史分析Ambari自带UI零成本但展示固定、无法定制大屏准实时单服务快速查看Grafana Infinity插件直连AMS API极低装插件、配数据源、写查询即可准实时受AMS接口性能约束DEMO、临时看板、轻量展示Prometheus 自定义Exporter中高需要开发Exporter对接AMS秒级到分钟级长期监控且愿意投入改造Infinity这条路最大的优势是“零存储”。它不落库每次面板刷新都直接请求AMS的HTTP接口。这样做的好处是部署简单、数据绝对新鲜坏处是AMS接口压力变大而且没有历史数据回放能力。所以我在实际项目中把它定位成“快速验证链路和展示效果”的工具等确认某些指标要长期盯再让采集脚本定期把AMS数据拉到正式存储里。1.3 整体架构与适用边界这个DEMO的整体链路是这样的Ambari Metrics Monitor采集主机和组件指标上报给Ambari Metrics CollectorCollector把数据落到内部的HBase存储里同时对外暴露Timeline Metrics REST API。Grafana通过Infinity插件向这个REST API发起HTTP请求拿到JSON响应后解析成表格再渲染成面板。这里要强调一个适用边界AMBARI Metrics Collector本质上是一个时序数据服务它的查询接口适合“按时间范围拉一批指标”不适合高频轮询。如果Grafana面板设置1秒自动刷新并且塞了十几个指标查询AMS Collector很容易出现响应变慢甚至超时。DEMO阶段建议刷新间隔至少30秒以上指标数控制在个位数。这也是为什么这套方案不能直接套到生产大屏上的原因之一。2. Ambari-Metrics REST API这个DEMO的“数据源”2.1 数据链路回顾Monitor → Collector → REST APIAmbari-Metrics能采到的数据分两类一类是主机层面的系统指标比如CPU、内存、磁盘IO、网络流量由Metrics Monitor以固定间隔采集另一类是组件指标比如HBase RegionServer的堆使用、NameNode的GC次数由组件通过Metrics System SDK主动上报。这些数据最终都汇聚到Ambari Metrics Collector它内部用HBase存储时序数据对外提供查询接口。理解这条链路对排查问题很有帮助。比如你在Grafana里查不到某个指标可能是指标名写错了也可能是该组件根本没有把指标上报到Collector。我在实际操作中养成一个习惯先在Ambari UI的Metrics页面确认某个指标确实有数据再去REST API里验证同样的指标能否查到。链路没打通之前不要在Grafana端浪费时间。2.2 接口地址与关键参数Ambari-Metrics对外开放的查询接口核心入口是Timeline Metrics API默认HTTP端口是6188HTTPS端口是6189。完整的请求地址长这样http://ams-collector-host:6188/ws/v1/timeline/metrics注意很多人在这一步会踩坑Ambari Server的REST API端口是8080路径是/api/v1/clusters/xxx而Ambari Metrics Collector的接口端口是6188路径是/ws/v1/timeline/metrics两者完全不是一回事。这个DEMO要调的是后者。常见查询参数如下参数含义示例metricNames指标名多个用逗号分隔metricNamesRegionServer.HeapMemory.UsedappId指标所属应用appIdhbasehostname主机名不传则返回所有主机聚合hostnamenode1.example.comstartTime开始时间戳毫秒startTime1690000000000endTime结束时间戳毫秒endTime1690003600000precision聚合精度可选seconds/minutes/hoursprecisionminuteslimit返回最大点数部分版本支持limit100这里最关键的是时间戳必须用毫秒而且Grafana的${__from}和${__to}变量本身就是毫秒所以可以直接往URL里怼这个后面实战部分会再验证。2.3 用curl验证拿真实返回结构在配置Grafana之前我强烈建议先在服务器上curl一下接口确认网络通不通、认证怎么搞、返回结构长什么样。这一步能帮你省掉后面90%的排查时间。先试最基础的请求curl -u admin:admin http://ams-collector-host:6188/ws/v1/timeline/metrics?metricNamesRegionServer.HeapMemory.UsedappIdhbasehostnamenode1.example.comstartTime1690000000000endTime1690003600000precisionminutes如果集群开了Kerberos或者其它安全认证curl命令需要加上对应的认证参数。大部分内网环境用Basic Auth填Ambari的admin账号就能通过也有部分环境直接免认证取决于部署时怎么配的。返回的JSON通常长这样[ { appid: hbase, hostname: node1.example.com, metricname: RegionServer.HeapMemory.Used, metrics: { 1690000020000: 1073741824, 1690000080000: 1090519040, 1690000140000: 1107296256 } } ]注意metrics字段是一个对象key是毫秒时间戳的字符串value是指标值。这个结构很关键因为后面在Infinity里怎么解析、能不能画出曲线都取决于你对这个map结构的处理方式。不同版本的AMS返回的字段名会有细微差异但大方向一致。2.4 常见指标名参考Ambari-Metrics里指标名不是随便猜的最好从Ambari UI的Metrics页面拿或者从Collector里查已有指标列表。这里列几个我经常用于DEMO展示的指标方便你快速上手组件指标名说明HBaseRegionServer.HeapMemory.UsedRegionServer堆内存使用量HBaseRegionServer.HeapMemory.MaxRegionServer堆内存上限HDFSNNSInfo.HeapUsedNameNode堆内存使用量OSOS.Cpu.Idle主机CPU空闲率OSOS.Memory.Free主机空闲内存需要确认单位HDFSHDFSNNInfo.CapacityUsedHDFS已用容量实际使用中不同发行版、不同组件版本的指标名可能略有差异最稳妥的方法还是先去Ambari UI上确认指标名再拿过来查API。3. 实操Grafana Infinity 配置与面板落地3.1 安装Grafana与Infinity插件Grafana本身安装很简单官方有RPM包也有Docker镜像。我用的是CentOS上的RPM方式sudo yum install -y https://dl.grafana.com/oss/release/grafana-10.4.0-1.x86_64.rpm sudo systemctl start grafana-server sudo systemctl enable grafana-server装完之后访问http://grafana-host:3000默认账号密码是admin/admin登录后第一步会引导改密码建议直接改掉。Infinity插件的官方名称是yesoreyeram-infinity-datasource可以通过grafana-cli直接安装sudo grafana-cli plugins install yesoreyeram-infinity-datasource sudo systemctl restart grafana-server如果你的Grafana所在机器不能访问外网需要离线安装。去Grafana插件市场下载对应的zip包解压到/var/lib/grafana/plugins目录然后重启Grafana并且在grafana.ini里确认allow_loading_unsigned_plugins配置包含yesoreyeram-infinity-datasource。安装完成后在Grafana的Data Sources页面新建数据源类型列表里会出现“Infinity”。这一步如果看不到说明插件没装好先检查插件目录权限和Grafana日志。3.2 配置Infinity数据源新建Infinity数据源时核心配置项不多但每项都直接影响后续查询能否成功。名字可以叫Ambari Metrics方便识别。URL这里我建议填AMS Collector的基础地址比如http://ams-collector-host:6188这样在面板查询里只需要写相对路径/ws/v1/timeline/metrics后续如果要换集群或者切换端口只改数据源配置就够了。认证方式先试Basic Auth填Ambari的admin账号密码。如果AMS Collector是免认证的这里可以不填但要注意内网环境的安全性别把敏感数据暴露到外网。如果AMS使用了自定义Header做认证比如有的安全加固环境会要求传token那就在Infinity数据源里配置自定义Headerkey是Header名value是token值。还有几个兼容性开关需要关注。如果AMS Collector用的是HTTPS并且是自签名证书必须开启“Skip TLS Verify”否则查询会报证书错误。数据源里还可以设置默认的超时时间AMS接口在聚合大量指标时可能超过10秒DEMO阶段可以把Timeout调大一点比如30秒。配置完成后点Save Test如果数据源配置正确界面会显示连接成功。这一步失败的话基本就是URL、认证、网络三件事挨个排查很快。3.3 创建查询从Preview到第一个Stat面板数据源配好之后新建一个Dashboard添加Panel数据源选择Infinity。这是整个DEMO里最需要耐心的一步但也是最容易出成果的一步。在Query编辑器的URL输入框里填完整请求路径和参数。我先用一个固定时间范围做验证避免Grafana变量还没通的时候引入额外变量问题/ws/v1/timeline/metrics?metricNamesRegionServer.HeapMemory.UsedappIdhbasehostnamenode1.example.comstartTime1690000000000endTime1690003600000precisionminutes填好URL之后先别急着选Parser直接点右侧的Preview按钮让插件发起一次真实请求并把返回的JSON展示出来。这一步能确认三件事网络通不通、AMS返回结构是什么、以及你填的指标名到底对不对。我看到很多人一上来就写Parser和查询表达式结果URL都没通纯属浪费时间。确认返回JSON正常之后点击Preview界面里的生成按钮Infinity插件会自动根据返回结构生成一个基础的解析脚本。不同版本的插件有的默认生成GROQ有的默认生成UQL具体语法会有差异以你当前版本生成的结果为准。对于DEMO阶段我建议先用Stat面板展示“当前值”而不是一上来就强求时间曲线。具体做法是在Parser生成的脚本基础上把返回体里metrics字段对应的时间戳和值取成一行Grafana就能识别。如果你的查询时间范围设置得比较短返回的点数很少Stat面板展示最后一个值完全够用。如果这里你发现解析脚本怎么调都不对别硬刚。退一步用一个固定时间点的接口返回比如把startTime和endTime设置为同一个时刻附近确保返回只有一两个点然后在解析脚本里直接固定取值。我知道这不够“优雅”但对DEMO来说先把链路跑通最重要。等你看清楚JSON结构了再去完善动态时间序列解析。3.4 用模板变量做出多指标切换效果Stat面板能出数之后接下来就可以让看板变得“活”一点。Grafana的模板变量可以直接在Infinity插件的URL模板里使用这算是这个插件最爽的地方。我在Dashboard Settings里新建一个变量名字叫metric类型选择Custom选项填几个我关心的指标名比如HBase Heap Used,RegionServer.HeapMemory.Used HDFS CapacityUsed,HDFSNNInfo.CapacityUsed变量类型选Custom是因为AMS查询指标名这种低频变化的数据手填列表比动态查询更省事。如果你需要动态获取指标列表也可以把变量类型配成Query数据源指向另一个Infinity查询从AMS的元数据接口拉指标名但这个复杂度放DEMO里没必要。然后在Panel的查询URL里把metricNames参数改成模板变量/ws/v1/timeline/metrics?metricNames${metric}appIdhbasehostnamenode1.example.comstartTime${__from}endTime${__to}precisionminutes注意这里我同时把startTime和endTime换成了Grafana的全局变量${__from}和${__to}。这两个变量在面板刷新时会自动替换成当前面板时间范围对应的毫秒时间戳正好满足AMS接口的要求。这里有一个非常容易踩的坑默认情况下Grafana的${__from}和${__to}在某些版本里是字符串形式的RFC3339时间比如2024-01-01T00:00:00.000Z而不是纯数字毫秒时间戳。如果在Infinity的请求里直接用AMS接口会报参数格式错误。解决办法是在变量后面加上:date:ms强制转换格式写作${__from:date:ms}和${__to:date:ms}。这一点务必留意我在实际配置中就因为这个查了半小时日志。配好模板变量后Dashboard顶部会多一个下拉框切换不同指标所有引用了这个变量的面板会一起刷新。这个效果用来做DEMO演示非常加分。3.5 进阶想把曲线画出来的思路Stat面板适合展示当前值但很多人还是希望看到一条时间曲线。Infinity插件本身支持Time series格式能不能画出曲线关键在于解析脚本能不能把AMS返回的“时间戳map”展开成两列一列是time一列是value。我试过在不同版本的Infinity插件里处理这种结构结论是能用但解析脚本写法很依赖插件版本和AMS返回的具体格式。最好的方法是拿你Preview到的真实JSON在Infinity插件里让生成按钮帮你生成基础脚本然后根据上下文微调。手写一套通用脚本不现实不同环境差异太大。如果你不想在卡片解析脚本上花太多时间另一个思路是用面板的Transform功能做二次处理。比如先让Infinity返回一张表然后用Grafana的“Convert field type”把时间戳列转成时间格式再用“Prepare time series”做宽表转长表。这个方法比硬写GROQ要直观一些但也不是万能的。这里我多说一句如果你要的是长期稳定、能出漂亮曲线图表的监控Infinity直连AMS这条路不是最优解。更好的做法是先用一个轻量脚本定时把AMS关键指标推到Prometheus或者InfluxDB再在Grafana里用正式数据源画图。DEMO阶段完全不必追求曲线先保证几个关键数字能稳定展示即可。4. 常见问题与排查技巧实录4.1 请求失败、401、404、400一查一个准Infinity查询失败时Grafana面板上会直接显示错误信息但很多时候错误信息比较笼统。我的排查顺序是先用curl复现同一个请求确认接口本身是否正常再回到Infinity里比对URL、认证、Header。现象可能原因解决办法401 UnauthorizedAMS接口开了认证但Infinity数据源没配Basic Auth在数据源配置里填上正确的账号密码404 Not Found路径写错或者端口不是6188确认是/ws/v1/timeline/metrics不是Ambari的/api/v1400 Bad Request时间戳格式错误、指标名不存在、缺少必填参数检查${__from:date:ms}是否生效用curl逐个参数排查连接超时网络不通、AMS负载高、查询范围过大先curl测试再缩小时间范围或指定precisionminutes返回为空但无报错指标名写错、appId不对、该主机没有这个指标到Ambari UI Metrics页面确认指标真实存在还有一个容易被忽略的点如果你在URL里直接写死hostname而AMS返回的结果里该主机确实没有这个指标接口不会报错只会返回一个空数组。所以遇到“Preview能看到JSON但面板没有数据”时先看返回数组是不是空的。4.2 时间戳与格式问题Grafana和AMS之间的时间戳匹配是这套DEMO里最容易出问题的地方。AMS接口要求的是毫秒时间戳而且是从1970年1月1日开始的Unix毫秒数。Grafana的${__from}和${__to}默认返回的也是毫秒数格式上完全匹配。问题通常出在两个方面。第一你在Configure Panel里看到的预览URL里时间戳可能被替换成了类似2024-01-01T00:00:00.000Z的字符串这说明${__from}没有加上:date:ms后缀。第二如果你手动填时间戳一定要数清楚位数13位才是毫秒10位是秒AMS直接吃10位秒级时间戳通常会返回异常或者取不到数据。如果返回JSON里的时间戳解析出来之后Grafana画图时时间轴不对比如显示成1970年或者时间偏移8小时大概率是时区问题。在Panel的Time series设置里把时区调整为UTC或者你的本地时区一般就能对齐。4.3 数据源升级后的legacy query报错这个报错很经典我第一次遇到时也愣了一下failed to upgrade legacy queries datasource im7_otuvz was not found这个报错的含义是Grafana从旧版本升级之后之前面板里保存的Infinity数据源引用是一个旧的UID升级后Grafana找不到这个UID了。本质上不是查询写错了而是“数据源引用失效”。解决办法有两个。最简单的打开Dashboard设置进入JSON Model搜索datasource字段把旧的UID改成当前数据源的UID。新数据源的UID可以在数据源设置页面的URL里看到是一长串随机字符。另一个办法直接把对应的Panel查询删掉重新选择数据源再配一次。虽然麻烦点但不会引入JSON编辑失误。我个人倾向于改JSON Model因为面板多的时候重配太累。4.4 查询超时与面板刷新策略Infinity直连AMS时查询响应速度直接决定面板体验。我见过一个DEMO面板塞了六个指标查询每个查询又没加precision参数Grafana默认30秒刷新一次结果AMS Collector CPU飙升好几个面板直接超时。控制查询压力有几个实用技巧。第一务必指定precisionminutes甚至precisionhours尤其当你查询的时间范围跨天时秒级精度会产生海量数据点AMS计算和网络传输都会被拖垮。第二Dashboard的刷新间隔不要低于30秒DEMO展示根本不需要秒级刷新设成1分钟甚至5分钟完全够用。第三每个面板的查询尽量只查一个指标加一个主机把多个指标拆到多个面板方便定位是哪个查询拖慢了整体。还有一个技巧在Infinity数据源配置里调大超时时间默认的10秒在AMS响应慢时不够用我通常改成30秒。但这个只能缓解症状不能解决AMS本身压力大的问题根子上还是控制查询复杂度和频率。5. 一点实践经验最后分享几个我在做这个DEMO时沉淀下来的心得不算总结纯粹是实操过程中的感受。第一Ambari-Metrics的接口调试一定要先curl再配Grafana。很多人在面板里反复改参数其实问题出在接口本身curl一发就知道。把curl视为整个链路的第一调试工具能省大量时间。第二Infinity插件对JSON解析的版本兼容性确实有点飘所以别把太多精力花在写“完美”的GROQ脚本上。先固定时间范围、用Stat面板跑通等链路完全通了再考虑曲线图或者动态解析也不迟。DEMO的核心目标是“让数据出现在大屏上”不是“让数据以最完美的方式出现在大屏上”。第三这套方案用来做应急展示和验证非常香但生产级监控别这么干。AMS的REST API面向的是查询需求不是高频轮询需求。真要长期监控还是把数据落到Prometheus或InfluxDB里让Grafana走正式数据源。Infinity直连可以作为Prometheus没配好之前的过渡方案或者作为一些临时指标的快速接入方式。我在实际项目中曾用这个DEMO临时顶了两周帮助团队在迁移监控系统期间保持了大屏不断更。后来正式监控上线后Infinity这边只保留了少数几个需要实时看到原始值的指标其它都切走了。这套链路的价值不在于替代正式监控而在于让你用最小成本把“想看到的东西”先看到这个能力在应急场景下特别好用。如果你在实操中遇到其它奇怪的问题建议优先打开Infinity插件自带的Preview功能看看真实返回数据和错误信息。大部分问题在Preview这一步就能暴露出来。祝你们的大屏早日跑起来。
Grafana+Infinity插件直连Ambari-Metrics快速搭建监控大屏DEMO
前天有个朋友微信我说Ambari集群装好大半年了HBase RegionServer的堆内存老是飘每次想看还得登录Ambari UI点进服务、切到Metrics标签页想对比两个组件的指标就得来回切页面。他问我能不能五分钟拉一个监控DEMO出来数据就拿Ambari-Metrics现成的。我第一反应是Grafana那边正好有个Infinity插件能把REST API直接变成数据源不用写后端、不用建库、不用起采集任务十几分钟就能把几个关键指标怼到大屏上。这篇文章就把这条链路完整拆开讲一遍适合正在用Ambari、手头有现成Metrics Collector、又想在Grafana里快速出监控DEMO的运维和开发参考。Ambari-Metrics这套东西其实一直有点“数据很全但展示不够灵活”的尴尬。Ambari自带的UI适合单服务查看但你要是想把几个集群、几个关键指标拉到一个统一看板上或者塞进公司现有的Grafana体系里它就不太够用了。常规做法是自己写采集脚本把指标入库再对接Grafana这个工作量对一个DEMO来说太重。Infinity插件就是用来填补这个空档的它把HTTP请求返回的JSON直接包装成Grafana能识别的数据帧省掉中间所有存储和计算环节。先说清楚这套方案定位是“快速验证、临时展示、轻量看板”不是生产级监控体系。它能帮你在一个下午之内跑通从Ambari-Metrics到Grafana大屏的完整链路让你直观看到数据长什么样、面板怎么配、变量怎么传、刷新节奏怎么控制。等确认这套指标确实有监控价值再考虑上Prometheus、InfluxDB或者正式采集任务都不迟。下面我把实际操盘过程中涉及的接口细节、插件配置、踩坑点一次性讲透。1. 方案选型与整体思路1.1 为什么监控DEMO会卡在“展示层”很多人一开始想搭监控DEMO第一个念头是写个Python脚本定时调Ambari-Metrics的REST接口把数据存到MySQL或者InfluxDB再用Grafana画图。这个思路没错但它不适合DEMO。为什么因为整套链路里有三个额外环节要搞定数据库表结构怎么设计、采集任务怎么调度、历史数据怎么清理。每一环都要花时间调等你把这些搞完半天就没了而老板和客户只想看屏幕上出现几个大数字。另一种思路是直接用Ambari的Metrics页面截图或者开Ambari自带的REST接口手动刷但这样根本构不成“看板”也没法和其它监控源整合。所以问题本质是Ambari-Metrics的指标数据已经躺在Collector里了你缺的只是一个“快速把它抽出来并可视化”的中间层。Infinity插件干的正是这件事。1.2 几条候选路线对比我在准备这个DEMO前顺手列了个对比表把几条常见路线的成本看得比较清楚方案成本延迟适合场景自研采集脚本 数据库 Grafana高需要设计表结构、写定时任务、处理去重和清理分钟级生产长期监控、需要自定义聚合和历史分析Ambari自带UI零成本但展示固定、无法定制大屏准实时单服务快速查看Grafana Infinity插件直连AMS API极低装插件、配数据源、写查询即可准实时受AMS接口性能约束DEMO、临时看板、轻量展示Prometheus 自定义Exporter中高需要开发Exporter对接AMS秒级到分钟级长期监控且愿意投入改造Infinity这条路最大的优势是“零存储”。它不落库每次面板刷新都直接请求AMS的HTTP接口。这样做的好处是部署简单、数据绝对新鲜坏处是AMS接口压力变大而且没有历史数据回放能力。所以我在实际项目中把它定位成“快速验证链路和展示效果”的工具等确认某些指标要长期盯再让采集脚本定期把AMS数据拉到正式存储里。1.3 整体架构与适用边界这个DEMO的整体链路是这样的Ambari Metrics Monitor采集主机和组件指标上报给Ambari Metrics CollectorCollector把数据落到内部的HBase存储里同时对外暴露Timeline Metrics REST API。Grafana通过Infinity插件向这个REST API发起HTTP请求拿到JSON响应后解析成表格再渲染成面板。这里要强调一个适用边界AMBARI Metrics Collector本质上是一个时序数据服务它的查询接口适合“按时间范围拉一批指标”不适合高频轮询。如果Grafana面板设置1秒自动刷新并且塞了十几个指标查询AMS Collector很容易出现响应变慢甚至超时。DEMO阶段建议刷新间隔至少30秒以上指标数控制在个位数。这也是为什么这套方案不能直接套到生产大屏上的原因之一。2. Ambari-Metrics REST API这个DEMO的“数据源”2.1 数据链路回顾Monitor → Collector → REST APIAmbari-Metrics能采到的数据分两类一类是主机层面的系统指标比如CPU、内存、磁盘IO、网络流量由Metrics Monitor以固定间隔采集另一类是组件指标比如HBase RegionServer的堆使用、NameNode的GC次数由组件通过Metrics System SDK主动上报。这些数据最终都汇聚到Ambari Metrics Collector它内部用HBase存储时序数据对外提供查询接口。理解这条链路对排查问题很有帮助。比如你在Grafana里查不到某个指标可能是指标名写错了也可能是该组件根本没有把指标上报到Collector。我在实际操作中养成一个习惯先在Ambari UI的Metrics页面确认某个指标确实有数据再去REST API里验证同样的指标能否查到。链路没打通之前不要在Grafana端浪费时间。2.2 接口地址与关键参数Ambari-Metrics对外开放的查询接口核心入口是Timeline Metrics API默认HTTP端口是6188HTTPS端口是6189。完整的请求地址长这样http://ams-collector-host:6188/ws/v1/timeline/metrics注意很多人在这一步会踩坑Ambari Server的REST API端口是8080路径是/api/v1/clusters/xxx而Ambari Metrics Collector的接口端口是6188路径是/ws/v1/timeline/metrics两者完全不是一回事。这个DEMO要调的是后者。常见查询参数如下参数含义示例metricNames指标名多个用逗号分隔metricNamesRegionServer.HeapMemory.UsedappId指标所属应用appIdhbasehostname主机名不传则返回所有主机聚合hostnamenode1.example.comstartTime开始时间戳毫秒startTime1690000000000endTime结束时间戳毫秒endTime1690003600000precision聚合精度可选seconds/minutes/hoursprecisionminuteslimit返回最大点数部分版本支持limit100这里最关键的是时间戳必须用毫秒而且Grafana的${__from}和${__to}变量本身就是毫秒所以可以直接往URL里怼这个后面实战部分会再验证。2.3 用curl验证拿真实返回结构在配置Grafana之前我强烈建议先在服务器上curl一下接口确认网络通不通、认证怎么搞、返回结构长什么样。这一步能帮你省掉后面90%的排查时间。先试最基础的请求curl -u admin:admin http://ams-collector-host:6188/ws/v1/timeline/metrics?metricNamesRegionServer.HeapMemory.UsedappIdhbasehostnamenode1.example.comstartTime1690000000000endTime1690003600000precisionminutes如果集群开了Kerberos或者其它安全认证curl命令需要加上对应的认证参数。大部分内网环境用Basic Auth填Ambari的admin账号就能通过也有部分环境直接免认证取决于部署时怎么配的。返回的JSON通常长这样[ { appid: hbase, hostname: node1.example.com, metricname: RegionServer.HeapMemory.Used, metrics: { 1690000020000: 1073741824, 1690000080000: 1090519040, 1690000140000: 1107296256 } } ]注意metrics字段是一个对象key是毫秒时间戳的字符串value是指标值。这个结构很关键因为后面在Infinity里怎么解析、能不能画出曲线都取决于你对这个map结构的处理方式。不同版本的AMS返回的字段名会有细微差异但大方向一致。2.4 常见指标名参考Ambari-Metrics里指标名不是随便猜的最好从Ambari UI的Metrics页面拿或者从Collector里查已有指标列表。这里列几个我经常用于DEMO展示的指标方便你快速上手组件指标名说明HBaseRegionServer.HeapMemory.UsedRegionServer堆内存使用量HBaseRegionServer.HeapMemory.MaxRegionServer堆内存上限HDFSNNSInfo.HeapUsedNameNode堆内存使用量OSOS.Cpu.Idle主机CPU空闲率OSOS.Memory.Free主机空闲内存需要确认单位HDFSHDFSNNInfo.CapacityUsedHDFS已用容量实际使用中不同发行版、不同组件版本的指标名可能略有差异最稳妥的方法还是先去Ambari UI上确认指标名再拿过来查API。3. 实操Grafana Infinity 配置与面板落地3.1 安装Grafana与Infinity插件Grafana本身安装很简单官方有RPM包也有Docker镜像。我用的是CentOS上的RPM方式sudo yum install -y https://dl.grafana.com/oss/release/grafana-10.4.0-1.x86_64.rpm sudo systemctl start grafana-server sudo systemctl enable grafana-server装完之后访问http://grafana-host:3000默认账号密码是admin/admin登录后第一步会引导改密码建议直接改掉。Infinity插件的官方名称是yesoreyeram-infinity-datasource可以通过grafana-cli直接安装sudo grafana-cli plugins install yesoreyeram-infinity-datasource sudo systemctl restart grafana-server如果你的Grafana所在机器不能访问外网需要离线安装。去Grafana插件市场下载对应的zip包解压到/var/lib/grafana/plugins目录然后重启Grafana并且在grafana.ini里确认allow_loading_unsigned_plugins配置包含yesoreyeram-infinity-datasource。安装完成后在Grafana的Data Sources页面新建数据源类型列表里会出现“Infinity”。这一步如果看不到说明插件没装好先检查插件目录权限和Grafana日志。3.2 配置Infinity数据源新建Infinity数据源时核心配置项不多但每项都直接影响后续查询能否成功。名字可以叫Ambari Metrics方便识别。URL这里我建议填AMS Collector的基础地址比如http://ams-collector-host:6188这样在面板查询里只需要写相对路径/ws/v1/timeline/metrics后续如果要换集群或者切换端口只改数据源配置就够了。认证方式先试Basic Auth填Ambari的admin账号密码。如果AMS Collector是免认证的这里可以不填但要注意内网环境的安全性别把敏感数据暴露到外网。如果AMS使用了自定义Header做认证比如有的安全加固环境会要求传token那就在Infinity数据源里配置自定义Headerkey是Header名value是token值。还有几个兼容性开关需要关注。如果AMS Collector用的是HTTPS并且是自签名证书必须开启“Skip TLS Verify”否则查询会报证书错误。数据源里还可以设置默认的超时时间AMS接口在聚合大量指标时可能超过10秒DEMO阶段可以把Timeout调大一点比如30秒。配置完成后点Save Test如果数据源配置正确界面会显示连接成功。这一步失败的话基本就是URL、认证、网络三件事挨个排查很快。3.3 创建查询从Preview到第一个Stat面板数据源配好之后新建一个Dashboard添加Panel数据源选择Infinity。这是整个DEMO里最需要耐心的一步但也是最容易出成果的一步。在Query编辑器的URL输入框里填完整请求路径和参数。我先用一个固定时间范围做验证避免Grafana变量还没通的时候引入额外变量问题/ws/v1/timeline/metrics?metricNamesRegionServer.HeapMemory.UsedappIdhbasehostnamenode1.example.comstartTime1690000000000endTime1690003600000precisionminutes填好URL之后先别急着选Parser直接点右侧的Preview按钮让插件发起一次真实请求并把返回的JSON展示出来。这一步能确认三件事网络通不通、AMS返回结构是什么、以及你填的指标名到底对不对。我看到很多人一上来就写Parser和查询表达式结果URL都没通纯属浪费时间。确认返回JSON正常之后点击Preview界面里的生成按钮Infinity插件会自动根据返回结构生成一个基础的解析脚本。不同版本的插件有的默认生成GROQ有的默认生成UQL具体语法会有差异以你当前版本生成的结果为准。对于DEMO阶段我建议先用Stat面板展示“当前值”而不是一上来就强求时间曲线。具体做法是在Parser生成的脚本基础上把返回体里metrics字段对应的时间戳和值取成一行Grafana就能识别。如果你的查询时间范围设置得比较短返回的点数很少Stat面板展示最后一个值完全够用。如果这里你发现解析脚本怎么调都不对别硬刚。退一步用一个固定时间点的接口返回比如把startTime和endTime设置为同一个时刻附近确保返回只有一两个点然后在解析脚本里直接固定取值。我知道这不够“优雅”但对DEMO来说先把链路跑通最重要。等你看清楚JSON结构了再去完善动态时间序列解析。3.4 用模板变量做出多指标切换效果Stat面板能出数之后接下来就可以让看板变得“活”一点。Grafana的模板变量可以直接在Infinity插件的URL模板里使用这算是这个插件最爽的地方。我在Dashboard Settings里新建一个变量名字叫metric类型选择Custom选项填几个我关心的指标名比如HBase Heap Used,RegionServer.HeapMemory.Used HDFS CapacityUsed,HDFSNNInfo.CapacityUsed变量类型选Custom是因为AMS查询指标名这种低频变化的数据手填列表比动态查询更省事。如果你需要动态获取指标列表也可以把变量类型配成Query数据源指向另一个Infinity查询从AMS的元数据接口拉指标名但这个复杂度放DEMO里没必要。然后在Panel的查询URL里把metricNames参数改成模板变量/ws/v1/timeline/metrics?metricNames${metric}appIdhbasehostnamenode1.example.comstartTime${__from}endTime${__to}precisionminutes注意这里我同时把startTime和endTime换成了Grafana的全局变量${__from}和${__to}。这两个变量在面板刷新时会自动替换成当前面板时间范围对应的毫秒时间戳正好满足AMS接口的要求。这里有一个非常容易踩的坑默认情况下Grafana的${__from}和${__to}在某些版本里是字符串形式的RFC3339时间比如2024-01-01T00:00:00.000Z而不是纯数字毫秒时间戳。如果在Infinity的请求里直接用AMS接口会报参数格式错误。解决办法是在变量后面加上:date:ms强制转换格式写作${__from:date:ms}和${__to:date:ms}。这一点务必留意我在实际配置中就因为这个查了半小时日志。配好模板变量后Dashboard顶部会多一个下拉框切换不同指标所有引用了这个变量的面板会一起刷新。这个效果用来做DEMO演示非常加分。3.5 进阶想把曲线画出来的思路Stat面板适合展示当前值但很多人还是希望看到一条时间曲线。Infinity插件本身支持Time series格式能不能画出曲线关键在于解析脚本能不能把AMS返回的“时间戳map”展开成两列一列是time一列是value。我试过在不同版本的Infinity插件里处理这种结构结论是能用但解析脚本写法很依赖插件版本和AMS返回的具体格式。最好的方法是拿你Preview到的真实JSON在Infinity插件里让生成按钮帮你生成基础脚本然后根据上下文微调。手写一套通用脚本不现实不同环境差异太大。如果你不想在卡片解析脚本上花太多时间另一个思路是用面板的Transform功能做二次处理。比如先让Infinity返回一张表然后用Grafana的“Convert field type”把时间戳列转成时间格式再用“Prepare time series”做宽表转长表。这个方法比硬写GROQ要直观一些但也不是万能的。这里我多说一句如果你要的是长期稳定、能出漂亮曲线图表的监控Infinity直连AMS这条路不是最优解。更好的做法是先用一个轻量脚本定时把AMS关键指标推到Prometheus或者InfluxDB再在Grafana里用正式数据源画图。DEMO阶段完全不必追求曲线先保证几个关键数字能稳定展示即可。4. 常见问题与排查技巧实录4.1 请求失败、401、404、400一查一个准Infinity查询失败时Grafana面板上会直接显示错误信息但很多时候错误信息比较笼统。我的排查顺序是先用curl复现同一个请求确认接口本身是否正常再回到Infinity里比对URL、认证、Header。现象可能原因解决办法401 UnauthorizedAMS接口开了认证但Infinity数据源没配Basic Auth在数据源配置里填上正确的账号密码404 Not Found路径写错或者端口不是6188确认是/ws/v1/timeline/metrics不是Ambari的/api/v1400 Bad Request时间戳格式错误、指标名不存在、缺少必填参数检查${__from:date:ms}是否生效用curl逐个参数排查连接超时网络不通、AMS负载高、查询范围过大先curl测试再缩小时间范围或指定precisionminutes返回为空但无报错指标名写错、appId不对、该主机没有这个指标到Ambari UI Metrics页面确认指标真实存在还有一个容易被忽略的点如果你在URL里直接写死hostname而AMS返回的结果里该主机确实没有这个指标接口不会报错只会返回一个空数组。所以遇到“Preview能看到JSON但面板没有数据”时先看返回数组是不是空的。4.2 时间戳与格式问题Grafana和AMS之间的时间戳匹配是这套DEMO里最容易出问题的地方。AMS接口要求的是毫秒时间戳而且是从1970年1月1日开始的Unix毫秒数。Grafana的${__from}和${__to}默认返回的也是毫秒数格式上完全匹配。问题通常出在两个方面。第一你在Configure Panel里看到的预览URL里时间戳可能被替换成了类似2024-01-01T00:00:00.000Z的字符串这说明${__from}没有加上:date:ms后缀。第二如果你手动填时间戳一定要数清楚位数13位才是毫秒10位是秒AMS直接吃10位秒级时间戳通常会返回异常或者取不到数据。如果返回JSON里的时间戳解析出来之后Grafana画图时时间轴不对比如显示成1970年或者时间偏移8小时大概率是时区问题。在Panel的Time series设置里把时区调整为UTC或者你的本地时区一般就能对齐。4.3 数据源升级后的legacy query报错这个报错很经典我第一次遇到时也愣了一下failed to upgrade legacy queries datasource im7_otuvz was not found这个报错的含义是Grafana从旧版本升级之后之前面板里保存的Infinity数据源引用是一个旧的UID升级后Grafana找不到这个UID了。本质上不是查询写错了而是“数据源引用失效”。解决办法有两个。最简单的打开Dashboard设置进入JSON Model搜索datasource字段把旧的UID改成当前数据源的UID。新数据源的UID可以在数据源设置页面的URL里看到是一长串随机字符。另一个办法直接把对应的Panel查询删掉重新选择数据源再配一次。虽然麻烦点但不会引入JSON编辑失误。我个人倾向于改JSON Model因为面板多的时候重配太累。4.4 查询超时与面板刷新策略Infinity直连AMS时查询响应速度直接决定面板体验。我见过一个DEMO面板塞了六个指标查询每个查询又没加precision参数Grafana默认30秒刷新一次结果AMS Collector CPU飙升好几个面板直接超时。控制查询压力有几个实用技巧。第一务必指定precisionminutes甚至precisionhours尤其当你查询的时间范围跨天时秒级精度会产生海量数据点AMS计算和网络传输都会被拖垮。第二Dashboard的刷新间隔不要低于30秒DEMO展示根本不需要秒级刷新设成1分钟甚至5分钟完全够用。第三每个面板的查询尽量只查一个指标加一个主机把多个指标拆到多个面板方便定位是哪个查询拖慢了整体。还有一个技巧在Infinity数据源配置里调大超时时间默认的10秒在AMS响应慢时不够用我通常改成30秒。但这个只能缓解症状不能解决AMS本身压力大的问题根子上还是控制查询复杂度和频率。5. 一点实践经验最后分享几个我在做这个DEMO时沉淀下来的心得不算总结纯粹是实操过程中的感受。第一Ambari-Metrics的接口调试一定要先curl再配Grafana。很多人在面板里反复改参数其实问题出在接口本身curl一发就知道。把curl视为整个链路的第一调试工具能省大量时间。第二Infinity插件对JSON解析的版本兼容性确实有点飘所以别把太多精力花在写“完美”的GROQ脚本上。先固定时间范围、用Stat面板跑通等链路完全通了再考虑曲线图或者动态解析也不迟。DEMO的核心目标是“让数据出现在大屏上”不是“让数据以最完美的方式出现在大屏上”。第三这套方案用来做应急展示和验证非常香但生产级监控别这么干。AMS的REST API面向的是查询需求不是高频轮询需求。真要长期监控还是把数据落到Prometheus或InfluxDB里让Grafana走正式数据源。Infinity直连可以作为Prometheus没配好之前的过渡方案或者作为一些临时指标的快速接入方式。我在实际项目中曾用这个DEMO临时顶了两周帮助团队在迁移监控系统期间保持了大屏不断更。后来正式监控上线后Infinity这边只保留了少数几个需要实时看到原始值的指标其它都切走了。这套链路的价值不在于替代正式监控而在于让你用最小成本把“想看到的东西”先看到这个能力在应急场景下特别好用。如果你在实操中遇到其它奇怪的问题建议优先打开Infinity插件自带的Preview功能看看真实返回数据和错误信息。大部分问题在Preview这一步就能暴露出来。祝你们的大屏早日跑起来。