Ambari 服务配置以及 Alert 详解

Ambari Alert（告警）简介

Ambari 告警的基础概念

Ambari 为了帮助用户鉴别以及定位集群的问题，实现了告警（Alert）机制。在 Ambari 中预定了很多的告警，这些告警被用于监测集群的各个模块以及机器的状态。对于告警来说，主要有两个概念，一个是 Alert Definition，一个是 Alert Instance。顾名思义，Alert Definition 就是告警的定义，其中会定告警的检测时间间隔（interval）、类型（type）、以及阈值（threshold）等。Ambari 会读取告警的定义，然后创建对应的实例（instance）去定期执行这个告警。例如 MapReduce2 这个 Service 就定义了两个告警“History Server WEB UI”和“History Server Process”来定期检查 History Server 模块的状态。

终端用户可以在 WEB 中 Alert 的页面，浏览以及组织管理这些告警。如果告警名称太多，用户可以用过滤器筛选想要查找的告警。其实这些 WEB 中的显示，都是 Alert Definition，也就是告警的定义。用户可以点击具体的 Alert name 去查看或者修改 Alert 属性（例如 interval 和阈值）。在详细的告警页面里，可以看到该告警所有的 instance。每个 instance 都会严格的报告该 instance 的检查结果。Alert 的检查结果会以五种级别呈现，分别是 OK、WARNING，CRITICAL、UNKNOW 和 NONE。其中最常见的是前三种。

Ambari 中 Alert 的类型

Ambari 中的 Alert 分为 5 种类型，分为 WEB、Port、Metric、Aggregate 和 Script。具体的区别见下面的表格。

表 1. Ambari 中的 Alert 类型对比

类型	用途	告警级别	阀值是否可配	单位
PORT	用来监测机器上的一个端口是否可用	OK, WARN, CRIT	是	秒
METRIC	用来监测 Metric 相关的配置属性	OK, WARN, CRIT	是	变量
AGGREGATE	用于收集其他某些 Alert 的状态	OK, WARN, CRIT	是	百分比
WEB	用于监测一个 WEB UI（URL）地址是否可用	OK, WARN, CRIT	否	无
SCRIPT	Alert 的监测逻辑由一个自定义的 python 脚本执行	OK, CRIT	否	无

如何在 WEB 中管理修改 Alert

当用户登录到 Ambari WEB 中，便可以直接跳转到 Alert 的页面。然后可以操作过滤器筛选 Alert 信息。也可以直接点击最右侧的 Enable 关闭一个开启状态的 Alert（也可以点击 Disable 直接开启一个关闭的 Alert）。

图 4. 告警示例图

点击查看大图

关闭 [x]

图 4. 告警示例图

 

如果用户需要更新一个 Alert 的相关配置，则需要点击 Alert 的名字，进入到 Alert 的定义页面去操作。在这个页面中，当用户点击 Edit 之后，便可以修改 Alert 显示名称，监测时间间隔（interval），以及对应的阀值（图 5 中的 1.5 和 5 秒），以及描述信息。这里用户也可以通过 Enable/Disable 去启停该 Alert。这里注意下地址栏中最后一个数字，这个其实就是每个 Alert 唯一的 id 标识。后面介绍 Rest API 会用到。

图 5. 定义页面

为自定义的 Service 增加 Alert 配置

随着 Ambari 的流行，越来越多的公司想利用 Ambari 管理自己的 Service。这里简单介绍下如何给第三方的 Service 增加 Alert 的相关配置。

在 Ambari 5 种类型的告警中，Port 类型是最容易理解的。如果定义了一个 Port 类型的告警，Ambari 便会监测这个端口。然后依赖这个端口的响应时间，报告对应的 Alert 级别。这里我便以 Port 类型为示例。

首先需要在对应的 Service 目录下创建 alerts.json。Ambari Server 会在启动的时候加载这个配置。当在 Ambari 中安装了这个 Service 之后，Ambari 会将 alert.json 中的定义存到数据库中。然后根据其中的定义（Alert Definition），创建对应的 Alert Instance。最终这些实例就会按照 interval 的配置定期检查。

Alert.json 示例代码如下：

 [root@zwshen71 SAMPLE]# cat alerts.json { "SZWTEST": { "service": [],
 "SZW_MASTER": [ { "name": "shenzhaowei_master", "label": "My Master Alert", "description":
 "This is my Master alert.", "interval": 1, "scope": "ANY", "enabled": true, "source": {
 "type": "PORT", "uri": "{{zwshen71.example.com:29888}}", "default_port": 29888, "reporting":
 { "ok": { "text": "TCP OK - {0:.3f}s response on port {1}" }, "warning": { "text": "TCP OK -
 {0:.3f}s response on port {1}", "value": 1.5 }, "critical": { "text": "Connection failed:
 {0} to {1}:{2}", "value": 5.0 } } } } ] } }

根据上面的代码，其中“SZWTEST”是 Service 的名字， “SZW_MASTER”是 component 名字（名字要与 metainfo.xml 的配置相匹配）。这两个配置就是用来定义这个 Alert 属于哪个 Service 的哪个模块。下面则是对 Alert 本身属性的定义。Name 是 Alert 的名字，这个用来唯一标识一个 alert。Label 会作为告警的名字显示在 WEB 中的列表（这个配置类似于 metainfo 中的 displayname）。Description 用来描述一个 alert 的用途，是一个显示的内容配置。Interval 用来配置 Alert 监测的间隔时间，单位是秒。Scope 一般都是 any，代表不区分机器。Enable 用来控制 Alert 的开启状态。如果是 false，就代表不启用这个 alert。Source 段用来配置 alert 的类型、阀值以及提示的消息。ok\warning\ critical 就是三种级别的配置。Text 是显示的消息，value 就是阀值。上面代码的配置意思是，如果端口在 5 秒不响应，就会提示连接失败；如果大于 1.5 秒小于 5 秒，则会提示 warning。

上面的示例代码中，我只定义了一个 Alert。如果想同时定义多种（多个）Alert，在增加一个段就可以了。并且可以在一个 alert.json 中同时定义多个 Service 的 alert。这个和一个 metainfo 中定义多个 service 是类似的（这两个本身就是匹配在一起的）。可以参考 Ambari 中 YARN 的配置。

这里需要注意，当 Service 安装完成之后，再修改 Alert.json 是没有用的。Ambari 已经将 Service 相关的告警存入到数据库中了。这时候如果更新 Alert.json，Ambari 便不会再读取里面的配置，即使重启也不行。

图 6. 新增的告警示例