Ambari下服务资源的定义结构如下图所示:
|_ stacks
|_
|_
metainfo.xml
|_ hooks
|_ repos
repoinfo.xml
|_ services
|_
metainfo.xml
metrics.json
|_ configuration
{configuration files}
|_ package
{files, scripts, templates}
下面就以Elasticsearch服务的集成为例,对所有核心的实现内容逐一讲解,elasticsearch集成项目定义结构如下图所示:
首先,通过metainfo.xml文件对elasticsearch这个服务进行一个标准的描述,完整文件如下所示:
2.0
ELASTICSEARCH
Elasticsearch
A highly scalable open-source full-text search and analytics engine. Including storage, searching, and analyzing big volumes of data quickly and in near real time.
6.4.2
ELASTICSEARCH_MASTER
Elasticsearch Master
MASTER
1+
true
PYTHON
1200
elasticsearch_master
true
ELASTICSEARCH_SLAVE
Elasticsearch Slave
SLAVE
0+
true
PYTHON
1200
elasticsearch_slave
true
any
elasticsearch-6.4.2
PYTHON
300
elasticsearch-config
elasticsearch-env
elasticsearch-log4j
true
quicklinks.json
true
=========================================================================================
定义服务的名称,显示名称,描述,版本号等核心信息:
ELASTICSEARCH
Elasticsearch
A highly scalable open-source full-text search and analytics engine. Including storage, searching, and analyzing big volumes of data quickly and in near real time.
6.4.2
=========================================================================================
定义服务的组件信息,这里针对elasticsearch的实现,分为了两种组件:master和slave,这里以master为例:
ELASTICSEARCH_MASTER
Elasticsearch Master
MASTER
1+
true
PYTHON
1200
elasticsearch_master
true
其中基础信息包括组件名称(name),组件显示名称(displayname)。
其它的几个较重要参数,包括:
1) category:描述组件是主服务、节点从服务或是客户端。
category 类别 | 默认生命周期命令实现 |
MASTER | install, start, stop, configure, status |
SLAVE | install, start, stop, configure, status |
CLIENT | install, configure, status |
2)cardinality:描述组件的数量限制。
cardinality格式 | 格式说明举例 |
数字 | |
数字区间 | |
数字单增区间 | |
ALL |
3)commandScript:组件生命周期命令的执行脚本实现。
=========================================================================================
所支持的OS系统定义,以及需要安装的软件包(此处作者在脚本实现过程中没有执行依赖包安装,默认各依赖均已具备):
any
elasticsearch-6.4.2
osFamily可定义如:redhat6,redhat7,ubuntu14,ubuntu16等。
package-name,即为yum install或apt-get install的软件包名称。
=========================================================================================
服务检查的脚本实现(注意,此py脚本的命名要保持一致):
PYTHON
300
=========================================================================================
配置文件依赖,即服务安装前需要填写或修改的配置文件:
elasticsearch-config
elasticsearch-env
elasticsearch-log4j
=========================================================================================
修改配置后是否重启(一般都为true):
true
=========================================================================================
界面快速链接的json脚本实现(注意,此json脚本的命名要保持一致):
quicklinks.json
true
请参考:官方说明(中文翻译)
configuration的目录及内容如下图所示(不包括original,这个是作者为了方便开发放入的原始配置文件):
这里可以简单分为两种类型的配置文件,及-env和其它。
1)-env.xml 配置文件
env配置要求必须存在,主要描述安装包路径,用户,组,pid文件目录,根目录等。文件内容此处截取部分以作简单举例,如下图所示:
elasticsearch.download.url
Elasticsearch Download Url
Elasticsearch package download url. The official download url is: https://artifacts.elastic.co/downloads/elasticsearch/elasticsearch-6.4.2.tar.gz
elasticsearch.user
elasticsearch
Elasticsearch User
USER
Elasticsearch unix user.
elasticsearch.group
elasticsearch
Elasticsearch Group
GROUP
Elasticsearch unix group.
elasticsearch.base.dir
/opt/elasticsearch
Elasticsearch Base Directory
Elasticsearch base directory.
elasticsearch.pid.dir
/var/run/elasticsearch
Elasticsearch Pid Directory
Elasticsearch pid file directory.
2)其它应用配置文件
其它应用配置配置文件即指应用本身所需的配置文件,例如elasticsearch的核心配置文件:elasticsearch.yml。但是我们在做实现的时候,并非要严格按照原始配置文件的格式。例如,可以将elasticsearch.yml中的内存拆分为多个部分,如es-config-general.xml和es-config-network.xml等。在作者的实现中,作者将jvm.options的内容放入了-env配置文件,然后-config.xml文件对应elasticsearch.yml。
具体的配置映射实现方式,将在第三节package 中说明。大家只要知道,此处的配置文件,就是为了在Ambari上安装服务或是安装服务后修改配置时展现配置并接受配置参数所实现的,如下图内容:
上面讲了配置文件的类型定义,下面详细说下内容格式。
默认我们使用最简单的格式,如下:
elasticsearch.base.dir
/opt/elasticsearch
但是上述格式,缺少了说明,且参数文字的显示效果可能不是很好。我们可以添加
elasticsearch.base.dir
/opt/elasticsearch
Elasticsearch Base Directory
Elasticsearch base directory.
效果如图所示:
默认情况下,
server.basePath
none
true
Server Base Path
此处要注意,xml中boolean值的内容请填写false或true,但是后续代码在获取参数时,获取的是boolean类型的False和True。
server.rewriteBasePath
false
boolean
false
Server Rewrite Base Path
xxxx
zeppelin.ssl.keystore.password
change me
password
PASSWORD
Keystore password. Can be obfuscated by the Jetty Password tool
ops.interval
5000
int
100
50000
Milliseconds
100
false
Ops Interval
Set the interval in milliseconds to sample system and process performance metrics. Minimum is 100ms. Defaults to 5000.
上述格式已然能满足大部分需求了。当然,Ambari对此xml文件的支持还包括很多其它参数,有兴趣的童鞋可参考Ambari下的通用服务目录下的配置:/var/lib/ambari-server/resources/common-services。
package的目录及内容如下图所示:
其中,params、service_check和status_params为必实现的脚本,分别用于参数的获取和加工、服务检查、为服务检查提供参数;es_master和es_slave是根据组件(component)区分的声明周期实现脚本,如下所示:
脚本 | 具体实现 | 要求及说明 |
params.py | 通过Script类的方法读取之前configuration文件夹中.xml文件定义的各个配置变量,有需要的话进行进一步加工,例如单位的添加,列表的解析,布尔值的转换等 | 脚本名称不可修改 |
service_check.py | 可直接使用内置方法实现,具体请见源码 | 脚本名称要与metainfo.xml中定义的保持一致 |
status_params.py | 引用pid文件目录及文件参数即可 | 内容参数可以与params中的对应项保持一致(之所以独立,是受ambari的检查机制读所限,其在做检查时是不会走params的) |
es_master.py/es_slave.py | 组件的install,start,stop等命令的实现 | 脚本名称要与metainfo.xml中定义的保持一致 |
具体内容,请参见源码,都是模式化的实现,很简单。
通过.xml对配置的定义,以及params.py对配置项的处理,以jinjia2为基础的templates模板将最终完成配置映射到原始应用配置文件的过程。例如:
在elasticsearch.master.yml.j2文件中引用params中定义好的用于master节点的配置,如:
# ----------------------------------- Paths ------------------------------------
#
# Path to directory where to store the data (separate multiple locations by comma):
#
path.data: {{master_path_data}}
#
# Path to log files:
#
path.logs: {{master_path_logs}}
在configure方法的实现中,实现master模板和对应master配置文件的替换:
configurations = params.config['configurations']['elasticsearch-config']
File(format("{es_master_conf_dir}/elasticsearch.yml"),
content=Template("elasticsearch.master.yml.j2", configurations=configurations),
owner=params.es_user,
group=params.es_group
)
4. 其它资源文件
基础格式如下,只需改写显示名称,组件名称,对应的端口号即可。property请填写.xml中定义的端口参数名称(此处作者比较偷懒,直接走默认端口):
{
"name": "default",
"description": "default quick links configuration",
"configuration": {
"protocol": {
"type":"http",
"checks":[
]
},
"links": [
{
"name": "elasticsearch_ui",
"label": "Elasticsearch UI",
"requires_user_name": "false",
"component_name": "ELASTICSEARCH_MASTER",
"url":"%@://%@:%@",
"port":{
"http_property": "http_port",
"http_default_port": "9200",
"https_property": "http_port",
"https_default_port": "9200",
"regex": "\\w*:(\\d+)",
"site": "elastic-config"
}
}
]
}
}
通quicklinks一样,作者犯懒,只实现了针对端口的简单检查。只需要改写服务名称,组件名称,说明信息,端口号即可。
{
"ELASTICSEARCH": {
"service": [],
"ELASTICSEARCH_MASTER": [
{
"name": "elasticsearch_port",
"label": "Elasticsearch Port",
"description": "This host-level alert is triggered if the 9200 port is unreachable.",
"interval": 1,
"scope": "HOST",
"source": {
"type": "PORT",
"uri": "{{elasticsearch-config/http.port}}",
"default_port": 9200,
"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
}
}
}
}
]
}
}
其它更为复杂的alerts.json配置同样请参考Ambari(HDP)下内置Hadoop组件的配置:/var/lib/ambari-server/resources/common-services。
对于监控,作者在此只做下简单说明。如果要求Ambari与第三方软件集成实现监控,仅仅简单实现metrics.json和widgets.json是不够的。此两个配置文件,仅能实现界面监控图表的显示和图标对应metrics信息的关联实现,但是不能实现具体数据的采集。这里官网文档也仅以几句话简单带过:
刚开始作者傻傻地以为有多智能,只要json定义了采集项,采集信息就能自动收集。实际上并不行,上图的说明并不全。首选,要有采集的实现,将数据采集送给monitor。这个部分Ambari自己的Hadoop组件有专门的Hadoop sinks做了实现。而上述第一条所阐述的内容同样需要自行通过脚本或是代码实现将信息推送至collector。之后第二条和第三条才是定义metrics和widgets。
另外Elasticsearch在6.3之后已经天然集成x-pack。用过x-pack的肯定都知道其秒级的监控实现。所以监控这块其自身实现已然很强大了。具体内容在下一章节会进行简单说明。