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_AGGREGATE）；
• Metrics Monitor：每节点代理，以轻量级 Python 进程运行，通过 JMX、/proc、命令行等方式采集指标，并通过 HTTP POST 发送至 Collector；
• Ambari 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:admin"http://ambari-server:8080/api/v1/clusters/mycluster/metrics?metricNames=dfs.namenode.DFSUsedPercent&startTime=1717027200000&endTime=1717027500000&host=nn1.example.com"

Ambari 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.enabled=true（Ambari 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_exporter（standalone mode）java-Dcom.sun.management.jmxremote\-javaagent:./jmx_exporter/jmx_prometheus_javaagent-1.1.0.jar=8081:./rmmetrics.yaml\-jarhadoop-yarn-server-resourcemanager.jar

（其中rmmetrics.yaml定义 JMX bean 过滤与指标重命名规则）