本文主要講述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通訊過程梳理

7.關於ActionQueue
等待更新