TT Bigdata TT Bigdata
首页
GitHub (opens new window)
JaneTTR

JaneTTR

数据酿造智慧,每一滴都是沉淀!
  • Ambari 深度专题

  • Bigtop 方法论

  • 自定义集成

  • Ambari Server 与 Web

  • Ambari Metrics

    • 试读&介绍

    • Ambari-Metrics解读【简写AMS】

      • 源码下载及环境初始化
      • 项目目录及模块解读
      • AMS-Collector剖析

        • Ambari启动视角剖析执行逻辑
        • 启动脚本链接Python&Java
        • [主启动类] — 执行逻辑梳理
        • [主启动类] — AMSApplication初始化职责
          • 一、上节回忆
          • 二、主类入口:main 方法
          • 三、init 的执行逻辑
          • 四、AMSApplicationServer — 配置文件初始化
            • 1. 配置加载源码
            • 2. 图示说明
          • 五、HBaseTimelineMetricsService — 库表初始化
            • 1. 类继承关系
            • 2. 关键职责
          • 六、职责对比
        • [主启动类] — HBaseTimeline初始化职责
        • [主启动类] — AMSApplication的Web启动
      • AMS-Collector表结构实战

      • AMS-Collector-元数据-接口实战

      • AMS-Collector-指标查询-接口实战

      • AMS-Collector-普通指标写入-接口实战

      • AMS-Collector-聚合指标写入-接口实战

  • Ambari Plus 思考

  • Redis集成实战

  • 通用代码模板

  • 各组件代码

  • 技术专题
  • Ambari Metrics
  • Ambari-Metrics解读【简写AMS】
  • AMS-Collector剖析
JaneTTR
2025-09-02
目录
一、上节回忆
二、主类入口:main 方法
三、init 的执行逻辑
四、AMSApplicationServer — 配置文件初始化
1. 配置加载源码
2. 图示说明
五、HBaseTimelineMetricsService — 库表初始化
1. 类继承关系
2. 关键职责
六、职责对比

[主启动类] — AMSApplication初始化职责

# 一、上节回忆

提出疑问

我们为什么可以快速梳理 Collector 的启动链路?
原因就在于:只要掌握 代码加载的过程,就能清晰地看出职责划分。

在上节中我们已经走到 main → launchAMSApplicationServer,最终落在:

amsApplicationServer.init(conf);
amsApplicationServer.start();
1
2

其中,init 与 start 是整个启动的两大核心。本节我们专注于 init 阶段。

# 二、主类入口:main 方法

下图展示了主启动类的 main 方法:

image-20250903154211140

它会流转到 launchAMSApplicationServer 这个静态方法:

image-20250903155148045

这里 new 出了一个 AMSApplicationServer,依次调用了 init() 和 start()。 整个过程可以简化为:

两步走

  1. 初始化(init):加载配置 + 初始化依赖服务
  2. 启动(start):挂载 Web 控制器,提供 API

# 三、init 的执行逻辑

我们来看 init(conf) 的真实调用链:

image-20250903160122519

可以看到:

amsApplicationServer.init(conf);  
// 实际调用了 AbstractService 的 init 方法
// 方法内部再回调子类的 serviceInit()
1
2
3

关键点

init() 其实是 父类 AbstractService 的模板逻辑,真正的业务初始化被延迟到 子类 serviceInit()。

因此,init 阶段的核心是两个子类:

  • AMSApplicationServer.serviceInit()
  • HBaseTimelineMetricsService.serviceInit()

# 四、AMSApplicationServer — 配置文件初始化

进入 AMSApplicationServer.serviceInit,首先执行:

image-20250903163305636

核心调用:

metricConfiguration.initialize();
1

# 1. 配置加载源码

URL hbaseResUrl = classLoader.getResource(HBASE_SITE_CONFIGURATION_FILE);
URL amsResUrl   = classLoader.getResource(METRICS_SITE_CONFIGURATION_FILE);

hbaseConf   = new Configuration(true);
hbaseConf.addResource(hbaseResUrl.toURI().toURL());

metricsConf = new Configuration(true);
metricsConf.addResource(amsResUrl.toURI().toURL());
1
2
3
4
5
6
7
8

加载结果

  • hbase-site.xml → 提供 HBase 存储层配置
  • ams-site.xml → 提供 Collector 服务端配置
  • ams-ssl-server.xml(可选)→ HTTPS 环境下加载

# 2. 图示说明

配置文件加载

这里加载的全是 Key-Value 配置项,最终形成 hbaseConf 与 metricsConf 对象。

注意

如果缺少 hbase-site.xml 或 ams-site.xml,初始化会直接抛出异常,Collector 将无法启动。

# 五、HBaseTimelineMetricsService — 库表初始化

配置文件加载完成后,serviceInit 会继续执行:

timelineMetricStore = createTimelineMetricStore(conf);
1

对应的是 HBaseTimelineMetricsService。

image-20250904093021610

# 1. 类继承关系

HBaseTimelineMetricsService 同样继承 AbstractService,意味着它拥有独立的生命周期。

继承关系

# 2. 关键职责

友情提醒

本节不深入讲解 HBaseTimelineMetricsService ,将在下一节详细赘述

image-20250904093136567

  • 校验 HBase 环境可用性
  • 初始化 METRIC_* 表结构
  • 负责持久化存储的准备工作

# 六、职责对比

我们可以将 init 阶段的分工总结为下表:

类名 职责定位 关键方法/逻辑
AMSApplicationServer 配置加载 metricConfiguration.initialize()
HBaseTimelineMetricsService 存储初始化 createTimelineMetricStore() → 建立 METRIC 表

重点回顾

  • AMSApplicationServer:相当于“准备地基”,加载配置文件,构建运行环境。
  • HBaseTimelineMetricsService:相当于“搭建框架”,基于配置完成表模型初始化。
#Ambari-Metrics#源码解析#Ambari
[主启动类] — 执行逻辑梳理
[主启动类] — HBaseTimeline初始化职责

← [主启动类] — 执行逻辑梳理 [主启动类] — HBaseTimeline初始化职责→

最近更新
01
当前版本 2026/08
08-29
02
把 Ambari Server HA 稳稳地跑起来
08-17
03
从一次启用操作追到主备就绪
08-17
更多文章>
Theme by Vdoing | Copyright © 2017-2026 JaneTTR | MIT License
  • 跟随系统
  • 浅色模式
  • 深色模式
  • 阅读模式