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. 告警示例图
图 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 便不会再读取里面的配置,即使重启也不行。