Ambari Agent源码梳理

本文主要讲述Ambari Agent。源码版本为2.5
（备注：在持续阅读Ambari 源码过程中，内容会不断更新。如果文章有错误，欢迎指正）

目录

1. Ambari-Agent启动
   1.1. Ambari-Agent启动脚本
   1.2. Ambari-Agent 启动过程
2. 关于Controller线程和Agent 主要功能模块
3. Service Auto Start
   3.1. 关于Service Auto Start
   3.1.1. 不支持“不活跃”到“活跃”状态的维护导致的问题
   3.2. Server中对Service Auto Start的处理
   3.2.1. 相关Rest API
   3.2.2. 服务设置Auto Start
   3.2.3. Server处理Auto Start Put请求
   3.2.4. Server将Auto Start动作下方给Agent
   3.3. Agent中对Service Auto Start的处理
   3.3.1. RecoveryManager工作原理
   3.3.2. 主要函数具体处理流程
4. Agent指令执行过程
   4.1. StatusCommands指令执行过程
   4.2. CancelCommands指令执行过程
   4.2.1. 关于CancelCommands的缺陷性
   4.3. executionCommands指令执行过程
5. Ambari Alert
6. Ambari Agent ActionQueue梳理
7. Agent 和Server通信过程梳理

---

1. Ambari Agent启动过程

1.1.Ambari-Agent启动脚本

           Ambari-Agent的启动脚本为/etc/init.d/ambari-agent。该脚本主要实现了start,stop,status,restart,reset方法。对于start,stop,status,reset方法的实现，直接调用/usr/sbin/ambari-agent脚本，将所有命令参数传入进去。Reset直接调用stop,在调用start。
           对于/usr/sbin/ambari-agent的执行如下：

1. 参数检测，如果设置了“–home”参数，则根据参数值，设置HOME_DIR。Ambari-Agent允许在单台节点上运行多个agent客户端（进行集群模拟），每个客户端有自己的配置文件目录。默认情况下，HOME_DIR为空。
2. 设置环境变量CONFIG_FILE=HOME_DIR/etc/ambari-agent/conf/ambari-agent.ini。默认情况下，CONFIG_FILE=/etc/ambari-agent/conf/ambari-agent.ini。
3. 解析CONFIG_FILE文件，根据该配置文件，进行相关环境变量的设置。
4. 检测用户权限，如果该用户不是root用户，则检查该用户是否有sudo权限（通过是否能执行sudo -l 命令，只有拥有sudo权限的用户能使用-l参数）

5. 根据命令，进行命令处理。这里只说明start命令的处理，处理步骤如下：

   a)检查当前python版本；
   b)根据pid文件，检查当前是否有正常运行的agent进程（如果存在pid文件，且存在进程的进程号等于pid文件中记录的进程号，则认为agent已经启动，则抛出异常，返回）
   c)修改相关文件目录权限；
   d)后台运行python脚本,脚本为：/usr/lib/python2.6/site-packages/ambari-agent/AmbariAgent.py。
   e)等待2秒，等待AmbariAgent运行一段时间（AmbariAgent会启动子进程，该进程会创建pid文件，将子进程的pid号写入到pid文件中）；
   f)根据pid号检查agent是否启动正常。
   注意：pid文件不是在启动脚本中创建写入的，而是在/usr/lib/python2.6/site-packages/ambari-agent/main.py中的daemonize函数中创建写入的，写入的是运行main.py的进程号。

1.2.Ambari-Agent 启动过程

           从Ambari-agent启动脚本可知，ambari-agent启动入口点为：/usr/lib/python2.6/site-packages/ambari-agent/AmbariAgent.py。下面主要分析AmbariAgent.py的运行过程。
           AmbariAgent.py脚本比较简单，主要工作是启动子进程，运行/usr/lib/python2.6/site-packages/ambari-agent/main.py脚本。当脚本运行结束后，清理其产生的pid文件。
下面看看main.py主要运行过程如下：

1. Signal信号绑定：
a)主要绑定SigInt信号处理器、SigTerm信号处理器
b)绑定debug类型的SigUSR1,SigUSR2信号和信号处理器
c)创建HeartBeatSopCallback回调处理器。

2. 执行main函数：
a)解析运行参数；
b)日志配置处理；
c)加载解析Ambari-Agent配置文件，解析参数；
d)添加系统日志处理器；
e)启动DataCleaner线程（如果配置文件中配置了data_cleanup_interval参数，且参数值大于0的话）；
f)Agent配置检查;
g)建立tcp服务器，启动tcp服务器（该服务器作为一个机器级的全局的锁）；
h)非windows系统，则创建pid文件，写pid
i)获取配置文件中配置的server列表，依次不断的去连接server,直到和某个server建立连接（或是agent停止）。如果连接成功，调用run_thread方法开始Server - Agent通信流程。
其中run_thread方法执行过程如下：
①　创建Controller线程并启动线程；
②　当Controller线程处于alive状态时，每隔0.1S去检查Controller的Status_Command_Executor状态，如果Status_Command_Executor设置了重启标志，则重启Status_Command_Executor。
③　如果Controller线程处于Dead状态，则给Status_Command_Executor发送agent-stop信号，停止该线程。
整个启动过程过程如下图所示：

2. 关于Ambari Controller线程 和Agent 主要功能模块

           Controller线程是Agent的核心，Agent和Server的交互都是通过Controller线程完成的。通过了解Controller线程，可总体了解Agent的运行框架和主要功能。

Controller线程由main进程创建，线程初始化主要包括：
①　基本参数值设置、初始化，如agent版本，主机名等；
②　请求url配置，如register请求url,heatbeat请求url等；
③　各种cache地址初始化，包括code cache,configuration cache等；
④　初始化ClusterConfiguration属性；
⑤　初始化aler_schedule_handler属性，该成员为一个线程，启动该线程。

Controller线程核心代码（run函数运行逻辑）：
①　初始化actionQueue属性（ActionQueue为线程对象）；
②　初始化statusCommandExecutor属性；
③　启动actionQueue线程；
④　初始化registered，heartbeat属性；
⑤　构建全局的Openner;
⑥　调用registerAndHeartbeat方法，进行host注册、心跳过程（心跳是一个不断循环的过程）
⑦　检查是否需要重新注册，（执行到7，说明心跳结束），如果设置了重新注册标志，则跳到6，否则该线程运行结束。
运行流程如下图所示。

注册+Heartbeat过程在registerAndHeartbeat中实现，其主要过程如下主要执行过程：
①　调用register函数进行host注册，注册步骤如下：
②　注册成功，则调用heartbeatWithServer函数，开始心跳过程。
上述过程如下图所示：

在registerWithServer中完成Agent的注册，注册过程如下所示：
a.向server发送register请求，获取server响应；
b.如果响应中包含”exitstatus”数据，则退出注册流程（没有设置repeatRegister标志）；
c.根据响应数据，调用cluster_configuration更新host配置；
d.根据响应数据，调用recovery_manager更新配置；
e.根据响应数据，更新ambari-agent配置；
f.启动（如果已经启动，则重新启动）statuscommandExecutor(以应用最新的agent配置数据；
g.如果响应中包含statusCommands数据，则将命令加入到StatusCommand队列中等待执行；
h.根据响应，更新Alert_scheduler_handler数据。

Agent的HeartBeat过程在heartbeatWithServer函数中实现，主要任务就是每隔一秒向server发送心跳请求，并获取响应，解析响应，处理响应中包含的指令，指令包括：registerCommand(表示主机需要重新注册）、update_configurations_from_hearbeat、cancelcommands，executionCommands,statusCommand,alerDefinitionCommands,alertExecutionCommands,restartAgent。在心跳过程中，嵌入recovery动作的执行。Recovery是周期性执行，当离上次执行recovery命令的时间大于recoverycommands_interval时，将recovery命令放入到ActionQueue中执行。
整个HeartBeat主要处理过程如下图所示：

备注：recovery命令是周期性执行的，当离上次执行recovery 命令的时间大于getrecoverycommands_interval时，将recovery命令放到ActionQueue中等待执行。

Ambari Agent主要功能模块
Ambari Agent中的Controller线程主要和Ambari Server模块通信，处理Server下发的信息+上报本节点的状态数据。Controller的核心部分就是该heartbeat过程，从Heartbeat处理逻辑可知，Agent的主要功能（模块有）：

1. Recovery 信息、任务处理：由Recovery Manager进行处理。Recovery任务还是在ActionQueue中执行。
2. ActionQueue:大多数命令都在AcitonQueue复杂处理。有ActionQueue复杂任务命令收集、由内部成员CustomOrchesterService进行实际分析处理、执行；并负责处理结果的投放；
3. AlertManager:复杂Alert的处理，调度、执行、更新，内部使用Apscheduler进行Alert的调度；
4. security:复杂和Server建立安全连接，发送请求、接收响应；
5. StatusCommandExecutor:处理Status命令，实际的工作还是交由Actionqueue处理。

3. Ambari Service Auto Start服务

3.1.关于Service Auto Start
在Ambari中服务组件有两种状态：1.Current state(当前实际的状态)；2.desired state(服务预期理想的状态)。如，你想将HDFS服务启动，发送了start命令，但是由于某些原因（如agent掉线了），该start命令并没有正确的执行，则HDFS的current状态为INSTALLED，disired状态为STARTED。而Service Auto Start的作用就是维护服务组件的状态，使得current状态和desired状态一致。目前可维护的状态转换包括：

从上表中可看出，目前可以将服务组件从不活跃的状态转化到活跃的状态，但是不能将活跃的状态状态为不活跃的状态。

3.1.1.不支持“不活跃”到“活跃”状态的维护导致的问题

反过来，当你想将HDFS服务停止，发送了stop命令，但是由于某些原因（如你取消了该命令，服务组件并没有全部执行stop动作），该stop命令并没有正确的执行，则HDFS的current状态为STARTED，disired状态为INSTALLED。当desired state为Installed，但是current state为STARTED状态。当出现这种情况时，Server会不停的给Agent的发送Cancel Command,但是Cancel Command数据为空（因为Server找不到该取消那个动作，事实上上次执行的stop动作是cancel了，所有使得某些服务组件还是维持了started状态）。
实验：

• node2节点上的所有服务都为Started状态。

• 执行stop all component动作，执行一小段时间后，cancel该动作，此时ES,Flume,FileBeat全部stop执行完成，SnameNode执行到一半（该种状态一半没有通过cancel恢复原状态，还是保持Installed状态），Zookeeper没有开始执行stop动作。
  

• Cancel完后各服务组件的状态如下图所示。其中Zookeeper Server还维持在Started状态。
  

• 此时，由于cancel时，server没有修改数据库，各服务组件的desired状态还是Installed。
  

• Agent不断的收到内容的空的CancelCommand(该日志输出为我在agent中输出了语句，源码中没有相应的输出）:
  

3.2.Server中对Service Auto Start的处理

           Service Auto Start的配置分为两种：1，集群全局的配置；2，服务特定的配置。
集群全局配置项包括：
1）recovery_enabled：集群是否允许Service Auto Start；

recovery_type：Auto Start类型，一般设置为AUTO_START。其他类型包括：DEFAULT，AUTO_INSTALL_START，FULL。目前只支持AUTO_START模式。

2）recovery_max_count：Auto start maximum count of recovery attempt allowed per host component in a window. This is reset when agent is restarted.

3）recovery_window_in_minutes：Auto start recovery window size in minutes.
和Auto Start相关的集群全局配置信息在cluter-env.xml文件中。

服务特定的配置主要是配置服务是否需要使用Auto Start服务。

3.2.1.相关Rest API

           1)获取集群全局配置

curl -u admin:admin -i -H 'X-Requested-By:ambari'  -X GET    http://node1:8080/api/v1/clusters/test?fields=Clusters/desired_config/cluster-env

           2)获取特定版本的集群配置

curl -u admin:admin -i -H 'X-Requested-By:ambari'  -X GET    http://node1:8080/api/v1/clusters/test/configurations?type=cluster-env&tag=versoin1

           3)查询所有组件的自启动状态

curl -u admin:admin -i -H 'X-Requested-By:ambari'  -X GET    http://node1:8080/api/v1/clusters/test/components?fields=ServiceComponentInfo/component_name,ServicecomponentInfo/service_name,ServiceComponentInfo/category,ServiceComponentInfo/recovery_enabled

           4)设置组件的自启动状态（？后的数据当作request的predicate处理）：

curl -u admin:admin -i -H 'X-Requested-By:ambari'  -X PUT    'http://node1:8080/api/v1/clusters/test/components?ServiceComponentInfo/component_name.in(XX,YY)'        -d '{"ServiceComponentInfo":{"recovery_enabled":"true"}}'

           例如设置ZOOKEEPER_SERVER的auto start标志

curl -u admin:admin -i -H 'X-Requested-By:ambari'  -X PUT    'http://node1:8080/api/v1/clusters/test/components?ServiceComponentInfo/component_name.in(ZOOKEEPER_SERVER)'        -d '{"ServiceComponentInfo":{"recovery_enabled":"true"}}'

3.2.2.服务设置Auto Start

           服务设置Auto Start可以通过如下几种方式进行设置：
（1）通过Rest API或是在Web页面进行设置；
（2）在服务的metainfo.xml中进行配置。例如：
对于AMBARI_METRICS服务，将服务的METRICS_COLLECTOR组件启用auto start配置，则在component子节点下进行配置，配置如下：

<component>
          <name>METRICS_COLLECTOR</name>
          <displayName>Metrics Collector</displayName>
          <category>MASTER</category>
          <cardinality>1+</cardinality>
          <versionAdvertised>false</versionAdvertised>
          <reassignAllowed>true</reassignAllowed>
          <timelineAppid>AMS-HBASE</timelineAppid>
          <recovery_enabled>true</recovery_enabled>
          ……….
        </component>

3.2.3.Server处理Auto Start Put请求

           服务Auto Start Put请求的处理Service Handle为ComponentService，处理入口为：

  @PUT
  @Produces("text/plain")
  public Response updateComponents(String body, @Context HttpHeaders headers, @Context UriInfo ui) {

    return handleRequest(headers, body, ui, Request.Type.PUT, createComponentResource(
        m_clusterName, m_serviceName, null));
  }

           服务处理Auto Start Put请求的处理过程如下图所示：

3.2.4.Server将Auto Start动作下方给Agent

           Server在每次更新了Auto Start设置后，会将主机上的所有Service auto start enable的组件回合一起发送给Agent，让Agent更新配置。
下发的配置信息如下所示：

RecoverConfig:
{
 u'components': u'ElasticSearch,FileBeatNode,NAMENODE,LogstashNode',
 u'maxCount': u'6',
 u'maxLifetimeCount': u'1024',
 u'recoveryTimestamp': 1508747609285,
 u'retryGap': u'5',
 u'type': u'AUTO_START',
 u'windowInMinutes': u'60'
}

3.3.Agent中对Service Auto Start的处理

           在Agent中，对Service Auto Start的处理主要由RecoveryManager完成。Controller中关于Service Auto Start的入口包含如下两个部分：
（1）Agent在向Server注册时，会根据Server HeartBeat Response信息更新配置；
（2）在HeartBeat循环中，调用RecoveryManager进行auto start服务配置更新、服务状态维护。
下面先讲述RecoveryManager的主要工作原理，在详细分析上面涉及的函数的具体处理过程。
3.3.1.RecoveryManager工作原理

RecoveryManager主要任务包括两个：
1，对Recovery Alert进行处理。但是目前Recovery Alert还没有看到开放的API。
2，根据服务组件的Desired State和Current State产生相应的动作指令，交由ActionQueue执行，使Desired State和Current State一致。
这里主要讲述第二个功能。

3.3.1.1.状态维护 工作原理

为了达到Desired State和Current State一致，RecoveryManager就必须维护服务组件的Desired State和Current State、Auto start使能的服务组件列表。

RecoveryManager使用status多维字典进行维护，每个组件保存三个成员：status[component][‘desired’], status[component][‘current’]和status[component][‘statle_config’]。

对Current状态的维护主要来源于ExecuteCommad。当Agent收到Server的ExecuteCommand后，Agent会根据ExecuteCommand更新一次Current状态。当ActionQueue执行完命令后，会根据命令的执行结果再次更新相关服务组件的相关状态。

这里，ActionQueue执行的Start,Stop,Restart，Status命令都回影响current状态。需要注意的是：Cancel命令的执行并不影响current的状态，也就是说，下方cancel命令后，不管cancel是否成功，Agent都不会更新保存的current状态。对Current状态的维护如下图所示。

对Desired状态的维护比较简单。Desired状态只能由Server改变。当Server下方Status命令时，数据中包含了服务组件的Desired状态。Agent使用该值去更新Desired state。另外，对Stale config的状态的更新同理。状态更新如下图所示。

3.3.1.2.Recovery Command 产生与执行

在Agent Controller HeartBeat主循环中，当距离上次处理Recovery Command时间间隔大于Recovery配置的时间周期后，Agent会从RecoveryManager中获取Recovery Command，然后放到ActionQueue中排队等待执行。

if current_time - getrecoverycommands_timestamp > getrecoverycommands_interval:
  getrecoverycommands_timestamp = current_time
  if not self.actionQueue.tasks_in_progress_or_pending():
    logger.log(logging_level, "Adding recovery commands")
    recovery_commands = self.recovery_manager.get_recovery_commands()
    for recovery_command in recovery_commands:
      logger.info("Adding recovery command %s for component %s",
                  recovery_command['roleCommand'], recovery_command['role'])
      self.addToQueue([recovery_command])

RecoveryManager通过get_recovery_commands函数获取Recovery Commmand，该函数涉及的函数过程见下。
3.3.2.主要函数具体处理流程

从HeartBeat Response中更新配置/recoveryConfig字段处理

对recovery配置的更新主要触发点包括：在向Server注册时，会根据Server Response更新recovery配置。另外当Agent进入HeartBeat过程，当收到的Heartbeat response中包含有recoveryConfig字段时，也会进行配置更新。

registerWithServer：
self.recovery_manager.update_configuration_from_registration(ret)

heartbeatWithServer：
if "recoveryConfig" in response:
  # update the list of components enabled for recovery
  logger.log(logging_level, "Updating recovery config")
  self.recovery_manager.update_configuration_from_registration(response)

更新流程如下图所示。

（2）HeartBeat Response ‘hasPendingTasks’字段的处理

当Server HeartBeat Response中包含有hasPendingTasks字段时，RecoveryManager会设置/重置Paused标志。当设置了该标志时，当向RecoveryManager获取Recovery命令时，RecoveryManager会暂停输出指令，返回空值，使得Agent能够更快的处理排队任务。

（3）产生Recovery Command：get_recovery_commands
目前Recovery Command可产生如下Recovery Command。

获取产生Recovery命令的过程如下图所示。

当组件开启了Recovery enable，且满足状态转换规则时，还需要继续检查是否可对组件产生Recovery Command。组件产生Recovery Command需要满足的条件包括：
a)组件的lifetimeCount次数小于集群配置的max_lifetime_count值。集群的max_lifetime_count值默认为1024；
b)对该组件的Recovery 次数小于集群配置的单组件最大Recovery次数，且距离上次发出recovery命令的时间大于集群配置的重试时间窗口retryGap。或是满足距离上次重置服务组件参数值时间大于集群配置windowInMinutes参数。
（3）Recovery Manager对’statusCommands’的处理
RecoveryManager收到StatusCommands后，主要是从命令中抽取组件的desire state来更新组件的desire状态，另外，如果发现目前组件的Desired state和current state保持一致了，则从RecoveryManager中保存的命令字典中将该组件的Recovery 命令删除（当RecoveryManger产生Recovery命令时，会从该命令字典中获取、配置命令）。
抽取配置信息更新组件的stale config。Recovery Manager对’executionCommands’的处理。

4.Agent指令执行过程

备注：该部分目前看的比较粗糙，以后会重新更新详细的源码分析过程。
4.1.StatusCommands指令执行过程

StatusCommand主要用来检测组件的状态， StatusCommand由Server周期性的发送给Agent,Agent执行后，将检测结果会通过heartbeat 请求传送到Server中。Agent收到StatusCommand后的处理过程如下图所示：

StatusCommandsExecutor并不是一个单独的处理线程。将StatusCommand放入到StatusCommmandsExecutor的命令队列中后，对命令的处理过程在ActionQueue中。在ActionQueue线程的主运行流程Run函数中，会触发对StatusCommand的处理。ActionQueue.run函数相关代码如下：

def run(self):
  try:
    while not self.stopped():
      ………
      self.controller.get_status_commands_executor().process_results() 
    …………..

其中，StatusCommmandsExecutor的 process_results()执行过程如下图所示。

Agent收到的StatusCommand的示例：

    "payloadLevel": "DEFAULT", 
    "desiredState": "STARTED", 
    "clusterName": "test", 
    "componentName": "ZOOKEEPER_SERVER", 
    "hostname": "node2", 
    "hostLevelParams": {
        "stack_version": "2.5", 
        "jdk_location": "http://node1:8080/resources/", 
        "agentCacheDir": "/var/lib/ambari-agent/cache", 
        "stack_name": "HDP"
    }, 
    "commandType": "STATUS_COMMAND", 
    "commandParams": {
        "command_timeout": "1200", 
        "script": "scripts/zookeeper_server.py", 
        "hooks_folder": "HDP/2.0.6/hooks", 
        "service_package_folder": "common-services/ZOOKEEPER/3.4.5/package", 
        "script_type": "PYTHON"
    }, 
    "serviceName": "ZOOKEEPER", 
    "agentConfigParams": {
        "agent": {
            "parallel_execution": 0, 
            "use_system_proxy_settings": true
        }
    }, 
"configuration_attributes": {
…………

4.2.CancelCommands指令执行过程

当Agent收到CancelCommands后，直接调用ActionQueue的cancel函数处理cancelCommands。Agent对cancle命令的处理比较简单，处理流程如下图所示。

4.2.1.关于CancelCommands的缺陷性

server 下发command时，agent首先在actionqueue中删除原executionCommand,如果executionCommand正在执行，则直接kill process。
问题：server收到 cancel动作后，不会走数据库，不会修改host component的desired state。如果service commponent 设置了service auto start，则会通过recovery manager继续完成executionCommand。
关于该问题的实验：

1. node2上所有组件都处于stop状态，执行start
   all动作，在执行一小段时间后，cancel该动作，则由一部份动作还没有开始执行，状态如下：
   

2. 查询数据库状态，此时数据库状态如下（全部为start)：
select * from hostcomponentdesiredstate where host_id=2;

3. 查询agent log，agent收到cancel command,但是同时产生recovery command:

4. SNameNode,Flue设置了service auto start，会被Agent再次启动起来，相当于继续完成了被Cancel的动作。最后的状态如下图示所示。（Logfeeder变成stop是因为没有对logfeeder进行配置，运行抛出异常而停止，和此实验无关）。

4.3.executionCommands指令执行过程
Server中主要的动作由ActionQueue执行（如服务启动、停止等，其他动作如Recovery等由其他线程处理）。
ActionQueue执行命令时有两种模式：串行模式和并行模式。在并行模式下，如果命令可以重试，则ActionQueue启动子线程执行执行；否则依然在本线程中处理该命令。在串行模式下，所有的执行都是在本线程中执行的。
命令执行通过调用ActionQueue的process_command函数完成。在process_command函数中主要是对非法指令做过滤，然后调用execute_command执行命令。在Execute_command通过调用CustomServiceOrchestrator的runCommand函数执行命令。
Service Response中对于每个非空指令，都包含如下参数：
①　serviceName:指令针对的服务
②　requestId:本次响应对应的requestID
③　roleCommand:动作类型，如Start,Stop
④　commandParams:包括对应的服务目录、操作脚本、脚本类型等。
如向server发送请求，停止ElasticSearch服务，则在host1（安装了ElasticSeach服务的节点）上收到的command数据如下所示：

u'executionCommands': [
{ u'localComponents':[ u'ElasticSearch',u'FileBeatNode', …….], u'configuration_attributes': {u'ranger-hdfs-audit': {}, …….}, u'commandId': u'441-0', 
u'hostname': u'node1', 
u'kerberosCommandParams': [],
u'serviceName': u'ELASTICSEARCH', 
 u'role': u'ElasticSearch', 
u'forceRefreshConfigTagsBeforeExecution': False, 
u'requestId': 441, 
 u'clusterName': u'mycluster', 
u'commandType': u'EXECUTION_COMMAND', 
u'taskId': 4406, u'roleParams': {}, 
 u'configurationTags': {u'ranger-hdfs-audit':{u'tag':u'version1505992064363'},…}, 
u'configuration_credentials': {}, 
u'roleCommand': u'STOP', 
u'credentialStoreEnabled': u'false', 
u'hostLevelParams': {u'agent_stack_retry_on_unavailability':…. }, 
u'commandParams': {   u'service_package_folder': u'stacks/HDP/2.5/services/ELASTICSEARCH/package', 
          u'script': u'scripts/master.py', 
          u'hooks_folder': u'HDP/2.0.6/hooks', 
          u'version': u'2.5.0.0-1245', 
          u'max_duration_for_retries': u'0', 
          u'command_retry_enabled': u'false', 
          u'command_timeout': u'600', 
          u'script_type': u'PYTHON'}, 
 u'stageId': ……

目前Ambari只支持python类型脚本。在CustomServiceOrchestrator执行命令过程：
1）根据收到的command,在/var/lib/ambari-agent/data中生成相关的command-taskId.json记录文件
2）获取python执行器，执行python脚本，脚本包括服务的动作执行前的hook脚本、命令动作脚本、动作执行后的hook脚本。
executeComand指令处理主要流程如下图所示：

5. Agent 和Server通信过程梳理

6.Ambari 告警
见Ambari Alert告警服务源码分析（Agent部分）
http://blog.csdn.net/youyou1543724847/article/details/78377400

7.关于ActionQueue
等待更新