Ambari Metrics 是 Apache Ambari 提供的轻量级、嵌入式集群监控子系统,用于收集、聚合、存储和展示 Hadoop 生态组件
Ambari Metrics 是 Apache Ambari 提供的轻量级、嵌入式集群监控子系统用于收集、聚合、存储和展示 Hadoop 生态组件如 HDFS、YARN、HBase、Kafka 等的关键性能指标Metrics。它基于时间序列数据库默认使用 embedded HBase 或可选集成 Phoenix HBase新版也支持 Metrics Collector 与 Grafana/InfluxDB 等对接通过 Metrics Monitor部署在每个节点采集本地进程指标如 JVM、CPU、内存、磁盘 I/O、服务特定指标并上报至中央 Metrics Collector 服务。核心组件包括Metrics Collector中心化服务接收、聚合、持久化指标数据默认后端为 HBase 表METRICS_RECORD和METRICS_AGGREGATEMetrics Monitor每节点代理以轻量级 Python 进程运行通过 JMX、/proc、命令行等方式采集指标并通过 HTTP POST 发送至 CollectorAmbari Server 集成在 Ambari Web UI 中提供“Metrics”仪表盘支持图表可视化、历史趋势查询、告警配置需配合 Ambari Alerts 框架REST API提供/api/v1/metrics接口支持按时间范围、服务、主机、指标名等条件查询原始或聚合指标如avg,max,sum。⚠️ 注意自 Ambari 2.7 起官方推荐逐步迁移到更现代的监控方案如 Prometheus Grafana JMX Exporter因 Ambari Metrics 存在扩展性瓶颈、HBase 依赖复杂、高并发查询性能受限等问题部分新版本已将 Metrics Collector 标记为“deprecated”。# 示例通过 REST API 查询某 namenode 的 DFSUsed 百分比过去5分钟curl-uadmin:adminhttp://ambari-server:8080/api/v1/clusters/mycluster/metrics?metricNamesdfs.namenode.DFSUsedPercentstartTime1717027200000endTime1717027500000hostnn1.example.comAmbari Metrics Collector原生并不直接支持 InfluxDB 或 Prometheus 作为后端存储——其架构硬编码依赖 HBase通过 Phoenix JDBC 或原生 HBase API 写入官方未提供可插拔的存储适配器机制。因此“替换为 InfluxDB/Prometheus”并非简单配置切换而是需采用架构级替代或数据桥接方案。以下是可行路径按推荐度排序✅ 推荐方案弃用 Metrics Collector改用标准可观测性栈现代最佳实践停用 Ambari Metrics Collector Monitor在 Ambari Web → Services → Metrics → Stop部署 JMX Exporter Prometheus Grafana为每个 Hadoop 组件NameNode、ResourceManager、HBase Master 等启动jmx_exporter以 sidecar 或 JVM agent 方式配置 Prometheusscrape_configs拉取各组件暴露的/metrics端点使用 Grafana 导入社区 Hadoop Dashboard如 Hadoop JMX Dashboard✅ 优势高性能、高扩展、多维标签、强大 PromQL、生态成熟⚠️ 注意需手动管理 exporter 配置与服务发现可用 Consul 或 Prometheus Service Discovery Ambari API 动态生成 targets。⚠️ 折中方案保留 Metrics Collector但将指标导出到外部时序库ETL 桥接启用 Metrics Collector 的timeline.metrics.export.enabledtrueAmbari 2.7 支持配置timeline.metrics.export.sink.class为自定义实现类需 Java 开发例如实现org.apache.hadoop.metrics2.sink.Sink接口将收到的MetricsRecord转为 InfluxDB Line Protocol 并 HTTP POST 到 InfluxDB/api/v2/write或对接 Prometheus Pushgateway不推荐长期使用因违背拉取模型缺点需编译自定义 JAR、重启 Collector、维护兼容性且非官方支持路径。❌ 不可行方案常见误区修改ambari-metrics-collector源码强行替换 HBase Client → 极高维护成本破坏升级能力试图用 HBase → Kafka → Flink → InfluxDB 管道 → 延迟高、复杂度爆炸无实际运维价值依赖已废弃项目如ambari-metrics-influxdb第三方 fork→ 无更新、不兼容新版 Ambari/HBase。 补充Ambari 3.x 及未来方向Ambari 3.0尚未 GA已完全移除 Metrics Collector 模块监控职责移交至外部系统官方文档明确建议“Use Prometheus, Grafana, and vendor-agnostic exporters for metrics collection”。# 示例为 ResourceManager 部署 jmx_exporterstandalone modejava-Dcom.sun.management.jmxremote\-javaagent:./jmx_exporter/jmx_prometheus_javaagent-1.1.0.jar8081:./rmmetrics.yaml\-jarhadoop-yarn-server-resourcemanager.jar其中rmmetrics.yaml定义 JMX bean 过滤与指标重命名规则
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.coloradmin.cn/o/2420974.html
如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈,一经查实,立即删除!