引言：一场迫在眉睫的变革

在大数据领域，Apache Ambari 作为一款成熟的集群管理工具已服务多年。然而，随着时间推移，它内置的监控系统—— Ambari Metrics System (AMS)——却逐渐成为了运维团队的"心头痛"。

在 EDP，我们管理着数百个 Hadoop 集群，每天面对的不仅是海量数据，还有来自 AMS 的各种"小情绪"：时不时的服务宕机、莫名其妙的数据丢失、以及那令人抓狂的查询延迟，GC…

"这不是一个监控系统应有的表现，" 我们的首席架构师在一次深夜故障排查后说道，"它应该是解决问题的工具，而不是制造问题的源头。"

这就是我们决定彻底重构 Ambari 监控系统的起点。在这个系列文章中，我将分享我们的经验——从认识问题，到设计方案，再到最终实现。今天，让我们先来了解 AMS 的前世今生，以及它为何需要一场彻底的革新。

什么是Ambari Metrics System？从设计初衷说起

Ambari Metrics System (简称AMS) 诞生于大数据技术的早期阶段，是 Apache Ambari 提供的一个专为 Hadoop 集群设计的监控系统。它的核心目标是帮助用户实时了解集群的运行状况，及时发现并解决潜在问题。

从架构上看，AMS 由四个主要层次组成：

嵌入式模式：使用本地文件系统存储数据（适用于小型集群）
分布式模式：使用 HDFS 存储数据（实际不能扩展，仅仅是数据丢在 HDFS 上，内置监控 HBase 的 RegionServer 和 Master 还是只有一个）
Phoenix：SQL 查询引擎，将 SQL 查询转换为 HBase 扫描操作
HBase：底层存储引擎，专为存储和快速检索时间序列数据而优化
存储选项：

这个设计在当时看来是合理的，但随着技术的发展和需求的变化，它的局限性逐渐显现…

想象一下，在一个拥有数百个节点的分布式集群中，监控系统的核心存储却是一个单机版的 HBase。这就像用一个小水桶去接一场暴雨——迟早会溢出。

"我们有一个客户，他们的集群有300多个节点，AMS的HBase几乎每周都会因为存储压力过大而崩溃一次。" — EDP资深运维工程师

单机 HBase 不仅存在存储容量瓶颈，还带来了单点故障风险 —— 一旦 HBase 服务出现问题，整个监控系统将无法正常工作。

虽然 AMS 是 Ambari 的一部分，但讽刺的是，它的核心存储 HBase 却没有被纳入 Ambari 的管理界面。这意味着运维团队需要单独维护这个组件，而且没有统一的管理界面。

当出现问题时，排查过程就像在黑暗中摸索——日志分散，错误信息不直观，修改复杂的 HBase 配置,重启服务。升级过程更是充满风险，需要额外的步骤和注意事项，稍有不慎就可能导致数据丢失。

随着监控数据的积累，AMS 的查询性能会明显下降。对于需要查看长时间窗口历史数据的用户来说，这简直是一种折磨。

系统运行还需要消耗大量内存资源，在资源受限环境中表现不佳。数据模型的简单设计也限制了数据分析的灵活性，无法满足复杂的分析需求。

在现代IT环境中，快速添加自定义监控指标是基本需求。然而，在 AMS 中，这却是一项复杂且耗时的任务。

"我们客户曾经花了一周时间，仅仅为了添加几个自定义JVM指标。这在Prometheus中可能只需要几分钟。" — EDP开发团队

缺乏便捷的自定义监控指标添加机制，使得扩展新的监控项目变得异常复杂。这严重限制了团队对特定服务和应用的监控能力。

AMS 的 API 设计较为刻板，难以实现复杂的条件组合查询和数据聚合。查询语言能力有限，不如 PromQL 灵活强大，无法支持丰富的函数和表达式。

数据导出选项也非常有限，难以将监控数据导出到其他分析工具进行深度分析。这使得监控数据的价值大打折扣，无法充分发挥其在问题诊断和性能优化中的作用。

与现代监控系统相比，AMS 的界面设计显得过于基础，缺乏灵活的定制能力和直观的数据可视化。

仪表盘功能和视觉呈现相对简单，难以根据特定需求灵活调整监控视图。告警机制也比较基础，缺乏高级告警功能，如动态阈值、模式识别等。

AMS 缺乏与现代监控和可视化工具的集成能力，无法融入当前的监控生态系统。

缺乏丰富的插件和扩展组件，社区活跃度低，更新频率较低，新功能开发缓慢。在大规模环境下扩展能力有限，难以满足不断增长的监控需求。

面对这些问题，我们不禁要问：为什么要现在重构 AMS ？答案很简单：

本文来自公众号：大数据实战演练