Ambari 學習指南

作用：

Hadoop 是用在商業主機網路集群上的大規模、分布式的資料存盤和處理基礎架構，監控和管理如此復雜的分布式系統是不簡單的，為了管理這種復雜性，

Apache Ambari 從集群節點和服務收集了大量的資訊，并把它們表現為容易使用的，集中化的介面：Ambari Web

功能：

顯示諸如服務特定的摘要、圖表以及警報資訊

創建和管理 HDP 集群并執行基本的操作任務，例如啟動和停止服務，向集群

中添加主機，以及更新服務配置

執行集群管理任務，例如啟用 Kerberos 安全以及執行 Stack 升級

使用：

1. Dashboard（儀表盤）

   使用集群儀表盤來監控 Hadoop 集群，通過單機 Ambari Web UI 主視窗頂端的 Dashboard 訪問集群儀表盤，Ambari Web UI 顯示儀表盤頁作為主頁，使用儀表盤來查看集群的操作狀態，Ambari Web 左側顯示集群當前運行的 Hadoop 服務串列，儀表盤包括 Metrics, Heatmaps, 以及Config History 選項卡；默認顯示 Metrics 選項卡，

   1.1 Metrics在Metrics 頁面上，有多個小程式(widget), 表現 HDP 集群服務的操作狀態資訊，多數小程式顯示一個度量值(metric), 例如，HDFS Disk Usage 表示為一個負載圖表和一個百分數指示，

   HDFS：

           NameNode Heap        ：NameNode Java Virtual Machine (JVM) 堆記憶體使用的百分數，

           HDFS Disk Usage        ：分布式檔案系統(DFS) 已使用的百分比，包括 DFS 和 non-DFS

           NameNode CPU WIO    ：CPU wait I/O 百分比

           Data Nodes Live        ：運轉中的 DataNodes 的數量，由 NameNode 報告

           NameNode RPC        ：潛在 RPC 佇列平均水平 (The average RPC queue latency)

           NameNode Uptime        ：NameNode 正常運行時間計算值(uptime calculation)

   YARN：

           ResourceManager Heap    : 以使用的 ResourceManager JVM 堆記憶體百分比

           NodeManagers Live        ：運轉中的 DataNodes 數量，由 ResourceManager 報告

           ResourceManager Uptime    ：ResourceManager uptime

           YARN Memory                ：可用的 YARN 記憶體百分數(used versus total available)

   HBase：

           HBase Master Heap        : 已使用的 NameNode JVM 對記憶體百分數

           HBase Ave Load            ：HBase server 上的平均負載

           Region in Transition    ：轉換中的 HBase regions 數量

           HBase Master Uptime        ：HBase master uptime

   Storm：

   Supervisors Live ：運轉中的 supervisor 的數量，由 Nimbus Server 報告

   Cluster-Wide：

   Memory usage    : 集群范圍的記憶體使用，包括快取的(cached)，交換的(swapped), 使用的(used), 以及共享的(shared)

   Network usage    : 集群范圍的網路利用，包括輸入和輸出(including in-and-out)

   CPU Usage        : 集群范圍的 CPU 資訊，包括系統的，用戶的及 wait IO (including system, user and wait IO)

   Cluster Load    : 集群范圍負載資訊，包括節點總數， CPU 總數，運行的行程數量，以及 1-min Load

    

   1.2Heatmaps：評價指標可視化

   如前所述，Ambari web 主頁左側被切分出一個狀態摘要面板，并在頂部有 Metrics, Heatmaps, 和 Config History 選項卡，默認顯示 Metrics 選項卡，

   當要查看整個集群利用情況的圖形表示時，單擊 Heatmaps 選項卡，使用簡單的顏色代碼，稱為 heatmap, 提供這類資訊，

   集群中每個主機表示為一個帶顏色的塊，將滑鼠懸停在主機的顏色塊上可以看到該主機更多的資訊，在另一視窗上顯示有關主機上安裝的 HDP 組件的度量值，

   在塊中顯示的顏色表示在一組選定的 metric 單元中的使用率，如果任何確定使用率的必要的資料不可用，這個塊顯示為 Invalid data. 通過修改 heatmap

   默認的最大值解決這個問題，使用 Select Metric 選單

   1.3Config History：配置歷史

    

2. Service

   2.1 操作狀態

   Ambari Web 左側的服務摘要串列列出了當前監控的所有 Apache 組件服務，圖示的形狀，顏色，以及每個條目左側的動作指明了每個條目的操作狀態：

   實心綠 (solid green) | All masters are running

   閃爍綠(blinking green) | Starting up

   實心紅 (solid red) | At least one master is down

   閃爍紅 (blinking red) | Stopping

   2.2鏈接到服務 UI (Linking to Service UIs)

   HDFS Links 和 HBase Links widgets 列出 HDP 組件用于鏈接到更多的 metric 資訊，可用的執行緒堆疊，日志，以及純組件 UI. 例如，可以為 HDFS 鏈接到

   NameNode, Secondary NameNode, 和 DataNode ，

   單擊 More 下拉串列從每個服務可用的鏈接串列中選擇，Ambari Dashboard 包括如下服務的度量的附加鏈接：

   HDFS：

       NameNode UI        ：Links to the NameNode UI

       NameNode Logs    ：Links to the NameNode logs

       NameNode JMX     ：Links to the NameNode JMX servlet

       Thread Stacks     ：Links to the NameNode thread stack traces

   HBase：

       HBase Master UI     ：Links to the HBase Master UI

       HBase Logs             ：Links to the HBase logs

       ZooKeeper Info         ：Links to ZooKeeper information

       HBase Master JMX     ：Links to the HBase Master JMX servlet

       Debug Dump             ：Links to debug information

   Thread Stacks         ：Links to the HBase Master thread stack traces

    

3. Hosts

   作為集群系統管理員或集群操作員，需要知道每部主機的操作狀態，也需要知道哪部主機有問題需要處理，可以使用 Ambari Web Hosts 頁面來管理多個Hortonworks Data Platform (HDP) 組件，例如運行在整個集群上 DataNodes, NameNodes, NodeManagers, 和 RegionServers. 舉例來說，可以重啟所有的DataNode 組件，可選地控制滾動重啟任務，Ambari Hosts 可以過濾進行管理的主機組件選取，基于操作狀態，主機健康狀況，以及定義的主機分組，

   

   3.1理解主機狀態 (Understanding Host Status)

   可以在 Ambari Web Hosts 頁面查看集群上單個主機的狀態，主機以 fully qualified domain name (FDQN)的形式列出，并附有一個帶有顏色的圖示指示出

   主機的操作狀態，

    ● 紅色三角形    ：該主機上至少有一個 master 組件掛掉了，滑鼠懸停圖示上查看一個工具提示列出受影響的組件，

    ● 橘色            ：該主機上至少有一個 slave 組件掛掉了，滑鼠懸停圖示上查看一個工具提示列出受影響的組件，

   ● 黃色            : Ambari Server 沒有從該主機上收到心跳包超過 3 分鐘，

   ● 綠色            ：正常運行狀態，

   ● Maintenace Mode    ：黑色 "醫藥箱" 圖示指出一部主機處于維護模式，

   ● Alert            ：紅色方框帶有一個數字指明該主機上的警報數量，

   紅色圖示覆寫橘色圖示，橘色圖示覆寫黃色圖示，換句話說，一部主機有 master component 宕機附有一個紅色圖示，即便它可能也有 slave component 和連接問題，主機處于維護模式或遇到警報，圖示出現在主機名右側，

   3.2 查找主機頁面 (Searching the Hosts Page)

   可以查找完全主機串列，通過主機名，組件屬性，以及組件操作狀態過濾查找，也可以通過關鍵字查找，簡單地在搜索框內輸入一個單詞，

   主機搜索工具在主機串列上方

   ① 單擊搜索框

    出現可用的搜索型別，包括：

   通過主機屬性搜索    ：通過 host name, IP, host status 以及其他屬性

   Search by Service    ：通過給定一個服務，查找運行此服務組件主機

   Search by Component    ：查找運行某組件處于給定狀態的主機，例如 started, stopped, maintenance mode, 等等，

   Search by keyword    ：在搜索框輸入任何單詞描述要查找的內容，這成為一個文本過濾器， 

   ② 單擊搜索型別

   出現一個可用選項的串列，取決于在第一步中的選擇

   例如，如果選擇單擊了 Service, 當前服務出現

   ③ 單擊一個選項

   匹配當前搜索條件的串列顯示到 Hosts 頁面

   ④ 單擊下一選項再次調整搜索

   3.3 執行主機級別的動作 (Performing Host-Level Actions)

   利用 Actions UI 控制元件對集群主機執行動作，可以執行的動作(Actions)由一個一上的操作(operation)組成，可能在多個主機上，也稱為批量操作(bulkoperations).

   Actions 控制元件由三個順序的選單精確定義(to refine your search) 的作業流組成：一個主機選單，一個基于主機選擇的物件選單，基于物件選擇的動作選單，

   例如，如果要重啟集群中任何存在 RegionServers 主機的 RegionServers 服務組件：

   ① 在 Hosts 頁面，選擇或查找運行 RegionServer 到主機：

   ② 利用 Actions 控制元件，單擊 Fitered Hosts > RegionServers > Restart

   ③ 單擊 OK 來啟動選定的操作

   ④ 可選地，監控后臺操作，診斷或處理重啟操作故障

   3.4 管理主機上的組件 (Managing Components on a Host)

   管理特定主機上運行的組件，在 Hosts 頁面列出的 FDQN 中單擊一個，那個主機的頁面出現，單擊 Summary 選項卡顯示組件面板列出該主機安裝的所有組件

   要管理一部主機上所有的組件，可以利用顯示視窗右上角的 Host Actions 控制元件來對所選主機上安裝的所有組件 start, stop, restart, delete, 或turn on maintenance mode

   另一方面，可以管理單個組件，利用在組件面板內顯示在每個單獨組件旁邊的下拉選單，每個組件的選單標示了組件當前的操作狀態，打開選單，顯示可用的管理選項，基于標示的狀態，例如，可以 HDFS 的 DataNode 組件執行 decommission, restart, or stop 動作

   3.5 退役一個 Master 或 Slave (Decommissioning a Master or Slave)

   退役是支持從集群中移除組件和它們的主機的程序，在移除主機或從服務上移除主機之前，必須退役運行在該主機上的 master 或 slave 服務，退役有助于保護資料丟失或服務損壞，退役對于下列組件型別可用：DataNodes、 NodeManagers、RegionServers 

   退役執行下列任務：

   對于 DataNodes        ：安全地復制 HDFS 資料到集群中其他的 DataNodes

   對于 NodeManagers    ：停止接受新作業的請求并停止組件

   對于 RegionServers    ：打開 drain mode 并停止組件

   3.6 退役和洗掉組件

   3.6.1 退役一個組件 (Decommission a Component)

   ① 利用 Ambari Web，瀏覽到 Hosts 頁面

   ② 找到并單擊組件駐留的主機 FQDN

   ③ 使用 Actions 控制元件，單擊 Selected Hosts > DataNodes > Decommission

   程序中 UI 顯示退役中(Decommissioning)狀態

   退役程序完成時，退役狀態變為已退役 (Decommissioned)

   3.6.2 洗掉一個組件 (Delete a Component)

   ① 利用 Ambari Web，瀏覽到 Hosts 頁面

   ② 找到并單擊組件駐留的主機 FQDN

   ③ 在 Components 中, 找到一個要退役的組件

   ④ 如果該組件的狀態是 Started, 停止它

    一個退役的 slave 組件可以在已退役狀態重啟    

   ⑤ 從組件下拉選單中單擊 Delete 

   洗掉一個 slave 組件，如一個 DataNode 不會自動通知 master 組件，如 NameNode 從它的排除串列中移除那個 slave 組件，添加一個已洗掉的組件回到集群表現出如下問題，從 master 的視角觀察，添加進來的 slave 保持在退役狀態，重啟 master 組件可排除故障

   ⑥ 讓 Ambari 識別并監控余下的組件，重啟服務，

   3.7 從集群洗掉一個主機 (Deleting a Host from a Cluster)

   洗掉一個主機從集群中移除該主機

   先決條件：在洗掉一部主機之前，必須完成如下前提：

   ● 停止該主機上運行的所有組件

   ● 退役運行在該主機上的所有 DataNode

   ● 遷移該主機上所有的 master 組件，例如 NameNode 或 ResourceManager

   ● 關閉主機的維護模式(Maintenance Mode)

   步驟：

   ① 利用 Ambari Web，瀏覽到 Hosts 頁面, 找到并單擊要洗掉的主機 FQDN

   ② 在 Host-Details 頁面，單擊 Host Actions

   ③ 單擊 Delete

   3.8 設定維護模式 (Setting Maintenance Mode)

   在一個 Ambari-managed 集群上，當要專注于執行硬體或軟體維護，修改配置設定，處理故障，退役，或移除集群節點時，設定維護模式可以阻止警報，并

   去掉在特定服務，組件，以及主機上的批操作(omit bulk operations)，

   顯示設定一個服務的維護模式，隱含地設定了運行此服務的組件和主機的維護模式，如果維護模式阻止了要執行在服務，組件，或主機上的批操作，可以在

   維護模式中顯式地啟動和停止服務、組件、或主機，

   下面幾節提供了一個案例，如何在有三個節點，Ambari 管理集群上使用維護模式，描述如何顯式地打開(turn on) HDFS 服務的維護模式，主機，以及隱式地

   打開服務、組件，以及主機的維護模式，

   3.8.1 設定服務維護模式 (Set Maintenance Mode for a Servicee)

   ① 在 Services 頁面，選擇 HDFS

   ② 選擇 Service Actions, 然后選擇 Turn On Maintenance Mode

   ③ OK 確認

   注意，在 Services Summary, NameNode 和 SNameNode 組件的 Maintenance Mode 打開

   3.8.2 設定主機維護模式 (Set Maintenance Mode for a Host)

   使用 Host Actions 控制元件設定主機維護模式

   步驟：

   ① Hosts 頁，選擇主機 FDQN

   ② 選擇 Host Actions, 然后選擇 Turn On Maintenance Mode.

   ③ OK 確認

   注意，主機上所有的組件打開維護模式

   使用 Actions 控制元件設定主機維護模式

   步驟：

   ① Hosts 頁，選擇主機 FDQN

   ② 在 Actions > Selected Hosts > Hosts, 選擇 Turn On Maintenance Mode.

   ③ OK 確認

   3.8.3 何時設定維護模式 (When to Set Maintenance Mode)

   設定維護模式的四個一般場景為：執行維護，測驗配置修改，測底洗掉一個服務，處理警報，

   ■ 要在一部主機上執行硬體或作業系統維護

   執行維護時，要能夠做如下操作：

   ● 阻止這部主機上所有組件生產警報

   ● 能夠停止、啟動、以及重啟主機上的每一個組件

   ● 阻止該主機 host-level 或 service-level 的 starting, stopping, 或 restarting 組件批操作為了達成這些目標，顯示設定主機的維護模式，將這部主機上所有的組件隱式地設定為維護模式，

   ■ 要測驗一個服務配置的修改，應該停止、啟動、以及重啟服務來測驗重啟是否激活了配置的變化

   要測驗配置資訊的變化，要確保如下條件：

   ● 這個服務上沒有任何組件生成警報

   ● 這個服務上沒有 host-level 貨 service-level 的批操作啟動、停止、或 重啟組件

   為了達成這些目標，顯示設定服務維護模式，將一個服務設定為維護模式隱式地為該服務的所有組件打開維護模式

   ■ 要停止一個服務

   要完全停止一個服務，需要確保如下條件： 

   ● 這個服務沒有生成 warnings

   ● 沒有由 host-level 的動作或批操作導致的組件啟動，停止，或重啟

   為了達成這些目標，顯示為服務設定維護模式，將一個服務設定為維護模式隱式地為該服務的所有組件打開維護模式

   ■ 要停止一個主機組件生成警報

   要停止一個主機組件生成警報，必須能夠做到如下內容：

   ● 檢查組件

   ● 訪問該組件生成的 warnings 和 alerts

   為了達成這些目標，為主機組件顯示設定維護模式，將主機組件設定為維護模式，阻止 prevents host-level 和 service-level 批操作 starting 或restarting 該組件，可以在維護模式開啟狀態系顯示重啟該組件，

   3.9 向集群添加主機 (Add Hosts to a Cluster)

   ① 瀏覽到 Hosts 頁面然后選擇 Actions > +Add New Hosts

   Add Host 向導提供一系列提示類似于 Ambari 集群安裝向導(Ambari Cluster Install wizard.)

   ② 跟隨提示，提供相關資訊，繼續完成向導

   3.10 建立機架感知 (Establishing Rack Awareness)

   有兩種方法建立機架感知，要么使用 Ambari 設定 rack ID, 或者利用自定義拓撲腳本(topology script) 設定 rack ID.

   3.10.1 利用 Ambari 設定機架 ID (Set the Rack ID Using Ambari)

   通過設定 Rack ID, 使 Ambari 為主機管理機架資訊，包括在 heatmaps 中通過 Rack ID 顯式主機，使用戶能過濾并在 Hosts 頁面通過 Rack ID 查找主機

   如果集群中安裝了 HDFS, Ambari 通過使用拓撲腳本將 Rack ID 資訊傳遞給 HDFS. Ambari 生成的拓撲腳本在 /etc/hadoop/conf/topology.py 位置，并自動設定 core-site 中的 net.topology.script.file.name 屬性，這個腳本讀取一個 Ambari 自動生成的 /etc/hadoop/conf/topology_mappings.data 映射檔案，當你在 Ambari 中修改 Rack ID 分配時，這個映射檔案會在推進(push out) HDFS 配置資訊時更新，HDFS 利用這個拓撲腳本獲得 DataNode 主機的機架資訊，有兩種方法利用 Ambari Web 設定 Rack ID: 對于多主機，使用 Actions, 或者對于單個的主機，使用 Host Actions

   ■ 為多個主機設定 Rack ID

   步驟：

   ① 使用 Actions, 單擊 selected, filtered, 或 all hosts

   ② 單擊 Hosts.

   ③ 單擊 Set Rack

    ■ 在單個主機上設定 Rack ID

   步驟：     

   ① 瀏覽到 Host 頁面

   ② 單擊 Host Actions

   ③ 單擊 Set Rack

   3.10.2 利用自定義拓撲腳本設定機架 ID (Set the Rack ID Using a Custom Topology Script)

   如果不想 Ambari 管理主機到機架資訊，可以使用自定義到拓撲腳本，要做到這一點，必須創建自己的拓撲腳本管理分布腳本到所有主機，注意，也因為Ambari 不能訪問到主機機架資訊，Ambari Web 中的 heatmaps 不能顯示機架，

   使用自定義腳本設定 Rack ID:

   步驟：

   ① 瀏覽到 Services > HDFS > Configs

   ② 修改 net.topology.script.file.name 為自己的自定義拓撲腳本

   如，/etc/hadoop/conf/topology.sh

   ③ 分布拓撲腳本到所有主機上

   現在，可以為 Ambari 之外的腳本管理機架映射資訊了，

    

4. 管理服務 (Managing Services)

   利用 Ambari Web UI 主頁的 Services 選項卡監控和管理運行于集群上選定的服務，

   集群上安裝的所有服務列于左側的面板上：

   4.1 啟動和管理所有服務 (Starting and Stopping All Services)

   同時啟動或停止列出的所有服務，單擊 Actions 然后單擊 Start All 或 Stop All:

   4.2 顯示服務操作摘要 (Displaying Service Operating Summary)

   從服務串列上單擊服務的名稱，顯示出 Summary 選項卡含有關于此服務操作狀態的基本資訊，包括警報，要重繪監控面板并顯示另一個服務的資訊，可以在服務串列上單擊一個不同的服務名稱，

   注意服務名稱后面帶有顏色的圖示，指出服務的操作狀態和該服務生成的警報，可以單擊一個 View Host 鏈接來查看組件和運行選定組件的主機，

   4.2.1 警報和健康檢查 (Alerts and Health Checks)

   在 Summary tab, 可以單擊 Alerts 來查看所有健康檢查串列以及所選中服務的狀態，重要警報首先顯示，要查看警報定義，可以單擊串列中每個警報訊息的文本標題來查看警報定義，例如單擊 HBase > Services > Alerts > HBase Master Process

   4.2.2 修改服務表盤 (Modifying the Service Dashboard)

   取決于所選擇的服務，Summary tab 包含一個 Metrics 表盤，默認含有重要的服務度量的監控

   如果安裝了 Ambari Metrics 服務并使用 Apache HDFS, Apache Hive, Apache HBase, 或 Apache YARN, 可以自定義度量表盤，可以向 Metrics 表盤添加

   或從表盤上移除 widget, 并可以創建新的 widget 或洗掉 widget，widget 可以是對你或你的表盤私有的(private), 或者可以共享到 Widget Browser 庫，

   必須已經安裝 Ambari Metrics 服務才能查看，創建，以及自定義 Metrics 表盤，

   4.2.2.1 添加或移除一個 Widget (Adding or Removing a Widget)

   要在 HDFS, Hive, HBase, 或 YARN 服務的 Metrics 表盤中添加或移除一個 widget:

    

   ① 或者單擊 + 號圖示啟動 Widget Browser, 或者從 Actions > Metrics 單擊 Widget Browser

   ② Widget Browser 顯示可以添加到服務表盤中的 widget, 包括已經包含在表盤中的，共享的 widget, 以及已創建的 widget.

   ③ 如果只要顯示自己創建的 widget,選擇 "Show only my widgets" 復選框

   ④ 如果要移除一個添加到表盤中的 widget, 單擊它的移除圖示

   ⑤ 如果要添加一個還沒有添加進來的可用 widget, 單擊 Add

   4.2.2.2 創建一個 Widget (Creating a Widget)

   ① 單擊 + 圖示啟動 Widget Browser

   ② 或者單擊 Create Widget 按鈕，或者在 Actions 選單上單擊 Create Widget

   ③ 選擇創建的 widget 型別

   ④ 取決于服務和 widget 型別，可以選擇度量和使用的運算子創建運算式來咋 widget 中顯式在構建運算式時會顯式 widget 的預覽，

   ⑤ 輸入 widget 的名稱和描述

   ⑥ 可選地，選擇共享此 widget

   共享 widget 使這個 widget 對集群中所有用戶可用，一個 widget 共享之后，其他 Ambari Admins 或 Cluster Operators 可以修改或洗掉這個widget, 這是不可恢復的，

   4.2.2.3 洗掉一個 Widget (Deleting a Widget)

   ① 單擊 + 圖示啟動 Widget Browser, 或者從 Actions > Metrics 單擊 Widget Browser

   ② Widget Browser 顯示可以添加到服務表盤中的 widget, 包括共享的和已創建的 widget

   ③ 如果一個 widget 已添加到表盤，它會顯式為 Added, 單擊它可以移除

   ④ 對于自己創建的 widget, 可以選擇 More... 選項洗掉

   ⑤ 對于共享的 widget, 如果是 Ambari Admin 或 Cluster Operator, 也會有選項洗掉

   洗掉一個共享的 widget 會從所有用戶洗掉，此程序不可逆

   4.2.2.4 匯出 Widget 圖形資料 (Export Widget Graph Data)

   可以利用 Export 能力從 widget 圖表中匯出度量資料

   ① 將滑鼠指標懸停在 widget 圖表上面，單擊圖表放大顯示，顯示 Export 圖示

   ② 單擊圖示并制定 CSV 或 JSON 格式  

   4.2.2.5 設定顯示時區 (Setting Display Timezone)

    可以設定時區用于顯示 widget 圖表中的度量資料    

   ① Ambari Web 中，單擊用戶名病選擇 Settings

   ② 在 Locale 節，選擇 Timezone.

   ③ 單擊 Save

   Ambari Web UI 重新載入并使用新設定的時區顯示圖表，

   4.3 添加服務 (Adding a Service)

   Ambari 安裝向導默認安裝所有可用的 Hadoop 服務，可以在初始安裝時僅選擇部署一部分服務，然后在需要時安裝其他服務，例如，有些有些用戶在初始

   安裝時只選擇安裝核心 Hadoop 服務， Actions 控制元件的 Add Service 選項可以在不中斷 Hadoop 集群操作情況下部署其他服務，當部署了所有可用當服務后，

   Add Service 控制元件顯示為無效，表明它不可用，

   添加服務，下面步驟展示了向 Hadoop 集群添加 Apache Falcon 服務的例子:

   (1) 單擊 Actions > Add Service

   打開 Add Service wizard

    

   (2) 單擊 Choose Services

   Choose Services 面板顯示，已激活的服務顯示為綠色背景并且其復選框被選中，

   (3) 在 Choose Services 面板上，選擇要添加服務前面的復選框，然后單擊 Next

   (4) 在 Assign Masters 頁面，確認默認的主機分配，

   Add Services Wizard 指示所選服務的 master 組件安裝的主機，另一方面，利用下拉選單選擇不同的主機，讓所選服務的 master 組件添加到該主機上，

   (5) 如果要添加的服務要求 slaves 和 clients, 在 Assign Slaves and Clients 頁，接受默認的 slave 和 client 組件分配的主機，單擊 Next，另一方面，選擇要安裝 slave 和 client 組件的主機，然后單擊 Next

   (6) 在 Customize Services, 接受默認的配置屬性

   另一方面，如有必要，編輯默認的配置屬性值，選擇 Override 為此服務創建一個配置組，然后，選擇 Next

   (7) 在 Review 頁，驗證配置設定符合期望，然后單擊 Deploy

   (8) 監控 安裝，啟動，以及測驗服務的程序，當成功結束時，單擊 Next

   (9) 當看到安裝結果的摘要顯示時，單擊 Complete

   (10) 查看并確認建議的配置修改

   (11) 重新啟動其他組件，因新增加了服務，其配置已過時，

   4.4 執行服務動作 (Performing Service Actions)

   通過執行服務動作來管理集群上一個選定的服務，在 Services tab, 單擊 Service Actions 然后單擊一個選項，可用的選項取決于選定的服務，例如，HDFS

   服務動作，單擊 Turn On Maintenance Mode 會阻止該服務生成的警報和狀態變化指示，但允許對該服務上啟動，停止，重啟，遷移，或執行維護任務，

   4.5 滾動重啟 (Rolling Restarts)

   當重啟多個服務、組件、或主機時，使用 rolling restarts 來分布任務，一個滾動重啟，使用一個批次序列停止并啟動多個運行中的 slave 組件，例如

   DataNodes, NodeManagers, RegionServers, or Supervisors .

   重要提示：

   DataNodes 的滾動重啟只能在集群維護期間執行，     

   可以設定滾動重啟的的引數值以控制服務的數量，間隔時間，容錯限度，以及在大型集群上重啟組件數量的限制，

   要運行一個滾動重啟，執行下列步驟：

   ① 在 Service 頁面左側的服務串列上，單擊一個服務名稱

   ② 在服務的 Summary 頁面，單擊一個鏈接，例如 DataNodes 或 RegionServers, 任何要重啟的組件Hosts 頁面列出集群上存在有所選組件的主機名稱

   ③ 利用 host-level 的 Actions 選單，單擊一個 slave 組件的名稱，然后單擊 Restart.

   ④ 為 Rolling Restart Parameters 查看并設定值

   ⑤ 可選地，重置標志來重啟僅修改了配置的組件

   ⑥ 單擊 Trigger Restart

   觸發重啟之后，應該監控后臺操作的程序，

   4.5.1 設定滾動重啟引數 (Setting Rolling Restart Parameters)

   選擇重啟從屬組件時，可以利用引數來控制如何重啟組件滾動，引數值默認為集群上組件總數的 10%, 例如，對于在有三個節點的集群中的組件, 一個滾動

   重啟的默認設定是一次重啟一個組件，重啟間隔是等待 2 分鐘，如果只有一個出現故障就繼續，并重啟運行此服務的所有組件，所有引數輸入整數，非零值

   Batch Size        ：包含在每次重啟批次里的組件數量

   Wait Time        ：每個批次組件排隊等候的資料(秒單位)

   Tolerate up to x failures    ：跨所有批次，在掛起重啟并不在排隊批次之前，重啟失敗容許的總數，

   4.5.2 終止滾動重啟 (Aborting a Rolling Restart)

   要終止批次中將來的滾動重啟，單擊 Abort Rolling Restart

   4.6 監控后臺操作 (Monitoring Background Operations)

   可以利用 Background Operations 視窗監控一個由多個操作組成的任務進度和完成情況，例如重啟組件，當運行這樣一個任務時，Background Operations

   視窗默認是打開的，例如監控一個滾動重啟的進度，單擊 Background Operations 視窗中的元素：

   ① 單擊每個操作的右箭頭顯示每一部主機上的重啟操作進度

   ② 重啟操作完成后，可以單擊右箭頭或主機名來查看日志檔案以及選定主機上生成的錯誤資訊

   ② 可選地，可以利用 Background Operations 視窗右上角的 Copy, Open, or Host Logs 圖示來復制，打開，或查看操作日志，

   也可以選擇 Background Operations 視窗底部的復選框來在將來執行任務時隱藏該視窗，

   4.7 移除一個服務 (Removing A Service)

   重要提示：

   移除一個服務是不可逆的并且所有的配置歷史將丟失

   步驟：

   ① 在 Services tab 頁面的左側面板，單擊服務名稱

   ② 單擊 Service Actions > Delete.

   ③ 提示時，移除任何依賴服務

   ④ 提示是，停止服務的所有組件

   ⑤ 確認移除

   服務停止后，必須確認移除

   4.8 操作審計 (Operations Audit) 

   當利用 Ambari 執行操作時，例如用戶登錄或退出，停止或啟動服務，添加或移除服務， Ambari 會在一個審計日志中創建一條內容，通過讀取審計日志，

   可以確定誰執行了操作，操作是什么時間發生的，以及其他操作特定的資訊，可以在 Ambari server 主機上找到 Ambari 審計日志：

   /var/log/ambari-server/ambari-audit.log  

   當修改了一個服務的配置資訊，Ambari 在審計日志中創建一條內容，并創建一個特殊的日志檔案：

   ambari-config-changes.log

   通過讀取配置修改日志，可以發現每次配置修改更多的資訊，例如：

   2016-05-25 18:31:26,242 INFO - Cluster 'MyCluster' changed by: 'admin';

   service_name='HDFS' config_group='default' config_group_id='-1' version='2' 

   4.9 使用快速鏈接 (Using Quick Links)

   選擇 Quick Links 選項可以訪問選定服務的一些額外的資訊源，例如 HDFS 的 Quick Links 選項包括如下內容：

   NameNode JMX

   NameNode Logs

   Thread Stacks

   NameNode UI

   Quick Links 不是對每個服務都可用    

   4.10 重繪 YARN 容量調度器 (Refreshing YARN Capacity Scheduler)

   修改 Capacity Scheduler 配置之后，如果沒有進行破壞性修改配置資訊，YARN 可以不需要重啟 ResourceManager 重繪佇列，如果執行了破壞性修改，例如

   洗掉一個佇列，重繪操作會失敗并輸出如下資訊：Failed to re-init queues . 當進行破壞性修改時，必須執行 ResourceManager 重啟來使容量調度器的

   修改生效，

   重繪 Capacity Scheduler, 執行如下步驟：

   ① 在 Ambari Web, 瀏覽到 Services > YARN > Summary.

   ② 單擊 Service Actions, 然后單擊 Refresh YARN Capacity Scheduler

   ③ 確認要執行此操作

   重繪操作提交給 YARN ResourceManager    

   4.11 管理 HDFS (Managing HDFS)

   4.11.1 重均衡 HDFS (Rebalancing HDFS)

   HDFS 提供了一個 a "balancer" 工具幫助均衡集群中資料塊跨 DataNodes 分布，啟動均衡行程，執行下列步驟：

   ① 在 Ambari Web 中，瀏覽到 Services > HDFS > Summary

   ② 單擊 Service Actions, 然后單擊 Rebalance HDFS.

   ③ 輸入 Balance Threshold 值作為磁盤容量到百分比

   ④ 單擊 Start

   可以通過打開 Background Operations 視窗監控或取消重均衡行程，

   4.11.2 調整垃圾回收 (Tuning Garbage Collection)

   Concurrent Mark Sweep (CMS) garbage collection (GC) 行程包括一系列啟發式規則用于觸發垃圾回收，這使得垃圾回收是不可預測的并趨向于延遲回收，直到抵達容量水平，產生一個 Full GC 錯誤(有可能中斷所有行程)

   Ambari 在集群部署期間設定了很多屬性的默認值，在 hadoop-env 模板中到 export HADOOP_NameNode_Opts= 子句，有兩個引數影響 CMS GC 行程，有如下的默認設定：

   ● -XX:+UseCMSInitiatingOccupancyOnly

   阻止 使用 GC 啟發    

   ● -XX:CMSInitiatingOccupancyFraction=<percent>

   告知 Java VM 何時 CMS 收集器被觸發

   如果這個值設定得過低，CMS 收集器運行過于頻繁；如果設定過高，CMS 收集器觸發得太晚，并且可能發生 concurrent mode failure. 默認設定

   -XX:CMSInitiatingOccupancyFraction 的值為 70, 意味著應用程式應該利用少于 70% 的容量，

   通過修改 NameNode CMS GC 引數來調整垃圾回收，執行如下步驟：

   ① 在 Ambari Web, 瀏覽到 Services > HDFS.

   ② 打開 Configs tab, 并瀏覽到 Advanced > Advanced hadoop-env

   ③ 編輯 hadoop-env 模板

   ④ 保存配置并有提示出現，重啟

   4.11.3 自定義 HDFS 主目錄 (Customizing the HDFS Home Directory)

   默認情況下，HDFS 的用戶主目錄為 /user/<user_name>. 可以利用 dfs.user.home.base.dir 屬性自定義 HDFS 主目錄

   ① 在 Ambari Web, 瀏覽到 Services > HDFS > Configs > Advanced.

   ② 單擊 Custom hdfs-site, 然后單擊 Add Property

   ③ 在彈出到 Add Property 中，添加如下屬性：

   dfs.user.home.base.dir=<home_directory>

   ④ 單擊 Add, 然后在提示是，保存新配置病重啟

   4.12 在 Storm 環境內管理 Atlas (Managing Atlas in a Storm Environment)

   在 Ambari 中更新 Apache Atlas 配置設定時，Ambari 標記此服務要求重啟，要重啟這些服務，執行如下步驟：

   ① 在 Ambari Web, 單擊 Actions 控制元件

   ② 單擊 Restart All Required

   提示：

   Apache Oozie 在一個 Atlas 配置更新后要求重啟，但在 Ambari 中可能沒有標記為要求重啟，如果 Oozie 沒有包含進來，執行如下步驟重啟 Oozie:

   ① 在 Ambari Web, 在服務摘要面板單擊 Oozie

   ② 單擊 Service Actions > Restart All.

   4.13 啟用 Oozie UI (Enabling the Oozie UI)

   Ext JS 是 GPL 許可證的軟體，并且不再包含在 HDP 2.6 中，因此 Oozie WAR 檔案沒有構建到 Ext JS-based 用戶介面程式中，除非 Ext JS 手動安裝到Oozie server. 如果使用 Ambari 2.6.1.3 添加 Oozie 到 HDP2.6.4 或更高版本，默認沒有 Oozie UI 可用，如果想要 Oozie UI，必須手動安裝 Ext JS到 Oozie server 主機，在重啟操作期間，Ambari 重構這個 Oozie WAR 檔案并包含 Ext JS-based Oozie UI

   步驟：

   ① 登錄到 Oozie Server 主機

   ② 下載并安裝 Ext JS 包

   CentOS RHEL Oracle Linux 7:

   wget http://public-repo-1.hortonworks.com/HDP-UTILS-GPL-1.1.0.22/repos/centos7/extjs/extjs-2.2-1.noarch.rpm

   rpm -ivh extjs-2.2-1.noarch.rpm

   ③ 移除如下檔案：

   rm /usr/hdp/current/oozie-server/.prepare_war_cmd

   ④ 在 Ambari UI 上重啟 Oozie Server

   Ambari 會重構 Oozie WAR 檔案

   5. 管理服務高可用性 (Managing Service High Availability)

   Ambari web 提供了向導驅動的用戶體驗，可以配置一些 Hortonworks Data Platform (HDP) stack 服務組件的高可用性，高可用性通過建立主(primary)

   和從(secondary) 組件來提供保險，在主組件故障或變為不可用情況下，從組件成為可用，為一個服務配置了高可用性之后，Ambari 可以管理或禁用((roll

   back) 該服務內組件的高可用性，

   5.1 NameNode 的高可用性 (NameNode High Availability)

   為了確保集群上在主 NameNode 主機故障時，另一個 NameNode 總是可用，可用利用 Ambari Web 在集群上啟用并配置 NameNode 高可用性，

   5.1.1 配置 NameNode 的高可用性 (Configuring NameNode High Availability)

   前提要求：

    ● 核實集群中至少有三部主機，并且至少運行三個 Apache ZooKeeper servers

   ● 確保 Hadoop Distributed File System (HDFS) 和 ZooKeeper 沒有運行在維護模式

   在啟用 NameNode HA 時，HDFS 和 ZooKeeper 必須停止然后啟動，維護模式會阻止這類啟動和停止操作，如果 HDFS 或 ZooKeeper 處于維護模式，

   NameNode HA 向導不會完全成功，

   步驟：      

    (1) 在 Ambari Web, 選擇 Services > HDFS > Summary.

    (2) 單擊 Service Actions, 然后單擊 Enable NameNode HA

   (3) Enable HA wizard 啟動，這個向導描述了一系列必須執行的自動和手動的步驟來建立 NameNode 高可用性

   (4) 在 Get Started 頁面，輸入 Nameservice ID, 然后單擊 Next

   在設定了 HA 之后，使用這個 Nameservice ID 而不是 NameNode FDQN

    (5) 在 Select Hosts 頁面，選擇一部主機最為附加 NameNode 以及 JournalNodes,然后單擊 Next

   (6) 在 Review 頁，確認主機的選擇，然后單擊 Next

    (7) 跟隨 Manual Steps Required: Create Checkpoint on NameNode 頁面上的指導，單擊 Next

   必須登錄到當前 NameNode 主機并運行命令，將 NameNode 置于安全模式并創建檢查點

    (8) 當 Ambari 檢測成功，并且視窗底部的訊息變為 Checkpoint created, 單擊 Next

    (9) 在 Configure Components 頁面，監控配置進度條，然后單擊 Next

   (10)在 Manual Steps Required: Initialize JournalNodes 頁面跟隨指導，然后單擊 Next

   必須登錄到當前 NameNode 主機運行命令來初始化 JournalNodes.

   (11)當 Ambari 檢測成功，并視窗底部的訊息變為 JournalNodes initialized 時，單擊 Next

   (12)在 Start Components 頁面，監控 ZooKeeper servers 和 NameNode 啟動進度條，然后單擊 Next在啟用 Ranger 的集群上，并且 Hive 配置為使用 MySQL, 如果 MySQL 停止，Ranger 會啟動失敗，要解決這個問題，啟動 Hive 的 MySQL 資料庫，然后重試啟動組件

   (13)在 Manual Steps Required: Initialize NameNode HA Metadata 頁面，根據頁面上的指導，完成每一步驟，然后單擊 Next，在這一步，必須登錄到當前 NameNode 和附加 NameNode 主機，確保每個命令登錄到正確的主機，在完成每一個命令后，單擊 OK 確認，

   (14)在 Finalize HA Setup 頁，監控向導完成 HA 設定的進度條，單擊 Done 結束向導，在 Ambari Web UI 重新載入之后，可能會看到一些警報通知，等幾分鐘直到所有服務重啟

   (15)如果必要，使用 Ambari Web 重啟任何組件

   (16)如果使用 Hive, 必須手動修改 Hive Metastore FS root 指向 Nameservice URI 而不是 NameNode URI. 在 Get Started 步驟創建的 Nameservice ID

   步驟：

   a. 在 Hive 主機上找到 FS root：

   hive --config /etc/hive/conf/conf.server --service metatool -listFSRoot

   輸出類似于：

   Listing FS Roots... hdfs://<namenodehost>/apps/hive/warehouse.

    b. 修改 FS root：

   $ hive --config /etc/hive/conf/conf.server --service metatool -updateLocation <new-location><old-location>

   例如，如果 Nameservice ID 為 mycluster, 輸入為：

   $ hive --config /etc/hive/conf/conf.server --service metatool -updateLocation hdfs://mycluster/apps/hive/warehouse    \

   hdfs://c6401.ambari.apache.org/apps/hive/warehouse

   輸出類似于：

   Successfully updated the following locations...Updated X records in SDS table

   (17)調整 ZooKeeper Failover Controller retries 設定環境

   a. 瀏覽到 Services > HDFS > Configs > Advanced core-site

   b. 設定 ha.failover-controller.active-standbyelector.zk.op.retries=120.

   下面步驟：

   查看并確認所有建議的配置修改

   5.1.2 回滾 NameNode 的高可用性 (CRolling Back NameNode HA)

   要禁用(roll back) NameNode 高可用性，執行如下步驟(取決于安裝)

    (1)    停止 HBase

   (2)    檢查點活動 NameNode

   (3)    停止所有服務

   (4)    為回滾準備 Ambari Server Host

   (5)    恢復 HBase 配置

   (6)    洗掉 ZooKeeper Failover 控制器

   (7)    修改 HDFS 配置

   (8)    重新創建 Secondary NameNode

   (9)    重新啟用 Secondary NameNode

   (10)洗掉所有 JournalNodes

   (11)洗掉附屬 NameNode

   (12)驗證 HDFS 組件

   (13)啟動 HDFS

   5.1.2.1 停止 HBase (Stop HBase)

   ① 在 Ambari Web 集群表盤，單擊 HBase 服務

   ② 單擊 Service Actions > Stop

   ③ 等待，直到 HBase 完全停止，然后繼續

   5.1.2.2 檢查點活動 NameNode (Checkpoint the Active NameNode)

   如果在啟用 NameNode HA 之后使用了 HDFS, 但想要回轉到非 HA 狀態，進行回滾之前必須要設定 HDFS 狀態檢查點，

   如果在 Enable NameNode HA wizard 操作程序中失敗并需要回轉，可以忽略此步驟，繼續進行停止所有服務，

   設定 HDFS 狀態檢查點要求不同的語法，取決于集群上是否啟用了 Kerberos 安全

       ● 如果集群上沒有啟用 Kerberos 安全，在活動 NameNode 主機上使用如下命令來保存名稱空間

       sudo su -l <HDFS_USER> -c 'hdfs dfsadmin -safemode enter' sudo su -l <HDFS_USER> -c 'hdfs dfsadmin -saveNamespace'

       ● 如果集群上已經啟用了 Kerberos 安全，使用如下命令來保存名稱空間：

       sudo su -l <HDFS_USER> -c 'kinit -kt /etc/security/keytabs/nn.service.keytab nn/<HOSTNAME>@<REALM>;hdfs dfsadmin -safemode    \

       enter' sudo su -l <HDFS_USER> -c 'kinit -kt /etc/security/keytabs/nn.service.keytab nn/<HOSTNAME>@<REALM>;hdfs dfsadmin -saveNamespace'

    

    

       本例中 <HDFS_USER> 是 HDFS 服務的用戶(如 hdfs), <HOSTNAME> 是 Active NameNode 主機名，<REALM> 是 Kerberos realm.

   5.1.2.3 停止所有服務 (Stop All Services)

   在停止 HBase, 并且如有必要設定了 Activ NameNode 檢查點之后，停止所有服務

       ① 在 Ambari Web, 單擊 Services tab

       ② 單擊 Stop All

       ③ 等待所有服務停止完成之后，繼續

   5.1.2.4 為回滾準備 Ambari Server 主機 (Prepare the Ambari Server Host for Rollback)

   為回滾程序準備：

       ① 登錄到 Ambari server 主機

       ② 設定如下環境變數

           export AMBARI_USER=AMBARI_USERNAME    ：替換為 Ambari Web 系統管理員，默認值為 admin

           export AMBARI_PW=AMBARI_PASSWORD    ：替換為Ambari Web 系統管理員的口令， 默認值為 admin

           export AMBARI_PORT=AMBARI_PORT        ：替換為 Ambari Web 埠，默認為 8080.

           export AMBARI_PROTO=AMBARI_PROTOCOL    ：替換為連接到 Ambari Web 使用的協議，選項為 http 或 https, 默認為 http

           export CLUSTER_NAME=CLUSTER_NAME    ：替換為集群名稱，如 mycluster

           export NAMENODE_HOSTNAME=NN_HOSTNAME    ：替換為 非 HA 的 NameNode 主機 FDQN, 例如 namenode.mycompany.com

           export ADDITIONAL_NAMENODE_HOSTNAME=ANN_HOSTNAME    ：替換為設定 HA 時使用的附屬 NameNode 主機的 FDQN

           export SECONDARY_NAMENODE_HOSTNAME=SNN_HOSTNAME        ：替換為非 HA 設定的 secondary NameNode 主機的 FDQN

           export JOURNALNODE1_HOSTNAME=JOUR1_HOSTNAME    ：替換為第一 Journal 節點主機的 FDQN

           export JOURNALNODE2_HOSTNAME=JOUR2_HOSTNAME    ：替換為第二 Journal 節點主機的 FDQN

           export JOURNALNODE3_HOSTNAME=JOUR3_HOSTNAME ：替換為第三 Journal 節點主機的 FDQN

       ③ 多檢查幾遍這些環境變數設定正確

   5.1.2.5 恢復 HBase 配置 Host (Restore the HBase Configuration)

   如果安裝了 HBase, 可能需要恢復到 HA 狀態之前的配置，

       Note：

           對于 Ambari 2.6.0 及更高版本，不再支持 config.sh 并且會失敗，使用 config.py

       ①     從 Ambari server 主機上，確定當前的 HBase 配置是否必須恢復：     

           /var/lib/ambari-server/resources/scripts/configs.py -u <AMBARI_USER> -p <AMBARI_PW> -port <AMBARI_PORT> get localhost     \

           <CLUSTER_NAME>    hbase-site       

           使用為回滾準備 Ambari Server 主機設定的環境變數應用命令中的環境變數名，    

           如果 hbase.rootdir 設定為 Enable NameNode HA 向導中設定的 NameService ID, 必須回轉 hbase-site 到非 HA 的值，例如，在

           "hbase.rootdir":"hdfs://<name-service-id>:8020/apps/hbase/data" 中，hbase.rootdir 屬性指向 NameService ID, 因此這個值必須回滾，

           如果 hbase.rootdir 指向一個特定的 NameNode 主機，它就沒必要回滾，"hbase.rootdir":"hdfs://<nn01.mycompany.com>:8020/apps/hbase/data",

           hbase.rootdir 指向了一個特定的 NameNode 主機而不是 NameService ID, 這就不需要回滾，可以繼續進行 ZooKeeper failover 控制器洗掉

       ②  如果必須要回滾 hbase.rootdir 值，在 Ambari server 主機上，使用 configs.py 腳本進行必要的修改：

           /var/lib/ambari-server/resources/scripts/configs.py -u <AMBARI_USER> -p<AMBARI_PW> -port <AMBARI_PORT> set

           localhost <CLUSTER_NAME> hbase-site hbase.rootdir hdfs://<NAMENODE_HOSTNAME>:8020/apps/hbase/data

           使用為回滾準備 Ambari Server 主機設定的環境變數應用命令中的環境變數名   

       ③    在 Ambari server 主機上，驗證 hbase.rootdir 屬性已恢復正確：

           /var/lib/ambari-server/resources/scripts/configs.py -u <AMBARI_USER> -p <AMBARI_PW> -port <AMBARI_PORT> get localhost \

           <CLUSTER_NAME> hbase-site

           hbase.rootdir 屬性現在應該與 NameNode 主機名相同而不是 NameService ID.

   5.1.2.6 洗掉 ZooKeeper Failover 控制器 (Delete ZooKeeper Failover Controllers)

   前提準備：

       如果在 Ambari 服務器主機上執行如下命令回傳一個非空的 items 陣列，那么必須洗掉 ZooKeeper (ZK) Failover Controllers：

       curl -u <AMBARI_USER>:<AMBARI_PW> -H "X-Requested-By: ambari" -i <AMBARI_PROTO>://localhost:<AMBARI_PORT>/api/v1/clusters/        \

       <CLUSTER_NAME>/host_components?HostRoles/component_name=ZKFC

   洗掉失效控制器：

       ①    在 Ambari server 主機上，發出如下 DELETE 命令：

       curl -u <AMBARI_USER>:<AMBARI_PW> -H "X-Requested-By: ambari" -i -X DELETE <AMBARI_PROTO>://localhost:<AMBARI_PORT>/api/v1/        \

       clusters/<CLUSTER_NAME>/hosts/<NAMENODE_HOSTNAME>/host_components/ZKFC curl -u <AMBARI_USER>:<AMBARI_PW> -H "X-Requested-By:     \

       ambari" -i -X DELETE <AMBARI_PROTO>://localhost:<AMBARI_PORT>/api/v1/clusters/<CLUSTER_NAME>/hosts/<ADDITIONAL_NAMENODE_HOSTNAME>/    \

       host_components/ZKFC

       ② 驗證控制器已被移除

       curl -u <AMBARI_USER>:<AMBARI_PW> -H "X-Requested-By: ambari"-i <AMBARI_PROTO>://localhost:<AMBARI_PORT>/api/v1/clusters/    \

       <CLUSTER_NAME>/host_components?HostRoles/component_name=ZKFC

       這條命令應該回傳一個空的 items 陣列

   5.1.2.7 修改 HDFS 配置 (Modify HDFS Configurations)

   可能需要修改 hdfs-site 配置和/或 core-site 配置

   前提準備：

       通過在  Ambari server 主機上執行下列命令，檢查是否需要修改 hdfs-site 配置：

    

       /var/lib/ambari-server/resources/scripts/configs.py -u <AMBARI_USER> -p <AMBARI_PW> -port <AMBARI_PORT> get localhost     \

       <CLUSTER_NAME> hdfs-site

   如果看到如下屬性，必須從配置中洗掉它們

       ? dfs.nameservices

       ? dfs.client.failover.proxy.provider.<NAMESERVICE_ID>

       ? dfs.ha.namenodes.<NAMESERVICE_ID>

       ? dfs.ha.fencing.methods

       ? dfs.ha.automatic-failover.enabled

       ? dfs.namenode.http-address.<NAMESERVICE_ID>.nn1

       ? dfs.namenode.http-address.<NAMESERVICE_ID>.nn2

       ? dfs.namenode.rpc-address.<NAMESERVICE_ID>.nn1

       ? dfs.namenode.rpc-address.<NAMESERVICE_ID>.nn2

       ? dfs.namenode.shared.edits.dir

       ? dfs.journalnode.edits.dir

       ? dfs.journalnode.http-address

       ? dfs.journalnode.kerberos.internal.spnego.principal

       ? dfs.journalnode.kerberos.principal

       ? dfs.journalnode.keytab.file

   這里的 <NAMESERVICE_ID> 是在運行 Enable NameNode HA 向導時創建的 NameService ID

   修改 hdfs-site 配置：

       ①    在 Ambari Server 主機上，對每一個發現的屬性執行如下命令：

           /var/lib/ambari-server/resources/scripts/configs.py -u <AMBARI_USER> -p <AMBARI_PW> -port <AMBARI_PORT> delete

           localhost <CLUSTER_NAME> hdfs-site property_name

           使用每一個要洗掉的屬性替換 property_name

       ②    驗證所以屬性都已洗掉：

           /var/lib/ambari-server/resources/scripts/configs.py -u <AMBARI_USER> -p <AMBARI_PW> -port <AMBARI_PORT> get localhost

           <CLUSTER_NAME> hdfs-site

       ③    確定是否必須修改 core-site 配置

           /var/lib/ambari-server/resources/scripts/configs.py -u <AMBARI_USER> -p <AMBARI_PW> -port <AMBARI_PORT> get localhost

           <CLUSTER_NAME> core-site

       ④    如果看到 ha.zookeeper.quorum 屬性，洗掉它

           /var/lib/ambari-server/resources/scripts/configs.py -u <AMBARI_USER> -p <AMBARI_PW> -port <AMBARI_PORT> delete

           localhost <CLUSTER_NAME> core-site ha.zookeeper.quorum

       ⑤    如果 fs.defaultFS 設定為 NameService ID, 將它回轉到 非-HA 值

           "fs.defaultFS":"hdfs://<name-service-id>" The property

           fs.defaultFS needs to be modified as it points to a NameService

           ID "fs.defaultFS":"hdfs://<nn01.mycompany.com>"

       ⑥    將 fs.defaultFS 屬性回轉到 NameNode 主機值

         

           /var/lib/ambari-server/resources/scripts/configs.py -u

           <AMBARI_USER> -p <AMBARI_PW> -port <AMBARI_PORT> set localhost

           <CLUSTER_NAME> core-site fs.defaultFS hdfs://<NAMENODE_HOSTNAME>

       ⑦    驗證 core-site 屬性現在正確設定了

           /var/lib/ambari-server/resources/scripts/configs.py -u

           <AMBARI_USER> -p <AMBARI_PW> -port <AMBARI_PORT> get localhost

           <CLUSTER_NAME> core-site

       fs.defaultFS 屬性值應該是 NameNode 主機，并且 ha.zookeeper.quorum 屬性不會出現

   5.1.2.8 重新創建 Secondary NameNode (Re-create the Secondary NameNode)

   需要重新創建 Secondary NameNode

   前提準備：

       在 Ambari Server 主機上檢查是否需要重新創建 Secondary NameNode

       curl -u <AMBARI_USER>:<AMBARI_PW> -H "X-Requested-By:

       ambari" -i -X GET <AMBARI_PROTO>://localhost:<AMBARI_PORT>/

       api/v1/clusters/<CLUSTER_NAME>/host_components?HostRoles/

       component_name=SECONDARY_NAMENODE

       如果回傳一個空的 items 陣列，必須重新創建 Secondary NameNode

   重新創建 Secondary NameNode

       ①    在 Ambari Server 主機上，運行如下命令：

       curl -u <AMBARI_USER>:<AMBARI_PW> -H "X-Requested-By:

       ambari" -i -X POST -d '{"host_components" : [{"HostRoles":

       {"component_name":"SECONDARY_NAMENODE"}}] }' <AMBARI_PROTO>://

       localhost:<AMBARI_PORT>/api/v1/clusters/<CLUSTER_NAME>/hosts?

       Hosts/host_name=<SECONDARY_NAMENODE_HOSTNAME>

       ②    驗證 Secondary NameNode 是否存在，在 Ambari server 主機上，運行如下命令：

       curl -u <AMBARI_USER>:<AMBARI_PW> -H "X-Requested-By:

       ambari" -i -X GET <AMBARI_PROTO>://localhost:<AMBARI_PORT>/

       api/v1/clusters/<CLUSTER_NAME>/host_components?HostRoles/

       component_name=SECONDARY_NAMENODE

       命令應回傳一個非空陣列包含 secondary NameNode

   5.1.2.9 重新啟用 Secondary NameNode (Re-enable the Secondary NameNode)

       ①    在 Ambari Server 主機上運行如下命令：

           curl -u <AMBARI_USER>:<AMBARI_PW> -H "X-Requested-

           By: ambari" -i -X PUT -d '{"RequestInfo":

           {"context":"Enable Secondary NameNode"},"Body":

           {"HostRoles":{"state":"INSTALLED"}}}'<AMBARI_PROTO>://

           localhost:<AMBARI_PORT>/api/v1/clusters/<CLUSTER_NAME>/hosts/

           <SECONDARY_NAMENODE_HOSTNAME}/host_components/SECONDARY_NAMENODE

       ②    分析輸出

           ? 如果回傳 200, 繼續進行洗掉所有 JournalNodes

           ? 如果回傳 202, 等待幾分鐘之后，然后運行下面命令：

           curl -u <AMBARI_USER>:<AMBARI_PW> -H "X-Requested-By:

           ambari" -i -X GET "<AMBARI_PROTO>://localhost:<AMBARI_PORT>/

           api/v1/clusters/<CLUSTER_NAME>/host_components?HostRoles/

           component_name=SECONDARY_NAMENODE&fields=HostRoles/state"

           等待回應 "state" : "INSTALLED" 然后繼續

   5.1.2.10 洗掉所有 JournalNodes (Delete All JournalNodes)

   可能需要洗掉若干個 JournalNodes

   前提要求：

       在 Ambari Server 主機上檢查看看是否需要洗掉 JournalNodes

       curl -u <AMBARI_USER>:<AMBARI_PW> -H "X-Requested-By:

       ambari" -i -X GET <AMBARI_PROTO>://localhost:<AMBARI_PORT>/

       api/v1/clusters/<CLUSTER_NAME>/host_components?HostRoles/

       component_name=JOURNALNODE

       如果回傳一個空的 items 陣列，可以繼續，否則必須洗掉 JournalNodes

   洗掉 JournalNodes：

       ①    在 Ambari Server 主機上，運行如下命令：

           curl -u <AMBARI_USER>:<AMBARI_PW> -H "X-Requested-By: ambari"

           -i -X DELETE <AMBARI_PROTO>://localhost:<AMBARI_PORT>/api/

           v1/clusters/<CLUSTER_NAME>/hosts/<JOURNALNODE1_HOSTNAME>/

           host_components/JOURNALNODE curl -u <AMBARI_USER>:<AMBARI_PW>

           -H "X-Requested-By: ambari" -i -X DELETE <AMBARI_PROTO>://

           localhost:<AMBARI_PORT>/api/v1/clusters/<CLUSTER_NAME>/hosts/

           <JOURNALNODE2_HOSTNAME>/host_components/JOURNALNODE

           curl -u <AMBARI_USER>:<AMBARI_PW> -H "X-Requested-By: ambari"

           -i -X DELETE <AMBARI_PROTO>://localhost:<AMBARI_PORT>/api/

           v1/clusters/<CLUSTER_NAME>/hosts/<JOURNALNODE3_HOSTNAME>/

           host_components/JOURNALNODE

       ②    驗證所有的 JournalNodes 已被洗掉，在 Ambari server 主機上執行：

           curl -u <AMBARI_USER>:<AMBARI_PW> -H "X-Requested-By:

           ambari" -i -X GET <AMBARI_PROTO>://localhost:<AMBARI_PORT>/

           api/v1/clusters/<CLUSTER_NAME>/host_components?HostRoles/

           component_name=JOURNALNODE

           這條命令應回傳空的 items 陣列

   5.1.2.11 洗掉附屬 NameNode (Delete the Additional NameNode)

   可能需要洗掉附屬 NameNode

   前提要求：

       在 Ambari server 主機上，檢查是否需要洗掉附屬 NameNode

       curl -u <AMBARI_USER>:<AMBARI_PW> -H "X-Requested-By: ambari" -i

       -X GET <AMBARI_PROTO>://localhost:<AMBARI_PORT>/api/v1/clusters/

       <CLUSTER_NAME>/host_components?HostRoles/component_name=NAMENODE

       如果回傳的 items 陣列含有兩個 NameNode, 必須洗掉附屬 NameNode

   洗掉為 HA 設定的附屬 NameNode:

       ①    在 Ambari Server 主機上，運行如下命令：

           curl -u <AMBARI_USER>:<AMBARI_PW> -H "X-Requested-By: ambari"

           -i -X DELETE <AMBARI_PROTO>://localhost:<AMBARI_PORT>/api/v1/

           clusters/<CLUSTER_NAME>/hosts/<ADDITIONAL_NAMENODE_HOSTNAME>/

           host_components/NAMENODE

       ②    驗證附屬 NameNode 已洗掉

           curl -u <AMBARI_USER>:<AMBARI_PW> -H "X-Requested-By: ambari" -i

           -X GET <AMBARI_PROTO>://localhost:<AMBARI_PORT>/api/v1/clusters/

           <CLUSTER_NAME>/host_components?HostRoles/component_name=NAMENODE

           回傳的 items 陣列應含有一個 NameNode

   5.1.2.12 驗證 HDFS 組件 (Verify the HDFS Components)

   啟動 HDFS 之前，應驗證具有正確的組件

       ①    瀏覽到 Ambari Web UI > Services, 然后選擇 HDFS

       ②    檢查 Summary 面板病確保前三行類似如下： 

           ? NameNode

           ? SNameNode

           ? DataNodes    

           不應看到 JournalNodes 到行

   5.1.2.13 啟動 HDFS (Start HDFS)

       ①    在 Ambari Web UI, 單擊 Service Actions, 然后單擊 Start.

       ②    如果進度條沒有顯示服務已完全啟動并且忽略了服務檢查，重做第一步

       ③    啟動所有其他服務，在 Services 頁面單擊 Actions > Start All

   5.1.3 管理 Journal 節點 (Managing Journal Nodes)

   在集群上啟用 NameNode 高可用性之后，必須在集群上維護至少三個活動的 Journal 節點，可以使用 Manage JournalNode 向導來分配、添加、或移除

   JournalNode. Manage JournalNode 向導分配 JournalNodes, 查看并確認必要的配置修改，然后會重啟集群上的所有組件，以利用 JournalNode 和配置的

   變化，

   注意，這個向導會重啟所有的集群服務，

   前提要求：

       集群上必須啟用了 NameNode 高可用性

   管理集群的 JournalNodes

       (1) 在 Ambari Web, 選擇 Services > HDFS > Summary.

       (2) 單擊 Service Actions, 然后單擊 Manage JournalNodes

       (3)    在 Assign JournalNodes 頁面，通過 + 和 - 圖示分配，并從下拉式選單選擇主機名稱，完成主機分配之后，單擊 Next

       (4) 在 Review 頁面，驗證 JournalNodes 主機分配及其相關配置修改，滿意之后，單擊 Next

       (5) 利用遠程 shell, 完成 Save Namespace 頁面的步驟，成功創建一個檢查點后，單擊 Next

       (6) 在 Add/Remove JournalNodes 頁面，監控進度條，然后單擊 Next

       (7) 跟隨 Manual Steps Required: Format JournalNodes 頁面指導，然后單擊 Next

       (8) 在遠程 shell 中，確認要初始化 JournalNodes, 在如下提示下輸入 Y

           Re-format filesystem in QJM to [host.ip.address.1, host.ip.address.2, host.ip.address.3,] ? (Y or N) Y

       (9) 在 Start Active NameNodes 頁面，服務重啟時監控進度條，然后單擊 Next

       (10)在 Manual Steps Required: Bootstrap Standby NameNode 頁面，利用頁面上的指導完成每一步驟，然后單擊 Next

       (11)在遠程 shell 中，確認要 bootstrap 備用 NameNode, 在下列提示中輸入 Y

         

           RE-format filesystem in Storage Directory /grid/0/hadoop/hdfs/namenode ? (Y or N) Y

       (12)在 Start All Services 頁面，向導啟動所有服務時監控進度條，然后單擊 Done 結束向導，

           Ambari Web UI 重新載入后，會看到一些警報通知，等幾分鐘直到所有服務重新啟動并且警報清除  

       (13)如有必要，利用 Ambari Web UI 重啟任何組件

   5.2 ResourceManager 高可用性 (ResourceManager High Availability)

   如果作業于 HDP 2.2 或更高版本環境，可以通過 Enable ResourceManager HA 為 ResourceManager 配置高可用性，

   前提要求：

       ● 集群必須至少有三部主機

       ● 至少有三個 ZooKeeper server 運行

   5.2.1 配置 ResourceManager 高可用性 (Configure ResourceManager High Availability)

   訪問向導并配置 ResourceManager 高可用性

       ①    在 Ambari Web, 瀏覽到 Services > YARN > Summary

       ②    選擇 Service Actions 然后選擇 Enable ResourceManager HA.

           Enable ResourceManager HA 向導啟動，描述一系列必須設定 ResourceManager 高可用性的自動和手動步驟

       ③    在 Get Started 頁面，閱讀啟用 ResourceManager HA 概述，然后單擊 Next 繼續

       ④    在 Select Host 頁面，接受默認選擇，或選擇一可用主機，然后單擊 Next 繼續

       ⑤    在 Review Selections 頁面，如有必要展開 YARN, 概覽所有對 YARN 推薦的配置變化，單擊 Next 同意修改并自動配置 ResourceManager HA

       ⑥    在 Configure Components 頁面，當所有進度條結束時，單擊 Complete

   5.2.2 禁用 ResourceManager 高可用性 (Disable ResourceManager High Availability)

   要禁用 ResourceManager 高可用性，必須洗掉一個 ResourceManager 并保留一個 ResourceManager. 在要求利用 Ambari API 來修改集群配置來洗掉

   ResourceManage 并利用 ZooKeeper 客戶端更新 znode 權限，

   前提準備：

       由于這些步驟包括使用 Ambari REST API, 應該提前在一個測驗環境中測驗并驗證它們，再到生產環境執行，

   禁用 ResourceManager 高可用性

       (1)    在 Ambari Web, 停止 YARN 和 ZooKeeper 服務

       (2)    在 Ambari Server 主機上，利用 Ambari API 獲取 YARN 配置資訊到一個 JSON 檔案

           /var/lib/ambari-server/resources/scripts/configs.py get <ambari.server> <cluster.name> yarn-site yarn-site.json

           本例中，ambari.server 是 Ambari Server 主機名，cluster.name 是集群的名稱

       (3)    在 yarn-site.json 檔案中，修改 change yarn.resourcemanager.ha.enabled 為 false, 并洗掉如下屬性：

           ? yarn.resourcemanager.ha.rm-ids

           ? yarn.resourcemanager.hostname.rm1

           ? yarn.resourcemanager.hostname.rm2

           ? yarn.resourcemanager.webapp.address.rm1

           ? yarn.resourcemanager.webapp.address.rm2

           ? yarn.resourcemanager.webapp.https.address.rm1

           ? yarn.resourcemanager.webapp.https.address.rm2

           ? yarn.resourcemanager.cluster-id

           ? yarn.resourcemanager.ha.automatic-failover.zk-base-path

       (4)    驗證 yarn-site.json 檔案中保留下列屬性設定為 ResourceManager 主機名

           ? yarn.resourcemanager.hostname

           ? yarn.resourcemanager.admin.address

           ? yarn.resourcemanager.webapp.address

           ? yarn.resourcemanager.resource-tracker.address

           ? yarn.resourcemanager.scheduler.address

           ? yarn.resourcemanager.webapp.https.address

           ? yarn.timeline-service.webapp.address

           ? yarn.timeline-service.webapp.https.address

           ? yarn.timeline-service.address

           ? yarn.log.server.url

       (5)    搜索 yarn-site.json 檔案，并洗掉任何對要洗掉的 ResourceManage 主機名的參考

       (6) 搜索 yarn-site.json 檔案，并洗掉任何仍設定為 ResourceManager IDs 的屬性，例如 rm1 and rm2

       (7) 保存 yarn-site.json 檔案，并設定到 Ambari server

           /var/lib/ambari-server/resources/scripts/configs.py set ambari.server cluster.name yarn-site yarn-site.json

       (8)    利用 Ambari API, 洗掉要洗掉的 ResourceManager 主機組件

           curl --user admin:admin -i -H "X-Requested-By: ambari" -X DELETE http://ambari.server:8080/api/v1/clusters/cluster.name/hosts/    \

           hostname/host_components/RESOURCEMANAGER

       (9)    在 Ambari Web 中，啟動 ZooKeeper 服務

       (10)在一個安裝了 ZooKeeper client 的主機上，使用 ZooKeeper client 修改 znode 許可權限：

           /usr/hdp/current/zookeeper-client/bin/zkCli.sh

           getAcl /rmstore/ZKRMStateRoot

           setAcl /rmstore/ZKRMStateRoot world:anyone:rwcda

       (11)在 Ambari Web, 重啟 ZooKeeper 服務并啟動 YARN 服務，

   5.3 HBase 高可用性 (HBase High Availability)

   為了在生產環境中幫助實作高可用性冗余， Apache HBase 支持在集群中部署多個 Master. 如果作業于 Hortonworks Data Platform (HDP) 2.2 或更高版本

   環境，Apache Ambari 通過簡單的設定實作多個 HBase Masters

   在 Apache HBase 服務安裝期間和取決于組件分配，Ambari 安裝并配置一個 HBase Master 組件以及多個 RegionServer 組件，為了配置 HBase 服務的高

   可用性，可以運行兩個或更多的 HBase Master 組件，HBase 利用 Zookeeper 來協調集群中運行的兩個或多個 HBase Master 其中的活動 Master. 這意味著

   當 primary HBase Master 失效時，客戶端會自動被轉移到 secondary Master.

    

    

       ● 通過 Ambari 設定多個 HBase Masters (Set Up Multiple HBase Masters Through Ambari)

       Hortonworks 建議使用 Ambari 來配置多個 HBase Master. 完成如下任務：  

       ● 向新創建集群添加第二 HBase Master (Add a Secondary HBase Master to a New Cluster)

       在 安裝 HBase 時，單擊顯示在已選中的 HBase Master 右側的 + 符號圖示添加并選擇一個節點來部署第二個 HBase Master

       ● 向已存在集群添加新的 HBase Master (Add a New HBase Master to an Existing Cluster)

       ①    以集群管理員賬號登錄到 Ambari 管理 UI

       ②    在 Ambari Web, 瀏覽到 Services > HBase.

       ③    在 Service Actions, 單擊 + Add HBase Master

       ④    選要安裝 HBase master 的主機，然后單擊 Confirm Add.

       Ambari 安裝這個新的 HBase Master 并識別 HBase 來管理多個 Master 實體

       ● 手動設定多個 HBase Masters (Set Up Multiple HBase Masters Manually)

       在手動配置多個 HBase Masters 之前，必須根據安裝程序中的指導配置集群上的第一個節點(node-1)，然后完成下面的任務：    

       ①    配置無密碼 SSH 訪問

       ②    準備 node-1

       ③    準備 node-2 和 node-3

       ④    啟動并配置 HBase 集群

       ● 配置無密碼 SSH 訪問 (Configure Passwordless SSH Access)

       集群上的第一個節點(node-1)必須能登錄到集群到其它主機，并且然后可以再登錄回自己來啟動守護行程，可以在所有主機上使用同一用戶名并使用

       無密碼 SSH 登錄來達成此目的，

       ①    在 node-1 上，停止 HBase 服務

       ②    在 node-1 上，以 HBase 用戶登錄并生成 SSH key 對

           $ ssh-keygen -t rsa

           系統列印出 key 對的存盤位置，默認的公鑰為 id_rsa.pub 

       ③    在其他節點上創建目錄來保存公鑰

           在 node-2 上，以 HBase 用戶登錄主機并在用戶主目錄創建 .ssh/ 目錄

           在 node-3 上，重復這一程序

       ④    利用 scp 或其他標準安全工具從 node-1 上復制公鑰到其它兩個節點

           在每個節點上創建一個新檔案 .ssh/authorized_keys 并把 id_rsa.pub 檔案內容添加到這個檔案中

           $ cat id_rsa.pub >> ~/.ssh/authorized_keys

           確保不是復寫到 .ssh/authorized_keys 檔案，

       ⑤    從 node-1 以同一個用戶名使用 SSH 登錄其它節點，應該不會提示輸入密碼

       ⑥    在 node-2 節點，重復第五步，因為它作為一個備份 Master 運行

       ● 準備 node-1 (Prepare node-1)

       因為 node-1 要作為 primary Master 和 ZooKeeper 行程運行，必須停止 node-1 上啟動的 RegionServer

       ①    編輯 conf/regionservers 檔案移除包含 localhost 的行，并為 node-2 和 node-3 添加主機名或 IP 地址

           Note：

               如果想要在 node-1 上運行 RegionServer, 應通過主機名指向它，其他服務器可以用來與之通信，如對于 node-1, 用作 node-1.test.com

       ②    配置 HBase 使用 node-2 作為一個備份 Master, 通過在 conf/ 下創建一個新檔案，稱為 backup-Masters, 在檔案內用 node-2 的主機名添加

           一行，如 node-2.test.com

       ③    在 node-1 上通過編輯 conf/hbase-site.xml 來配置 ZooKeeper, 添加如下屬性：

           <property>

               <name>hbase.zookeeper.quorum</name>

               <value>node-1.test.com,node-2.test.com,node-3.test.com</value>

           </property>

           <property>

               <name>hbase.zookeeper.property.dataDir</name>

               <value>/usr/local/zookeeper</value>

           </property>

           這個配置指示 HBase 在集群的每個節點上啟動并管理一個 ZooKeeper 實體

       ④    修改配置中每個以 localhost 參考到 node-1 的配置指向到主機名，例如，node-1.test.com

       ● 準備 node-2 和 node-3 (Prepare node-2 and node-3)

       在 準備 node-2 和 node-3 之前，每個節點必須有相同的配置資訊

       node-2 運行為一個被非法 Master 服務器和一個 ZooKeeper 實體

       ①    在 node-2 和 node-3 上下載并解包 HBase

       ②    復制 node-1 上的組態檔到 node-2 和 node-3

       ③    復制 conf/ 目錄的內容到 node-2 和 node-3 的 conf/ 目錄

       ● 啟動并測驗 HBase 集群 (Start and Test your HBase Cluster)

       ①    使用 jps 命令確保 HBase 沒有運行

       ②    殺掉 HMaster, HRegionServer, 以及 HQuorumPeer 行程，如果他們正在運行

       ③    在 node-1 上通過運行 start-hbase.sh 啟動集群，必須有類似如下的輸出：

           $ bin/start-hbase.sh

           node-3.test.com: starting zookeeper, logging to /home/hbuser/hbase-0.98.3-

           hadoop2/bin/../logs/hbase-hbuser-zookeeper-node-3.test.com.out

           node-1.example.com: starting zookeeper, logging to /home/hbuser/hbase-0.98.

           3-hadoop2/bin/../logs/hbase-hbuser-zookeeper-node-1.test.com.out

           node-2.example.com: starting zookeeper, logging to /home/hbuser/hbase-0.98.

           3-hadoop2/bin/../logs/hbase-hbuser-zookeeper-node-2.test.com.out

           starting master, logging to /home/hbuser/hbase-0.98.3-hadoop2/bin/../logs/

           hbase-hbuser-master-node-1.test.com.out

           node-3.test.com: starting regionserver, logging to /home/hbuser/hbase-0.98.

           3-hadoop2/bin/../logs/hbase-hbuser-regionserver-node-3.test.com.out

           node-2.test.com: starting regionserver, logging to /home/hbuser/hbase-0.98.

           3-hadoop2/bin/../logs/hbase-hbuser-regionserver-node-2.test.com.out

           node-2.test.com: starting master, logging to /home/hbuser/hbase-0.98.3-

           hadoop2/bin/../logs/hbase-hbuser-master-node2.test.com.out

           ZooKeeper 首先啟動，然后是 Master, 然后是 RegionServer, 最后是 backup Masters

       ④    在每一個節點上運行 jps 命令來驗證每一個服務器上運行了正確的行程

           可能看到額外的 Java 行程也運行在服務器上，如果它們也用于其他目的

             

           Example1. node-1 jps Output

           $ jps

           20355 Jps

           20071 HQuorumPeer

           20137 HMaster

           Example 2. node-2 jps Output

           $ jps

           15930 HRegionServer

           16194 Jps

           15838 HQuorumPeer

           16010 HMaster

           Example 3. node-3 jps Output

           $ jps

           13901 Jps

           13639 HQuorumPeer

           13737 HRegionServer

           ZooKeeper 行程名

           Note：

               HQuorumPeer 行程是 ZooKeeper 實體，由 HBase 控制和啟動，如果以這種方式使用 ZooKeeper，受限制為每個集群節點一個實體，并且

               只適用于測驗，如果 ZooKeeper 運行在 HBase 之外，行程叫做 QuorumPeer.

       ⑤    瀏覽到 Web UI 并測驗新的連接

           應該可以連接到 Master UI http://node-1.test.com:16010/

           或者 secondary master      http://node-2.test.com:16010/

           可以在 16030 埠看到每一個 RegionServer 的 web UI 

   5.4 Hive 高可用性 (Hive High Availability)

   Apache Hive 服務有多個相關聯的組件，主要的 Hive 組件是 Hive Metastore 和 HiveServer2. 可以在 HDP 2.2 或以后版本中為 Hive 服務配置高

   可用性，運行兩個或更多的相關組件，

   5.4.1 添加 Hive Metastore (Adding a Hive Metastore Component)

   前提準備：

       如果 Hive 中有 ACID 啟用，確保 Run Compactor 設定時啟用的(設定為 True) on only one Hive metastore 主機

   步驟：

       ①    在 Ambari Web, 瀏覽到 Services > Hive

       ②    在 Service Actions, 單擊 + Add Hive Metastore 選項

       ③    選取要安裝另外的 Hive Metastore 的主機，然后單擊 Confirm Add

       ④    Ambari 安裝組件并重新配置 Hive 來處理多個 Hive Metastore 實體

   5.4.2 添加 HiveServer2 組件 (Adding a HiveServer2 Component)

   步驟：

       ①    在 Ambari Web，瀏覽到要安裝另一個 HiveServer2 組件的主機    

       ②    在 Host 頁，單擊 +Add.

       ③    從串列中單擊 HiveServer2

       Ambari 安裝另外的 HiveServer2

   5.4.3 添加 WebHCat Server (Adding a WebHCat Server)

   步驟：

       ①    在 Ambari Web，瀏覽到要安裝另一個 WebHCat 服務器的主機

       ②    在 Host 頁，單擊 +Add.

       ③    從串列中單擊 WebHCat

       Ambari 安裝新服務器并重新配置組 Hive

   5.5 Storm 高可用性 (Storm High Availability)

   HDP 2.3 及以后版本，可以通過在 Ambari 上添加 Nimbus 組件配置 Apache Storm Nimbus 服務器高可用性，    

   5.5.1 添加一個 Nimbus 組件 (Adding a Nimbus Component)

   步驟：

       ①    在 Ambari Web, 瀏覽到 Services > Storm

       ②    在 Service Actions, 單擊 + Add Nimbus 選項

       ③    單擊要安裝另外的 Nimbus 的主機，然后單擊 Confirm Add

       Ambari 安裝組件并重新配置 Storm 來處理多個 Nimbus 實體

   5.6 Oozie 高可用性 (Oozie High Availability)

   HDP 2.2 及以后版本，可以設定 Apache Oozie 服務的高可用性，可以運行兩個或多個 Oozie Server 組件，

   前提準備：

       ● 使用默認安裝的 Derby 資料庫實體不支持多 Oozie Server 實體，因此必須使用已有的關系資料庫，當使用 Apache Derby 為 Oozie Server 提供

           資料庫時，沒有添加 Oozie Server 組件到集群中的選項

       ● 對 Oozie 高可用性要求使用外部虛擬 IP 地址(an external virtual IP address) 或負載均衡器(load balancer) 將流量轉發給多個 Oozie 服務器，

   5.6.1 添加一個 Oozie 服務器組件 (Adding an Oozie Server Component)

   步驟：

       (1)    在 Ambari Web, 瀏覽到要安裝另一個 Oozie server 的主機

       (2)    在 Host 頁, 單擊 +Add 按鈕

       (3)    從串列中單擊 Oozie server

       (4)    配置外部負載均衡器，然后更新 Oozie 配置

       (5) 瀏覽到 Services > Oozie > Configs

       (6)    在 oozie-site, 添加如下熟悉值：

           oozie.zookeeper.connection.string

           列出 ZooKeeper  主機，帶有埠，例如：

           c6401.ambari.apache.org:2181,

           c6402.ambari.apache.org:2181,

           c6403.ambari.apache.org:2181

           oozie.services.ext

           org.apache.oozie.service.ZKLocksService,

           org.apache.oozie.service.ZKXLogStreamingService,

           org.apache.oozie.service.ZKJobsConcurrencyService

           oozie.base.url

           http://<Cloadbalancer.hostname>:11000/oozie

    

       (7)    在 oozie-env 中，撤銷 oozie_base_url 屬性注釋，并修改它的值指向負載均衡器：

           export oozie_base_url="http://<loadbalance.hostname>:11000/oozie"

       (8)    重啟 Oozie

       (9)    為 Oozie proxy user 更新 HDFS 配置屬性

           a. 瀏覽到 Services > HDFS > Configs

           b. 在 core-site 中，更新 hadoop.proxyuser.oozie.hosts  屬性，包含新添加的 Oozie server 主機，使用逗號分隔的多個主機名

       (10)重啟服務

   5.7 Apache Atlas 高可用性 (Apache Atlas High Availability)

   步驟：

       (1)    在 Ambari 表盤上，單擊 Hosts, 然后選擇要安裝備用 Atlas Metadata Server 的主機

       (2)    在新 Atlas Metadata Server 主機的 Summary 頁面，單擊 Add > Atlas Metadata Server

           Ambari 添加新的 Atlas Metadata Server 為 Stopped 狀態

       (3) 單擊 Atlas > Configs > Advanced    

       (4)    單擊 Advanced application-properties 并添加 atlas.rest.address 屬性，使用逗號分隔，值為新的 Atlas Metadata Server：

           ,http(s):<host_name>:<port_number>

           默認協議是 "http", 如果 atlas.enableTLS 屬性設定為 true, 使用 "https". 同時，默認的 HTTP 埠為 21000, 并且默認額 HTTPS 埠為 21443

           這些值可以分別使用 atlas.server.http.port 和 atlas.server.https.port 屬性覆寫

       (5)    停止所有當前正在運行的 Atlas Metadata Servers

           重要提示：

               必須使用 Stop  命令來停止 Atlas Metadata Servers . 不要使用 Restart 命令：這會嘗試首先停止新創建的 Atlas Server, 此時在

               /etc/atlas/conf 中還沒有包含任何配置資訊  

       (6)    在 Ambari 表盤上, 單擊 Atlas > Service Actions > Start

           Ambari 會自動配置 Atlas 在 /etc/atlas/conf/atlas-application.properties 檔案中如下屬性：

           ? atlas.server.ids

           ? atlas.server.address.$id

           ? atlas.server.ha.enabled

       (7)    要重繪組態檔，重啟如下含有 Atlas hooks 的服務：

           ? Hive

           ? Storm

           ? Falcon

           ? Sqoop

           ? Oozie

       (8)    單擊 Actions > Restart All Required 來重啟所有要求重啟的服務

           當在 Ambari 中更新了 Atlas 的配置設定， Ambari 標記了要求重啟的服務

       (9)    單擊 Oozie > Service Actions > Restart All 以重啟 Oozie 以及其相關服務

           Apache Oozie 在 Atlas 配置更新之后要求重啟，但有可能沒有包含到 Ambari 標記要求重啟的服務中

   5.8 啟用 Ranger Admin 高可用性 (Enabling Ranger Admin High Availability)

   在 Ambari 管理的集群上，可以配置 Ranger Admin 高可用性帶有或不帶有 SSL ，

   步驟：

       ● HTTPD setup for HTTP - 在 Ambari 中啟用 Ranger Admin HA, 從第 16 步開始：

       https://docs.hortonworks.com/HDPDocuments/HDP2/HDP-2.6.4/bk_hadoop-high-availability/content/configure_ranger_admin_ha.html        \

       #configure_ranger_admin_ha_without_ssl

       ● HTTPD setup for HTTPS - 在 Ambari 中啟用 Ranger Admin HA, 從第 14 步開始

       https://docs.hortonworks.com/HDPDocuments/HDP2/HDP-2.6.4/bk_hadoop-high-availability/content/configure_ranger_admin_ha.html        \

       #configure_ranger_admin_ha_with_ssl

   6 管理配置 (Managing Configurations)

   可以通過調整配置設定和屬性值來優化集群上的 Hadoop 組件的性能，也可以利用 Ambari Web 通過如下方法，來建立和管理配置分組及配置設定的版本：

       ? Changing Configuration Settings

       ? Manage Host Config Groups

       ? Configuring Log Settings

       ? Set Service Configuration Versions

       ? Download Client Configuration Files

   6.1 修改配置設定 (Changing Configuration Settings)

   可以通過每一個服務的 Configs 頁面優化服務性能，Configs 頁面包含幾個選項卡，用于管理配置版本，分組，設定，屬性和值，可以調整設定，稱為

   "Smart Configs" 在宏級別(macro-level) 進行控制，每個服務的記憶體分配，調整 Smart Configs 要求相關配置的設定修改整個集群范圍，Ambari 提示檢驗

   并確認所有建議的修改并重啟相關服務，

   步驟：

       ①    在 Ambari Web 中，在左側的服務串列上單擊服務名稱

       ②    從服務的 Summary 頁面，單擊 Configs 選項卡，然后利用如下選項卡管理配置設定

           利用 Configs tab 管理配置版本和分組

           利用 Settings tab 管理 "Smart Configs", 通過調整綠色的滑動按鈕

           利用 Advanced tab 編輯特殊配置屬性和值

       ③    單擊 Save

   6.1.1 調整智能配置設定 (Adjust Smart Config Settings)

   利用 Settings tab 管理 "Smart Configs", 通過調整綠色滑動按鈕

   步驟：

       ① 在 Settings tab, 單擊并拖拽綠色滑動按鈕到理想值

       ② 編輯顯示為 Override 選項的屬性

       ③ 單擊 Save

   6.1.2 編輯特定屬性 (Edit Specific Properties)

   利用每個服務 Configs 頁面的 Advanced tab 訪問影響該服務性能的屬性組

   步驟：

       ① 在服務的 Configs 頁面，單擊 Advanced

       ② 在 Configs Advanced 頁面，展開類別

       ③ 編輯屬性值

       ④ 單擊 Save

   6.1.3 檢驗并確認配置修改 (Review and Confirm Configuration Changes)

   當修改了一個配置屬性值是，Ambari Stack Advisor 捕捉到修改，并建議修改受此修改影響的所有相關的配置屬性，修改一個屬性，一個 "Smart

   Configuration", 以及其他動作，例如添加或洗掉一個服務、主機或 ZooKeeper server, 或遷移一個 master, 或者啟用一個組件的高可用性，所有要求檢驗

   (review)并確認相關配置的修改，例如，如果提升 YARN 的 Minimum Container Size (Memory), Dependent Configurations 列出所有建議的修改，對此必須

   檢驗(review) 并(可選地)接受(accept)，

   修改的型別突出顯示為如下顏色：

    

       值修改                ：黃色

       添加的屬性             ：綠色

       洗掉的屬性             ：紅色

   檢驗并確認配置屬性修改

   步驟：

       ①    在 Dependent Configurations, 對于每個列出的屬性檢驗摘要資訊

       ②    如果這個修改可以接受，繼續檢驗串列中的下一條屬性

       ③    如果這個修改不可接受，單擊屬性前邊的藍色復選框標記

           單擊復選框標記會清除復選框，清除復選框的修改是沒有確認的，并且也不會發生修改

       ④    檢驗所有列出的修改之后，單擊 OK 以確認所有標記的修改會發生

   6.1.4 重啟組件 (Restart Components)

   編輯并保存配置修改之后，一個 Restart 指示器會出現在組件旁邊要重啟以利用更新的配置值

       ①    單擊指示的 Components 或 Hosts 鏈接來查看有關請求重啟的細節

       ②    單擊 Restart 然后單擊適宜的動作

   6.2 管理主機配置分組 (Manage Host Config Groups)

   Ambari 初始將所有安裝的服務分配集群上所有主機到一個默認的配置分組，例如，使用默認配置部署一個三個節點的集群，HDFS 服務的每個主機都屬于一個

   具有默認配置設定資訊的配置組，

       ● 管理配置分組：

       ①    單擊服務名稱，然后單擊 Configs

       ②    在 Configs 頁面，單擊 Manage Config Groups

       ● 要創建一個新配置組，重新分配主機，并覆寫主機組件的默認設定，可以利用 Manage Configuration Groups 控制元件：

       ①    在 Manage Config Groups 中, 單擊 Create New Configuration Group 的 + 符號按鈕

       ②    命名并描述配置組的名稱，然后選擇 OK

       ● 向新的配置組中添加主機

       ①    在 Manage Config Groups 中，單擊配置組名稱

       ②    單擊 Add Hosts to selected Configuration Group + 符號按鈕

       ③    利用 Select Configuration Group Hosts, 單擊 Components, 然后從串列中單擊一個組件名稱

             

           選取一個組件過濾主機串列，只有所選服務組件存在的主機會列出，要進一步過濾可用主機名稱串列，可以利用 Filter 的下拉串列，默認情況系，

           主機串列通過 IP 地址過濾

       ④    過濾主機串列之后，單擊每個要包含進配置分組主機的復選框

       ⑤    單擊 OK

       ⑥    在 Manage Configuration Groups 中，單擊 Save

       ● 編輯配置分組設定

       ①    在 Configs, 單擊組名稱

       ②    單擊一個 Config Group, 展開組件找到允許 Override 的設定

       ③    提供一個默認值，然后單擊 Override 或 Save

           配置組強制配置屬性允許覆寫，取決于所選服務和組安裝的組件

       ④    Override 提示選取如下選項之一：

           a. 或者單擊一個已存在配置組的名稱，屬性值被第三步提供的值覆寫

           b. 或者創建一個新的配置組，包含默認值，加上被第三步提供的值覆寫的值

           c. 單擊 OK.

       ⑤    單擊 Save

   6.3 配置日志設定 (Configuring Log Settings)

   Ambari 利用 Log4j properties 屬性集控制 Hadoop 集群上運行的每一個服務的日志活動，最初，每個屬性的默認值在 <service_name>-log4j template

   模板檔案中，Log4j 的屬性和值限制了日志檔案的大小和日志檔案備份的數量，每個服務會超過 log4j 模板檔案的設定，要訪問每個服務默認的 Log4j 設定，

   在 Ambari Web 中，瀏覽到 <Service_name> > Configs > Advanced <service_name>-log4j

       ● 修改一個服務的日志檔案大小和備份數量：

       ①     編輯 <service_name> backup file size 以及 <service_name> # of backup files 屬性值

       ②     單擊 Save

       ● 自定義一個服務的 Log4j 設定：

       ①    在 <service_name> log4j template 中編輯屬性

       ②    復制 log4j 模板檔案內容

       ③    瀏覽到 custom <service_name>log4j 屬性組

       ④    將復制到內容粘貼到 custom <service_name>log4j properties, 覆寫掉默認掉內容

       ⑤    單擊 Save

       ⑥    提示時，檢驗并確認建議的配置修改

       ⑦    如果提示，重啟受影響的服務

       重啟服務中的組件會推送顯示在 Custom log4j.properites 中的配置屬性到每一部運行該服務組件的主機，

       如果自定義了日志屬性，定義每個服務怎樣的活動記入日志，需要重繪每個服務名稱前的指示器，確保顯示在 Custom logj4.properties 中的日志屬性

       包含自定義資訊，

       可選地，可以創建配置組來包含自定義日志屬性，

   6.4 設定服務配置版本 (Set Service Configuration Versions)

   Ambari 可以管理配置相關的服務，可以修改配置資訊，查看修改歷史，比較并恢復修改，以及推送配置變化到集群主機

   6.4.1 基本概念 (Basic Concepts)

   理解 Ambari 中服務配置如何組織和存盤非常重要，屬性分組成配置型別，一系列配置型別組成了一個服務的配置集，

   例如， Hadoop Distributed File System (HDFS) 服務包括 hdfs-site, coresite, hdfs-log4j, hadoop-env, and hadoop-policy 配置型別，如果瀏覽到

   Services > HDFS > Configs, 可以編輯這些配置型別的配置屬性，

   Ambari 在服務級別執行配置版本化，因此，當在一個服務上修改一個配置屬性時，Ambari 創建一個服務配置版本，

   6.4.2 術語 (Terminology)

   配置屬性(configuration property)        : 配置屬性由 Ambari 管理，例如 NameNode 堆大小和復制因子

   配置型別(configuration type, config type): 配置屬性的組，例如，hdfs-site

   服務配置(service configurations)        : 特定服務的配置型別集，例如，hdfs-site 和 core-site 作為 HDFS 服務配置的一部分

   修改注釋(change notes)                    ：作為服務配置修改可選的注釋

   服務配置版本(service config version, SCV)    : 特定服務的一個配置版本

   主機配置組(host config group, HCG)        : 一系列配置屬性應用到一個特定的主機集合

   6.4.3 保存修改 (Saving a Change)

       ①    在 Configs, 修改某一配置屬性的值

       ②    選擇 Save

       ③    可選地，輸入描述修改地注釋

       ④    單機 Cancel 繼續編輯，單擊 Discard 保持控制元件沒有任何修改，或者單擊 Save 確認修改

   6.4.4 查看歷史 (Viewing History)

   Ambari Web 中，可以在兩個位置查看配置變化歷史：Dashboard 頁面的 Config History tab, 和每個服務頁面的 Configs tab

   Dashboard > Config History tab 頁面顯示一個所有服務所有版本的表格，每個版本的號碼和創建的時間日期，也可以看到是哪個用戶修改的配置，以及修改

   的注釋，使用這個表格，可以過濾，排序，以及搜索版本，

   Service > Configs tab 頁面只顯示最近配置的修改，當然也可以使用版本滾動條查看更早版本，利用這個選項卡可以快速訪問服務最近的配置修改

   利用這個視圖，可以單擊滾動條內的任何版本來查看，也可以將滑鼠指標懸停在版本上以顯示一個選項選單，可以進行版本比較和執行恢復操作，可以選定

   任何一個最為當前版本，

   6.4.5 比較版本 (Comparing Versions)

   當在 Services > Configs tab 頁面瀏覽版本滾動時，可以將滑鼠指標懸停在版本上顯示 view, compare, or revert (make current) 選項，

   比較兩個服務配置版本：

       ①    導航到某個配置版本，如 V6

       ②    利用版本滾動條，找到要與 V6 進行比較到版本，利潤 V2

       ③    將滑鼠指標懸停在 V2 上顯示選項選單，然后單擊 Compare.

   Ambari 顯示 V6 和 V2 的比較，伴隨一個 revert to V2 ((Make V2 Current) 的選項，Ambari 也在 Filter 控制元件新，通過 Changed properties 過濾顯示

   6.4.6 恢復修改 (Reverting a Change)

   通過 Make Current 特性可以恢復到一個舊的服務配置版本，Make Current 從選擇恢復的版本上，創建一個新的服務配置版本，效果上，相當于一個克隆

   啟動 Make Current 操作后，在 Make Current Confirmation 提示上，輸入注釋并保存(Make Current)

   有多種方法可以恢復到一個之前的配置版本：

       ● 查看一個特定的版本，然后單擊 Make V* Current:

       ● 使用版本導航，然后單擊 Make Current

       ● 將滑鼠指標懸停到版本滾動條中到一個版本，然后單擊 Make Current

       ● 執行版本比較，然后單擊 Make V* Current

   6.4.7 主機配置組 (Host Config Groups)

   服務配置版本作用域范圍是到一個主機配置組，例如，在默認組中的修改可以在那個配置組中被比較和恢復，自定義組中也應用同樣的方式，

   6.5 下載客戶端組態檔 (Download Client Configuration Files)

   客戶端組態檔包括：.xml 檔案, env-sh 腳本, 以及 log4j 屬性用于配置 Hadoop 服務，對于包括客戶端組件的服務(大多數服務，除了 SmartSense 和

   Ambari Metrics 服務)，可以下載與那個服務相關聯的客戶端組態檔，也可以下載整個集群的客戶端組態檔作為一個存檔檔案，

   ● 為單一服務下載客戶端組態檔：

   步驟：

       ①    在 Ambari Web 中，瀏覽到想要配置到服務

       ②    單擊 Service Actions

       ③    單擊 Download Client Configs

       瀏覽器下載一個 "tarball" 存檔檔案只包含選定服務的客戶端組態檔到瀏覽器默認的，本地下載目錄

       ④    如果提示保存或打開客戶端組態檔    

       ⑤    單擊 Save File, 然后單擊 OK

   ● 要為整個集群下載所有客戶端組態檔

       ①    在 Ambari Web, 在服務串列底部單擊 Actions

       ②    單擊 Download Client Configs

       瀏覽器下載一個 "tarball" 存檔檔案包含集群所有客戶端組態檔到瀏覽器默認的，本地下載目錄

   7 管理集群 (Administering the Cluster)

   利用 Ambari Web Admin 選項：

   任何用戶(any user)                    : 可以查看有關安裝堆疊和加入其中的每個服務版本的資訊

   集群管理員(Cluster administrators)    : 能夠

                                       ? 啟用 Kerberos 安全性

                                       ? 重新生成 key tabs

                                       ? 查看服務用戶帳號的名稱和值

                                       ? 啟用服務的自動啟動

   Ambari administrators                ：能夠

                                       ? 添加新服務到安裝堆疊

                                       ? 升級安裝堆疊到一個新的版本            

   7.1 利用安裝堆疊和版本資訊 (Using Stack and Versions Information)

   Stack tab 包含有關集群堆疊中已安裝和可用的服務，任何用戶都可以瀏覽服務串列，作為 Ambari 系統管理員，可以單擊 Add Service 來啟動向導來安裝

   服務到集群中，

   Versions tab 包含有關哪個版本的軟體當前已安裝并運行在集群中的資訊，作為集群管理員，可以在此頁啟動一次自動集群更新，

   7.2 查看服務賬號 (Viewing Service Accounts)

   作為集群管理員，可以查看集群服務的服務用戶和用戶組賬號串列，

   在 Ambari Web UI > Admin, 單擊 Service Accounts

   7.3 啟用 Kerberos 和重新生成 Keytabs (Enabling Kerberos and Regenerating Keytabs)

   作為集群管理員，可以在集群上啟用并管理 Kerberos 安全性，

   前提準備：

       在集群上啟用 Kerberos 之前，必須為集群做好準備，如下列新所描述：

       https://docs.hortonworks.com/HDPDocuments/Ambari-2.6.1.5/bk_ambari-security/content/ch_configuring_amb_hdp_for_kerberos.html

   步驟：

       在 Ambari web UI > Admin 選單，單擊 Enable Kerberos 啟動 Kerberos 向導

   Kerberos 啟用之后，可以在 Ambari web UI > Admin 選單，重新生成 key tabs 以及禁用 Kerberos

   7.3.1 重新生成 Keytabs (Regenerate Key tabs)

   作為集群管理員，可以再生維護 Kerberos 安全性要求的 key tabs

   前提準備：

       再生 key tabs 之前：

       ● 集群必須 Kerberos-enabled

       ● 必須有 KDC Admin 憑證

   步驟：

       ①    瀏覽到 Admin > Kerberos

       ②    單擊 Regenerate Kerberos.

       ③    確認選擇

       ④    Ambari 連接到 Kerberos Key Distribution Center (KDC) 并為服務和集群到 Ambari 負責人再生 key tabs. 可選地，可以只為那些丟失連 key

           tab 的主機生成 key tab, 例如，為那些在 Ambari 啟用 Kerberos 時不在線或不可用的主機再生，

       ⑤    重啟所有服務

   7.3.2 禁用 Kerberos (Disable Kerberos)

   作為集群管理員，可以在集群上禁用 Kerberos

   前提：

       禁用 Kerberos 安全性之前，集群必須已經是 Kerberos-enabled

   步驟：

       ①    瀏覽到 Admin > Kerberos

       ②    單擊 Disable Kerberos

       ③    確認選擇

           集群服務停止，并且 Ambari Kerberos 安全性設定重置

       ④  要重新啟用 Kerberos, 單擊 Enable Kerberos 并跟隨向導

         

         

         

   7.4 啟用服務自動啟動 (Enable Service Auto-Start)

   作為集群管理員或集群操作員，可以啟用安裝堆疊內每一個服務自動重啟，一個服務啟用了 auto-start 會使 ambari-agent 不需要用戶手作業用重新啟動

   停止狀態的服務組件，auto-start 服務默認是啟用的，但只有 Ambari Metrics Collector 組件默認設定為 auto-start，

   作為第一步，應該在核心 Hadoop 服務的作業節點上啟用 auto-start, 例如 YARN 和 HDFS 的 DataNode 以 NameNode 組件， 也應該在 SmartSense 服務中

   為所有組件啟用 auto-start. 啟用 auto-start 之后，在 Ambari Web 表盤中監控服務的操作狀態，Auto-start 不會嘗試顯示為后臺操作，診斷服務組件的

   失敗啟動，檢查 ambari agent 的日志檔案，位于組件主機的 /var/log/ambari-agent.log

   管理一個服務的組件 auto-start 狀態

   步驟：

       ①    在 Auto-Start Services 上，單擊一個服務名稱

       ②    在 Auto-Start Services 控制元件的至少一個組件，單擊灰色區域，使其狀態變為 Enabled

           服務名稱右側的綠色圖示指示該服務啟用了 auto-start 的組件的百分比

       ③    要啟用服務的所有組件為 auto-start, 單擊 Enable All

           綠色圖示填滿指示該服務的所有組件啟用了 auto-start

       ④    要禁用服務所有組件的 auto-start, 單擊 Disable All

           綠色圖示清空指示該服務的所有組件禁用了 auto-start

       ⑤    要清除所有未定的狀態改變，在保存它們之前，單擊 Discard

       ⑥    結束修改 auto-start 狀態設定時，單擊 Save.

   禁用服務當 auto-start :

       ①    在 Ambari Web, 單擊 Admin > Service Auto-Start

       ②    在 Service Auto Start Configuration 中, 在 Auto-Start Services 控制元件上，單擊灰色區域，使其狀態由 Enabled 變為 Disabled

       ③    單擊 Save

   8 啟用服務自動啟動 (Managing Alerts and Notifications)

   Ambari 為每一個集群組件和主機使用一套預定義的七種型別的警報(web, port, metric, aggregate, script, server, and recovery). 可以利用這些警報

   監控集群健康情況，以及向其他用戶報警以幫助識別和處理故障問題，可以修改警報的名稱，描述，以及檢查周期，也可以禁用以及重新啟用警報，

   也可以創建一組警報并設定通知目標給每個用戶組，這樣就可以使用不同的方法通知不同的警報集給不同的用戶組， 

   8.1 理解警報 (Understanding Alerts)

   Ambari 預定義了一系列警報來監控集群組件和主機，每一個警報由一個警報定義(alert definition)來定義，定義警報型別檢查的間隔和閾值，集群創建或

   修改時，Ambari 讀取警報定義并為指定的項(items)創建警報實體進行監控，例如，如果集群包括 Hadoop Distributed File System (HDFS), 有一個警報

   定義用于監控 "DataNode Process". 集群中為每一個 DataNode 創建一個警報定義的實體，

   利用 Ambari Web，通過單擊 Alert tab 可以瀏覽集群上警報定義串列，可以通過當前狀態，最后狀態變化，以及與警報定義相關聯的服務，查找或過濾警報

   的定義，可以單擊 alert definition name 來查看該警報的詳細資訊，或修改警報屬性(如檢查間隔和閾值)，以及該警報定義相關聯的警報實體串列，

   每個警報實體報告一個警報狀態，由嚴重程度定義，最常用的嚴重級別為 OK, WARNING, and CRITICAL, 也有 UNKNOWN 和 NONE 的嚴重級別，警報通知在警報

   狀態發生變化時發送(如，狀態從 OK 變為 CRITICAL)，

   8.1.1 警報型別 (Alert Types)

   警報閾值和閾值的單位取決于警報的狀態，下表列出了警報型別，它們可能的狀態，以及可以配置什么閾值單位，如果閾值可配置的話

   WEB Alert Type            ：WEB 警報監視一個給定組件的 web URL, 警報狀態由 HTTP 回應代碼確定，因此，不能改變 HTTP 的回應代碼來確定 WEB 警報

                           的閾值，可以自定義每個閾值和整個 web 連接超時的回應文本，連接超時被認為是 CRITICAL 警報，閾值單位基于秒，

                           回應代碼對應 WEB 警報的狀態如下：         

                               ● OK status         ：如果 web URL 回應代碼低于 400.

                               ● WARNING status    ：如果 web URL 回應代碼等于或高于 400.

                               ● CRITICAL status    ：如果 Ambari 不能連接到某個 web URL.

                         

   PORT Alert Type            ：PORT 警報檢查連接到一個給定埠的回應時間，閾值單位基于秒

   METRIC Alert Type        ：METRIC 警報檢查一個或多個度量的值(如果執行計算)，度量從一個給定組件上的可用的 URL 端點訪問，連接超時被認為是 CRITICAL

                           警報，      

                           閾值是可調整的，并且每一個閾值的單位取決于度量，例如，在 CPU utilization 警報的場景下，單位是百分數；在

                           RPC latency 警報的場景下，單位為毫秒，

   AGGREGATE Alert Type    ：AGGREGATE 警報聚合警報狀態的數量作為受影響警報數量的百分比，例如，Percent DataNode Process 警報聚合 DataNode Process

                           警報，

   SCRIPT Alert Type        ：SCRIPT 警報執行某個腳本來確定其狀態，例如 OK, WARNING, 或 CRITICAL. 可以自定義回應文本和屬性的值，以及 SCRIPT 警報的

                           閾值，

   SERVER Alert Type        ：SERVER 警報執行一個服務器側的可運行類以確定警報狀態，例如，OK, WARNING, 或 CRITICAL

   RECOVERY Alert Type        ：RECOVERY 警報由 Ambari Agent 處理，用于監控行程重啟，警報狀態 OK, WARNING, 以及 CRITICAL 基于一個行程自動重啟所用時間的

                           數量，這在要了解行程終止并被 Ambari 自動重啟時非常有用，

   8.2 修改警報 (Modifying Alerts)

   警報的通用屬性包括名稱，描述，檢查間隔，以及閾值，

   檢查間隔定義了 Ambari 檢查警報狀態的頻率，例如，"1 minute" 意思是 Ambari 每分鐘檢查警報的狀態，

   閾值的配置選項取決于警報的型別

   修改警報的通用屬性：

       ①    在 Ambari Web 上瀏覽到 Alerts 部分

       ②    找到警報到定義并單擊以查看定義詳細資訊

       ③    單擊 Edit 來修改名稱，描述，檢查間隔，以及閾值(如果可用)

       ④    單擊 Save

       ⑤    在下一次檢查間隔時，在所有警報實體上修改生效

   8.3 修改警報檢查數量 (Modifying Alert Check Counts)

   Ambari 可以設定警報在分發一個通知之前執行檢查的數量，如果警報狀態在一個檢查期間發生了變化，Ambari 在分發通知之前會嘗試檢查這個條件一定的

   次數(check count)，

   警報檢查次數不適用于 AGGREATE 警報型別，一個狀態的變化對于 AGGREATE 警報導致一個通知分發，

   如果環境中經常會用短時的問題導致錯誤的警報，可以提升檢查次數，這種情況下，警報狀態的變化仍然會記錄，但是作為 SOFT 狀態變化，如果在一個指定

   的檢查次數之后警報條件仍然觸發，這個狀態的變化被認為是 HARD, 并且通知被發出，

   通常對所有警報全域設定檢查次數，但如果一個或多個警報實踐中有短時問題的情況，也可以對單個的警報設定一覆寫全域設定值，

   修改全域警報檢查次數：

       ① 在 Ambari Web 中瀏覽到 Alerts 部分

       ② 在 Actions 選單, 單擊 Manage Alert Settings

       ③ 更新 Check Count 值

       ④ 單擊 Save

       對全域警報檢查次數對修改可能要求幾秒鐘后出現在 Ambari UI 的單個警報上

   為單個警報覆寫全域警報檢查次數：

       ① Ambari Web 中瀏覽到 Alerts 部分

       ② 選擇要設定特殊 Check Count 值的警報

       ③ 在右側，單擊 Check Count property 旁的 Edit 圖示

       ④ 更新 Check Count 值

       ⑤ 單擊 Save

   8.4 禁用和再啟用警報 (Disabling and Re-enabling Alerts)

   可以禁用警報，當一個警報禁用時，沒有警報實體生效，并且 Ambari 不在執行該警報的檢查，因而，沒有警報狀態變化會記錄，并且沒有通知發送，

       ① Ambari Web 中瀏覽到 Alerts 部分

       ② 找到警報定義，單擊文本旁的 Enabled 或 Disabled 以啟用/禁用該警報

       ③ 另一方法，單擊警報以查看定義的詳細資訊，然后單擊 Enabled 或 Disabled 以啟用/禁用該警報

       ④ 提示確認啟用/禁用

   8.5 預定義的警報 (Tables of Predefined Alerts)

   8.5.1 HDFS 服務警報 (HDFS Service Alerts)

   □ 警報名稱：NameNode Blocks Health

       警報型別    ：METRIC

       描述        ：This service-level alert is triggered if the number of corrupt or missing blocks exceeds the configured critical threshold.

       潛在原因    ：Some DataNodes are down and the replicas that are missing blocks are only on those DataNodes.

                   The corrupt or missing blocks are from files with a replication factor of 1. New replicas cannot be created because the

                   only replica of the block is missing.

       解決方法    ：For critical data, use a replication factor of 3.

                   Bring up the failed DataNodes with missing or corrupt blocks.

                   Identify the files associated with the missing or corrupt blocks by running the Hadoop fsck command.

                   Delete the corrupt files and recover them from backup, if one exists.

    □ 警報名稱：NFS Gateway Process

       警報型別    ：PORT

       描述        ：This host-level alert is triggered if the NFS Gateway process cannot be confirmed as active.

       潛在原因    ：NFS Gateway is down.

       解決方法    ：Check for a non-operating NFS Gateway in Ambari Web.

   □ 警報名稱：DataNode Storage

       警報型別    ：METRIC

       描述        ：This host-level alert is triggered if storage capacity is full on the DataNode (90% critical). It checks the DataNode

                   JMX Servlet for the Capacity and Remaining properties.

       潛在原因    ：Cluster storage is full.

                   If cluster storage is not full, DataNode is full.

       解決方法    ：If the cluster still has storage, use the load balancer to distribute the data to relatively less-used DataNodes.

                   If the cluster is full, delete unnecessary data or add additional storage by adding either more DataNodes or more or larger

                   disks to the DataNodes. After adding more storage, run the load balancer.

    □ 警報名稱：DataNode Process

       警報型別    ：PORT

       描述        ：This host-level alert is triggered if the individual DataNode processes cannot be established to be up and listening on

                   the network for the configured critical threshold, in seconds.

       潛在原因    ：DataNode process is down or not responding.

                   DataNode are not down but is not listening to the correct network port/address.

       解決方法    ：Check for non-operating DataNodes in Ambari Web.

                   Check for any errors in the DataNode logs (/var/log/hadoop/hdfs) and restart the DataNode, if necessary.

                   Run the netstat -tuplpn command to check if the DataNode process is bound to the correct network port.

   □ 警報名稱：DataNode Web UI

       警報型別    ：WEB

       描述        ：This host-level alert is triggered if the DataNode web UI is unreachable.

       潛在原因    ：The DataNode process is not running.

       解決方法    ：Check whether the DataNode process is running.

   □ 警報名稱：NameNode Host CPU Utilization

       警報型別    ：METRIC

       描述        ：This host-level alert is triggered if CPU utilization of the NameNode exceeds certain thresholds (200% warning,

                   250% critical). It checks the NameNode JMX Servlet for the SystemCPULoad property. This information is available only if

                   you are running JDK 1.7.

       潛在原因    ：Unusually high CPU utilization might be caused by a very unusual job or query workload, but this is generally the sign

                   of an issue in the daemon.

       解決方法    ：Use the top command to determine which processes are consuming excess CPU.

                   Reset the offending process.

   □ 警報名稱：NameNode Web UI

       警報型別    ：WEB

       描述        ：This host-level alert is triggered if the NameNode web UI is unreachable.

       潛在原因    ：The NameNode process is not running.

       解決方法    ：Check whether the NameNode process is running.

   □ 警報名稱：Percent DataNodes with Available Space

       警報型別    ：AGGREGATE

       描述        ：This service-level alert is triggered if the storage is full on a certain percentage of DataNodes(10% warn, 30% critical)

       潛在原因    ：Cluster storage is full.

                   If cluster storage is not full, DataNode is full.

       解決方法    ：If the cluster still has storage, use the load balancer to distribute the data to relatively less-used DataNodes

                   If the cluster is full, delete unnecessary data or increase storage by adding either more DataNodes or more or larger disks

                   to the DataNodes. After adding more storage, run the load balancer.

    □ 警報名稱：Percent DataNodes Available

       警報型別    ：AGGREGATE

       描述        ：This alert is triggered if the number of non-operating DataNodes in the cluster is greater than the configured critical

                   threshold. This    aggregates the DataNode process alert.

       潛在原因    ：DataNodes are down.

                   DataNodes are not down but are not listening to the correct network port/address.

       解決方法    ：Check for non-operating DataNodes in Ambari Web.

                   Check for any errors in the DataNode logs (/var/log/hadoop/hdfs) and restart the DataNode hosts/processes.

                   Run the netstat -tuplpn command to check if the DataNode process is bound to the correct network port.

    □ 警報名稱：NameNode RPC Latency

       警報型別    ：METRIC

       描述        ：This host-level alert is triggered if the NameNode operations RPC latency exceeds the configured critical threshold.

                   Typically an increase in the RPC processing time increases the RPC queue length, causing the average queue wait time to

                   increase for NameNode operations.

       潛在原因    ：A job or an application is performing too many NameNode operations.

       解決方法    ：Review the job or the application for potential bugs causing it to perform too many NameNode operations.

   □ 警報名稱：NameNode Last Checkpoint

       警報型別    ：SCRIPT

       描述        ：This alert will trigger if the last time that the NameNode performed a checkpoint was too long ago or if the number of

                   uncommitted transactions is beyond a certain threshold.

       潛在原因    ：Too much time elapsed since last NameNode checkpoint.

                   Uncommitted transactions beyond threshold.

       解決方法    ：Set NameNode checkpoint.

                   Review threshold for uncommitted transactions.

   □ 警報名稱：Secondary NameNode Process

       警報型別    ：WEB

       描述        ：If the Secondary NameNode process cannot be confirmed to be up and listening on the network. This alert is not applicable

                   when NameNode HA is configured.

       潛在原因    ：The Secondary NameNode is not running.

       解決方法    ：Check that the Secondary DataNode process is running.

    □ 警報名稱：NameNode Directory Status

       警報型別    ：METRIC

       描述        ：This alert checks if the NameNode NameDirStatus metric reports a failed directory.

       潛在原因    ：One or more of the directories are reporting as not healthy.

       解決方法    ：Check the NameNode UI for information about unhealthy directories.

   □ 警報名稱：HDFS Capacity Utilization

       警報型別    ：METRIC

       描述        ：This service-level alert is triggered if the HDFS capacity utilization exceeds the configured critical threshold

                   (80% warn, 90% critical). It checks the NameNode JMX Servlet for the CapacityUsed and CapacityRemaining properties.

       潛在原因    ：Cluster storage is full.

       解決方法    ：Delete unnecessary data.

                   Archive unused data.

                   Add more DataNodes.

                   Add more or larger disks to the DataNodes.

                   After adding more storage, run the load balancer.

   □ 警報名稱: DataNode Health Summary

       警報型別    : METRIC

       描述        : This service-level alert is triggered if there are unhealthy DataNodes.

       潛在原因    : A DataNode is in an unhealthy state.

       解決方法    : Check the NameNode UI for the list of non-operating DataNodes.

       □ 警報名稱：HDFS Pending Deletion Blocks

       警報型別    : METRIC

       描述        : This service-level alert is triggered if the number of blocks pending deletion in HDFS exceeds the configured warning

                   and critical thresholds. It checks the NameNode JMX Servlet for the PendingDeletionBlock property.

       潛在原因    : Large number of blocks are pending deletion.

       解決方法    :

   □ 警報名稱：HDFS Upgrade Finalized State

       警報型別    : SCRIPT

       描述        : This service-level alert is triggered if HDFS is not in the finalized state.

       潛在原因    : The HDFS upgrade is not finalized.

       解決方法    : Finalize any upgrade you have in process.

     □ 警報名稱：DataNode Unmounted Data Dir

       警報型別    : SCRIPT

       描述        : This host-level alert is triggered if one of the data directories on a host was previously on a mount point and became

                   unmounted.

       潛在原因    : If the mount history file does not exist, then report an error if a host has one or more mounted data directories as well

                   as one or more unmounted data directories on the root partition. This may indicate that a data directory is writing to the

                   root partition, which is undesirable.

       解決方法    : Check the data directories to confirm they are mounted as expected.

    □ 警報名稱：DataNode Heap Usage

       警報型別    : METRIC

       描述        : This host-level alert is triggered if heap usage goes past thresholds on the DataNode. It checks the DataNode JMXServlet

                   for the MemHeapUsedM and MemHeapMaxM properties. The threshold values are percentages.

       潛在原因    :

    □ 警報名稱：NameNode Client RPC Queue Latency

       警報型別    : SCRIPT

       描述        : This service-level alert is triggered if the deviation of RPC queue latency on client port has grown beyond the specified

                   threshold within an given period. This alert will monitor Hourly and Daily periods.

       潛在原因    :

       解決方法    :

    □ 警報名稱：NameNode Client RPC Processing Latency

       警報型別    : SCRIPT

       描述        : This service-level alert is triggered if the deviation of RPC latency on client port has grown beyond the specified

                   threshold within a given period. This alert will monitor Hourly and Daily periods.

       潛在原因    :

       解決方法    :

   □ 警報名稱：NameNode Service RPC Queue Latency

       警報型別    : SCRIPT

       描述        : This service-level alert is triggered if the deviation of RPC latency on the DataNode port has grown beyond the specified

                   threshold within a given period. This alert will monitor Hourly and Daily periods.

       潛在原因    :

       解決方法    :

   □ 警報名稱：NameNode Service RPC Processing Latency

       警報型別    : SCRIPT

       描述        : This service-level alert is triggered if the deviation of RPC latency on the DataNode port has grown beyond the specified

                   threshold within a given period. This alert will monitor Hourly and Daily periods.

       潛在原因    :

       解決方法    :

    □ 警報名稱：HDFS Storage Capacity Usage

       警報型別    : SCRIPT

       描述        : This service-level alert is triggered if the increase in storage capacity usage deviation has grown beyond the specified

                   threshold within a given period. This alert will monitor Daily and Weekly periods.

       潛在原因    :

       解決方法    :

   □ 警報名稱：NameNode Heap Usage

       警報型別    : SCRIPT

       描述        : This service-level alert is triggered if the NameNode heap usage deviation has grown beyond the specified threshold

                   within a given period. This alert will monitor Daily and Weekly periods.

       潛在原因    :

       解決方法    :

   8.5.2 HDFS HA 警報 (HDFS HA Alerts)

   □ 警報名稱: JournalNode Web UI

       警報型別    : WEB

       描述        : This host-level alert is triggered if the individual JournalNode process cannot be established to be up and listening

                   on the network for the configured critical threshold, given in seconds.

       潛在原因    : The JournalNode process is down or not responding.

                   The JournalNode is not down but is not listening to the correct network port/address.

       解決方法    :

   □ 警報名稱: NameNode High Availability Health

       警報型別    : SCRIPT

       描述        : This service-level alert is triggered if either the Active NameNode or Standby NameNode are not running.

       潛在原因    : The Active, Standby or both NameNode processes are down.

       解決方法    : On each host running NameNode, check for any errors in the logs (/var/log/hadoop/hdfs/) and restart the NameNode

                   host/process using Ambari Web.

                   On each host running NameNode, run the netstat -tuplpn command to check if the NameNode process is bound to the correct

                   network port.

     警報名稱: Percent JournalNodes Available

       警報型別    : AGGREGATE

       描述        : This service-level alert is triggered if the number of down JournalNodes in the cluster is greater than the configured

                   critical threshold (33% warn, 50% crit ). It aggregates the results of JournalNode process checks.

       潛在原因    : JournalNodes are down.

                   JournalNodes are not down but are not listening to the correct network port/address.

                     

       解決方法    : Check for dead JournalNodes in Ambari Web.

   □ 警報名稱: ZooKeeper Failover Controller Process

       警報型別    : PORT

       描述        : This alert is triggered if the ZooKeeper Failover Controller process cannot be confirmed to be up and listening on the

                   network.

       潛在原因    : The ZKFC process is down or not responding.

       解決方法    : Check if the ZKFC process is running.

   8.5.3 NameNode HA 警報 (NameNode HA Alerts)

   □ 警報名稱: JournalNode Process

       警報型別    : WEB

       描述        : This host-level alert is triggered if the individual JournalNode process cannot be established to be up and listening

                   on the network for the configured critical threshold, given in seconds.

    

       潛在原因    : The JournalNode process is down or not responding.

                   The JournalNode is not down but is not listening to the correct network port/address.

       解決方法    : Check if the JournalNode process is running.

    □ 警報名稱: NameNode High Availability Health

       警報型別    : SCRIPT

       描述        : This service-level alert is triggered if either the Active NameNode or Standby NameNode are not running.

       潛在原因    : The Active, Standby or both NameNode processes are down.

       解決方法    : On each host running NameNode, check for any errors in the logs (/var/log/hadoop/hdfs/) and restart the NameNode

                   host/process using Ambari Web.

                   On each host running NameNode, run the netstat -tuplpn command to check if the NameNode process is bound to the correct

                   network port.

   □ 警報名稱: Percent JournalNodes Available

       警報型別    : AGGREGATE

       描述        : This service-level alert is triggered if the number of down JournalNodes in the cluster is greater than the configured

                   critical threshold (33% warn, 50% crit ). It aggregates the results of JournalNode process checks.

       潛在原因    : JournalNodes are down.

                   JournalNodes are not down but are not listening to the correct network port/address.

                     

       解決方法    : Check for non-operating JournalNodes in Ambari Web.

   □ 警報名稱: ZooKeeper Failover Controller Process

       警報型別    : PORT

       描述        : This alert is triggered if the ZooKeeper Failover Controller process cannot be confirmed to be up and listening on the

                   network.

       潛在原因    : The ZKFC process is down or not responding.

       解決方法    : Check if the ZKFC process is running.

   8.5.4 YARN 警報 (YARN Alerts)

    □ 警報名稱: App Timeline Web UI

       警報型別    : WEB

       描述        : This host-level alert is triggered if the App Timeline Server Web UI is unreachable.

       潛在原因    : The App Timeline Server is down.

                   App Timeline Service is not down but is not listening to the correct network port/address.

    

       解決方法    : Check for non-operating App Timeline Server in Ambari Web.

   □ 警報名稱: Percent NodeManagers Available

       警報型別    : AGGREGATE

       描述        : This alert is triggered if the number of down NodeManagers in the cluster is greater than the configured critical threshold.

                   It aggregates the results of DataNode process alert checks.

       潛在原因    : NodeManagers are down.

                   NodeManagers are not down but are not listening to the correct network port/address.

                     

       解決方法    : Check for non-operating NodeManagers.

                   Check for any errors in the NodeManager logs (/var/log/hadoop/yarn) and restart the NodeManagers hosts/processes, as necessary.

                   Run the netstat -tuplpn command to check if the NodeManager process is bound to the correct network port.

   □ 警報名稱: ResourceManager Web UI

       警報型別    : WEB

       描述        : This host-level alert is triggered if the ResourceManager Web UI is unreachable.

       潛在原因    : The ResourceManager process is not running.

       解決方法    : Check if the ResourceManager process is running.

   □ 警報名稱: ResourceManager RPC Latency

       警報型別    : METRIC

       描述        : This host-level alert is triggered if the ResourceManager operations RPC latency exceeds the configured critical threshold.

                   Typically an increase in the RPC processing time increases the RPC queue length, causing the average queue wait time to

                   increase for ResourceManager operations.

                     

       潛在原因    : A job or an application is performing too many ResourceManager operations

       解決方法    : Review the job or the application for potential bugs causing it to perform too many ResourceManager operations.

   □ 警報名稱: ResourceManager CPU Utilization

       警報型別    : METRIC

       描述        : This host-level alert is triggered if CPU utilization of the ResourceManager exceeds certain thresholds (200% warning,

                   250% critical). It checks the ResourceManager JMX Servlet for the SystemCPULoad property. This information is only available

                   if you are running JDK 1.7.

       潛在原因    : Unusually high CPU utilization: Can be caused by a very unusual job/query workload, but this is generally the sign of

                   an issue in the daemon.

       解決方法    : Use the top command to determine which processes are consuming excess CPU.

                   Reset the offending process.

    □ 警報名稱: NodeManager Web UI

       警報型別    : WEB

       描述        : This host-level alert is triggered if the NodeManager process cannot be established to be up and listening on the network

                   for the configured critical threshold, given in seconds.

      

       潛在原因    : NodeManager process is down or not responding.

                   NodeManager is not down but is not listening to the correct network port/address.

    

       解決方法    : Check if the NodeManager is running.

                   Check for any errors in the NodeManager logs (/var/log/hadoop/yarn) and restart the NodeManager, if necessary.

    □ 警報名稱: NodeManager Health Summary

       警報型別    : SCRIPT

       描述        : This host-level alert checks the node health property available from the NodeManager component.

       潛在原因    : NodeManager Health Check script reports issues or is not configured.

       解決方法    : Check in the NodeManager logs (/var/log/hadoop/yarn) for health check errors and restart the NodeManager, and restart

                   if necessary.

                   Check in the ResourceManager UI logs (/var/log/hadoop/yarn) for health check errors.

    □ 警報名稱: NodeManager Health

       警報型別    : SCRIPT

       描述        : This host-level alert checks the nodeHealthy property available from the NodeManager component.

       潛在原因    : The NodeManager process is down or not responding.

       解決方法    : Check in the NodeManager logs (/var/log/hadoop/yarn) for health check errors and restart the NodeManager, and restart

                   if necessary.

   8.5.5 MapReduce2 警報 (MapReduce2 Alerts)

   □ 警報名稱: History Server Web UI

       警報型別    : WEB

       描述        : This host-level alert is triggered if the HistoryServer Web UI is unreachable.

       潛在原因    : The HistoryServer process is not running.

       解決方法    : Check if the HistoryServer process is running.

    □ 警報名稱: History Server RPC latency

       警報型別    : METRIC

       描述        : This host-level alert is triggered if the HistoryServer operations RPC latency exceeds the configured critical threshold.

                   Typically an increase in the RPC processing time increases the RPC queue length, causing the average queue wait time to

                   increase for NameNode operations.

       潛在原因    : A job or an application is performing too many HistoryServer operations.

       解決方法    : Review the job or the application for potential bugs causing it to perform too many HistoryServer operations.

   □ 警報名稱: History Server CPU Utilization

       警報型別    : METRIC

       描述        : This host-level alert is triggered if the percent of CPU utilization on the HistoryServer exceeds the configured

                   critical threshold.

       潛在原因    : Unusually high CPU utilization: Can be caused by a very unusual job/query workload, but this is generally the sign of

                   an issue in the daemon.

       解決方法    : Use the top command to determine which processes are consuming excess CPU.

                   Reset the offending process.

    □ 警報名稱: History Server Process

       警報型別    : PORT

       描述        : This host-level alert is triggered if the HistoryServer process cannot be established to be up and listening on the

                   network for the configured critical threshold, given in seconds.

       潛在原因    : HistoryServer process is down or not responding.

                   HistoryServer is not down but is not listening to the correct network port/address.

       解決方法    : Check the HistoryServer is running.

                   Check for any errors in the HistoryServer logs (/var/log/hadoop/mapred) and restart the HistoryServer, if necessary.

   8.5.6 HBase 服務警報 (HBase Service Alerts)

    □ 警報名稱: Percent RegionServers Available

       警報型別    :

       描述        : This service-level alert is triggered if the configured percentage of Region Server processes cannot be determined to be

                   up and listening on the network for the configured critical threshold. The default setting is 10% to produce a WARN alert

                   and 30% to produce a CRITICAL alert. It aggregates the results of RegionServer process down checks.

       潛在原因    : Misconfiguration or less-thanideal configuration caused the RegionServers to crash.

                   Cascading failures brought on by some workload caused the RegionServers to crash.

                   The RegionServers shut themselves own because there were problems in the dependent services, ZooKeeper or HDFS.

                   GC paused the RegionServer for too long and the RegionServers lost contact with Zookeeper.

    

       解決方法    : Check the dependent services to make sure they are operating correctly.

                   Look at the RegionServer log files (usually /var/log/hbase/*.log) for further information.

                   If the failure was associated with a particular workload, try to understand the workload better.

                   Restart the RegionServers.

   □ 警報名稱: HBase Master Process

       警報型別    :

       描述        : This alert is triggered if the HBase master processes cannot be confirmed to be up and listening on the network for

                   the configured critical threshold, given in seconds.

       潛在原因    : The HBase master process is down.

                   The HBase master has shut itself down because there were problems in the dependent services, ZooKeeper or HDFS.

    

       解決方法    : Check the dependent services.

                   Look at the master log files (usually /var/log/hbase/*.log) for further information.

                   Look at the configuration files (/etc/hbase/conf).

                   Restart the master.

   □ 警報名稱: HBase Master CPU Utilization

       描述        : This host-level alert is triggered if CPU utilization of the HBase Master exceeds certain thresholds (200% warning,

                   250% critical). It checks the HBase Master JMX Servlet for the SystemCPULoad property. This information is only available

                   if you are running JDK 1.7.

    

       潛在原因    : Unusually high CPU utilization: Can be caused by a very unusual job/query workload, but this is generally the sign of

                   an issue in the daemon.

                     

       解決方法    : Use the top command to determine which processes are consuming excess CPU

                   Reset the offending process.

    □ 警報名稱: RegionServers Health Summary

       描述        : This service-level alert is triggered if there are unhealthy RegionServers

       潛在原因    : The RegionServer process is down on the host.

                   The RegionServer process is up and running but not listening on the correct network port (default 60030).

    

       解決方法    : Check for dead RegionServer in Ambari Web.

    □ 警報名稱: HBase RegionServer Process

       描述        : This host-level alert is triggered if the RegionServer processes cannot be confirmed to be up and listening on the

                   network for the configured critical threshold, given in seconds.

    

       潛在原因    : The RegionServer process is down on the host.

                   The RegionServer process is up and running but not listening on the correct network port (default 60030).

    

       解決方法    : Check for any errors in the logs (/var/log/hbase/) and restart the RegionServer process using Ambari Web.

                   Run the netstat -tuplpn command to check if the RegionServer process is bound to the correct network port.

   8.5.7 Hive 警報 (Hive Alerts)

    □ 警報名稱: HiveServer2 Process

       警報型別    :

       描述        : This host-level alert is triggered if the HiveServer cannot be determined to be up and responding to client requests.

    

       潛在原因    : HiveServer2 process is not running.

                   HiveServer2 process is not responding.

    

       解決方法    : Using Ambari Web, check status of HiveServer2 component. Stop and then restart.

   □ 警報名稱: HiveMetastore Process

       描述        : This host-level alert is triggered if the Hive Metastore process cannot be determined to be up and listening on the

                   network for the configured critical threshold, given in seconds.

       潛在原因    : The Hive Metastore service is down.

                   The database used by the Hive Metastore is down.

                   The Hive Metastore host is not reachable over the network.

       解決方法    : Using Ambari Web, stop the Hive service and then restart it.

    □ 警報名稱: WebHCat Server Status

       警報型別    :

       描述        : This host-level alert is triggered if the WebHCat server cannot be determined to be up and responding to client requests.

       潛在原因    : The WebHCat server is down.

                   The WebHCat server is hung and not responding.

                   The WebHCat server is not reachable over the network.

       解決方法    : Restart the WebHCat server using Ambari Web.

   8.5.8 Oozie 警報 (Oozie Alerts)

   □ 警報名稱: Oozie Server Web UI

       描述        : This host-level alert is triggered if the Oozie server Web UI is unreachable.

       潛在原因    : The Oozie server is down.

                   Oozie Server is not down but is not listening to the correct network port/address.

       解決方法    : Check for dead Oozie Server in Ambari Web.

    □ 警報名稱: Oozie Server Status

       描述        : This host-level alert is triggered if the Oozie server cannot be determined to be up and responding to client requests.

       潛在原因    : The Oozie server is down.

                   The Oozie server is hung and not responding.

                   The Oozie server is not reachable over the network.

       解決方法    : Restart the Oozie service using Ambari Web.

   8.5.9 ZooKeeper 警報 (ZooKeeper Alerts)

   □ 警報名稱: Percent ZooKeeper Servers Available

       警報型別    : AGGREGATE

       描述        : This service-level alert is triggered if the configured percentage of ZooKeeper processes cannot be determined to be up

                   and listening on the network for the configured critical threshold, given in seconds. It aggregates the results of

                   ZooKeeper process checks.

       潛在原因    : The majority of your ZooKeeper servers are down and not responding.

       解決方法    : Check the dependent services to make sure they are operating correctly.

                   Check the ZooKeeper logs (/var/log/hadoop/zookeeper.log) for further information.

                   If the failure was associated with a particular workload, try to understand the workload better.

                   Restart the ZooKeeper servers from the Ambari UI.

   □ 警報名稱: ZooKeeper Server Process

       警報型別    : PORT

       描述        : This host-level alert is triggered if the ZooKeeper server process cannot be determined to be up and listening on the

                   network for the configured critical threshold, given in seconds.

       潛在原因    : The ZooKeeper server process is down on the host.

                   The ZooKeeper server process is up and running but not listening on the correct network port (default 2181).

       解決方法    : Check for any errors in the ZooKeeper logs (/var/log/hbase/) and restart the ZooKeeper process using Ambari Web.

                   Run the netstat -tuplpn command to check if the ZooKeeper server process is bound to the correct network port.

   8.5.10 Ambari 警報 (Ambari Alerts)

   □ 警報名稱: Host Disk Usage

       警報型別    : SCRIPT

       描述        : This host-level alert is triggered if the amount of disk space used on a host goes above specific thresholds (50% warn,

                   80% crit ).

       潛在原因    : The amount of free disk space left is low.

       解決方法    : Check host for disk space to free or add more storage.

   □ 警報名稱: Ambari Agent Heartbeat

       警報型別    : SERVER

       描述        : This alert is triggered if the server has lost contact with an agent.

       潛在原因    : Ambari Server host is unreachable from Agent host

                   Ambari Agent is not running

       解決方法    : Check connection from Agent host to Ambari Server

                   Check Agent is running

    □ 警報名稱: Ambari Server Alerts

       警報型別    : SERVER

       描述        : This alert is triggered if the server detects that there are alerts which have not run in a timely manner

       潛在原因    : Agents are not reporting alert status

                   Agents are not running

       解決方法    : Check that all Agents are running and heartbeating

   8.5.11 Ambari Metrics 警報 (Ambari Metrics Alerts)

    □ 警報名稱: Metrics Collector Process

       描述        : This alert is triggered if the Metrics Collector cannot be confirmed to be up and listening on the configured port for

                   number of seconds equal    to threshold.

       潛在原因    : The Metrics Collector process is not running.

       解決方法    : Check the Metrics Collector is running.

    □ 警報名稱: Metrics Collector –ZooKeeper Server Process

       警報型別    :

       描述        : This host-level alert is triggered if the Metrics Collector ZooKeeper Server Process cannot be determined to be up and

                   listening on the network.

       潛在原因    : The Metrics Collector process is not running.

       解決方法    : Check the Metrics Collector is running.

    □ 警報名稱: Metrics Collector –HBase Master Process

       警報型別    :

       描述        : This alert is triggered if the Metrics Collector HBase Master Processes cannot be confirmed to be up and listening on

                   the network for the configured critical threshold, given in seconds.

       潛在原因    : The Metrics Collector process is not running.

       解決方法    : Check the Metrics Collector is running.

    □ 警報名稱: Metrics Collector – HBase Master CPU Utilization

       警報型別    :

       描述        : This host-level alert is triggered if CPU utilization of the Metrics Collector exceeds certain thresholds.

       潛在原因    : Unusually high CPU utilization generally the sign of an issue in the daemon configuration.

       解決方法    : Tune the Ambari Metrics Collector.

   □ 警報名稱: Metrics Monitor Status

       警報型別    :

       描述        : This host-level alert is triggered if the Metrics Monitor process cannot be confirmed to be up and running on the network.

       潛在原因    : The Metrics Monitor is down.

       解決方法    : Check whether the Metrics Monitor is running on the given host.

   □ 警報名稱: Percent Metrics Monitors Available

       描述        : This is an AGGREGATE alert of the Metrics Monitor Status.

       潛在原因    : Metrics Monitors are down.

       解決方法    : Check the Metrics Monitors are running.

   □ 警報名稱: Metrics Collector -Auto-Restart Status

       描述        : This alert is triggered if the Metrics Collector has been auto-started for number of times equal to start threshold in

                   a 1 hour timeframe. By default if restarted 2 times in an hour, you will receive a Warning alert. If restarted 4 or more

                   times in an hour, you will receive a Critical alert.

       潛在原因    : The Metrics Collector is running but is unstable and causing restarts. This could be due to improper tuning.

       解決方法    : Tune the Ambari Metrics Collector.

    □ 警報名稱: Percent Metrics Monitors Available

       描述        : This is an AGGREGATE alert of the Metrics Monitor Status.

       潛在原因    : Metrics Monitors are down.

       解決方法    : Check the Metrics Monitors.

   □ 警報名稱: Grafana Web UI

       描述        : This host-level alert is triggered if the AMS Grafana Web UI is unreachable.

       潛在原因    : Grafana process is not running.

       解決方法    : Check whether the Grafana process is running. Restart if it has gone down.

   8.5.12 SmartSenses 警報 (SmartSense Alerts)

   □ 警報名稱: SmartSense Server Process

       描述        : This alert is triggered if the HST server process cannot be confirmed to be up and listening on the network for the

                   configured critical threshold, given in seconds.

       潛在原因    : HST server is not running.

       解決方法    : Start HST server process. If startup fails, check the hst-server.log.

    □ 警報名稱: SmartSense Bundle Capture Failure

       描述        : This alert is triggered if the last triggered SmartSense bundle is failed or timed out.

       潛在原因    : Some nodes are timed out during capture or fail during data capture. It could also be because upload to Hortonworks fails.

       解決方法    : From the "Bundles" page check the status of bundle. Next, check which agents have failed or timed out, and review their logs.

                   You can also initiate a new capture.

   □ 警報名稱: SmartSense Long Running Bundle

       描述        : This alert is triggered if the SmartSense in-progress bundle has possibility of not completing successfully on time.

       潛在原因    : Service components that are getting collected may not be running. Or some agents may be timing out during data

                   collection/upload.

       解決方法    : Restart the services that are not running. Force-complete the bundle and start a new capture.

    □ 警報名稱: SmartSense Gateway Status

       描述        : This alert is triggered if the SmartSense Gateway server process is enabled but is unable to reach.

       潛在原因    : SmartSense Gateway is not running.

       解決方法    : Start the gateway. If gateway start fails, review hst-gateway.log

   8.6 管理通知 (Managing Notifications)

   利用警報組和通知可以創建警報分組，并為每個分組設定通知目標，通過這種方式可以把一組警報以不同的方式發送給不同的集群參與者，例如，可能想要

   Hadoop Operations team 通過 email 接收所有的警報，不管警報是什么狀態，同時，想要系統管理員小組只接收 RPC 和 CPU 相關的 Critical 狀態的警報，

   并且只通過 simple network management protocol(SNMP) 方式接收，

   為了實作這些不同的結果，可以用一個警報通知，用于管理對所有警報組的所有的嚴重級別的 email 通知，用一個不同的警報組來管理 SNMP 方式發送的

   Critical 嚴重性級別的警報通知，只包含 RPC 和 CPU 警報，

   8.7 創建和編輯通知 (Creating and Editing Notifications)

       ① Ambari Web 中, 單擊 Alerts

       ② 在 Alerts 頁面，單擊 Actions 選單，然后單擊 Manage Notifications

       ③ 在 Manage Alert Notifications 中，單擊 + 創建一個新的警報通知

           在 Create Alert Notification 中

           ● 在 Name 文本框，輸入通知的名稱

           ● 在 Groups 欄位，單擊 All 或 Custom 分配通知給所有或設定的組

           ● 在 Description 欄位，輸入描述通知的短語

           ● 在 Method 欄位，單擊 EMAIL, SNMP (for MIB-based) 或 Custom SNMP 作為 Ambari server 發送通知的方法

       ④ 完成所選擇的通知方法欄位定義

           ● 對于 email 通知，提供有關 SMTP 的資訊，如，SMTP server, port ,以及 from 地址，服務器是否要求認證

           可以對 SMTP 配置添加自定義的屬性，基于Javamail SMTP

               Email To            ：由一個或多個 email 地址組成的逗號分隔的串列，用于發送警報給這些 email 地址

               SMTP Server            ：用于發送警報 email 的 SMTP server 的 FDQN 或 IP 地址

               SMTP Port            ：SMTP server 的 SMTP 埠

               Email From            ：一個 email 地址用于發送警報 email 的發送者

               Use Authentication    ：確定在進行發送訊息之前， SMTP server 是否要求身份驗證，也要提供用戶名和密碼憑證

             

           ● 對于 MIB-based SNMP 通知，提供版本，community, 主機和埠，用于 SNMP trap 發送

               Version        ：SNMPv1 或 SNMPv2c, 取決于網路環境

               Hosts        ：逗號分隔的一個或多個主機 FDQN 串列，用于發送 trap

               Port        ：行程用于監聽 SNMP traps 的埠

               對于 SNMP 通知， Ambari 使用 "MIB", 一個文本檔案警報定義的清單，來傳輸警報資訊，MIB 概述了物件 ID 如何

               映射為物件或屬性，

               可以在 Ambari server 主機上找到集群的 MIB 檔案：

                   /var/lib/ambari-server/resources/APACHE-AMBARI-MIB.txt

           ● 對于自定義 SNMP 通知，提供版本，community, 主機和埠，用于 SNMP trap 發送，

             OID 引數必須配置正確，如果沒有自定義，使用 enterprise-specific OID

             Version SNMPv1 or SNMPv2c, depending on the network environment

           OID 1.3.6.1.4.1.18060.16.1.1

           Hosts A comma-separated list of one or more host FQDNs to which to send the

           trap

           Port The port on which a process is listening for SNMP traps

       ⑤ 單擊 Save

   8.8 創建或編輯通知組 (Creating or Editing Alert Groups)

       ① Ambari Web 中, 單擊 Alerts

       ② 在 Alerts 頁面，單擊 Actions 選單，然后單擊 Manage Alert Groups

       ③ 在 Manage Alert Groups 中，單擊 + 創建一個新的警報組

       ④ 在 Create Alert Group 中，輸入組名稱然后單擊 Save

       ⑤ 通過在串列中單擊自定義的組，可以添加或洗掉警報定義，并可以改變該組的通知目標

       ⑥ 完成分配之后，單擊 Save

   8.9 分發通知 (Dispatching Notifications)

   當啟用了一個警報并且警報的狀態發生變化時(例如，從 OK 變為 CRITICAL, 或從 CRITICAL 變為 OK), Ambari 或者發送一個 email 或 SNMP 通知，取決于

   如何配置的通知，

   對于 email 通知，Ambari 發送一封 email 包含所有警報狀態的變化，例如，如果有兩個警報變為 critical, Ambari 發送一封 email 訊息：

       Alert A is CRITICAL and Ambari B alert is CRITICAL

   Ambari 不會發送另外一封 email 通知，直到狀態再次發生變化，

   對于 SNMP 通知，Ambari 每個警報狀態變化發送一個 SNMP trap. 例如，有兩個警報狀態變為 critical, Ambari 發送兩個 SNMP trap, 每個警報一個，然后

   這兩個警報狀態再次變化時，再次發送，

   8.10 查看警報狀態日志 (Viewing the Alert Status Log)

   不管 Ambari 是否配置為發送警報通知，它都會將警報狀態的變化寫入 Ambari server 主機的日志，查看日志：

       ① 在 Ambari server 主機上，瀏覽到日志目錄

           cd /var/log/ambari-server/

             

       ② 查看 ambari-alerts.log 檔案

       ③ 日志條目包括狀態變化的時間，警報狀態，警報定義名稱，以及回應文本

   8.10.1 自定義通知模板 (Customizing Notification Templates)

   由 Ambari 產生的通知模板內容取決于通知的型別，Email 和 SNMP 通知都有自定義的模板用于生成內容，本節描述改變用于 Ambari 創建警報通知模板的

   必要步驟，

       警報模板的 XML 位置

       默認情況下，Ambari 自帶有一個 alert-templates.xml 檔案，這個檔案包含每一個已知型別通知的所有的模板(例如， EMAIL 和 SNMP). 這個檔案

       打包到 Ambari server 的 .jar 檔案，因此模板沒有存在于磁盤上，但是，這個檔案用于如下文本，作為一個參考示例，

       當自定義警報模板時，可以高效得覆寫默認的警報模板的 XML, 如下：

       ① 在 Ambari server 主機上，瀏覽到 /etc/ambari-server/conf 目錄

       ② 編輯 ambari.properties 檔案

       ③ 為新模板添加一個位置條目

           alerts.template.file=/foo/var/alert-templates-custom.xml

       ④ 保存檔案并重啟 Ambari Server

       重啟 Ambari Server 之后，新模板中定義的任何通知型別都會覆寫打包在 Ambari 中的模板定義，如果選擇提供自己的模板檔案，只需要定義希望覆寫

       的型別，如果一個通知模板型別在自定義的模板中沒有找到，Ambari 會使用打包到 JAR 檔案中的默認模板，

       警報模板的 XML 結構

       模板檔案的結構定義如下，每個 <alert-template> 元素宣告警報通知要用于什么型別：

       <alert-templates>

           <alert-template type="EMAIL">

               <subject>

                   Subject Content

               </subject>

               <body>

                   Body Content

               </body>

           </alert-template>

           <alert-template type="SNMP">

               <subject>

                   Subject Content

               </subject>

               <body>

                   Body Content

               </body>

           </alert-template>

       </alert-templates>

       模板變數

       模板利用 Apache Velocity 來表現所有標記的內容(tokenized content). 下面的變數可用于模板：

       $alert.getAlertDefinition() The definition of which the alert is an instance.

       $alert.getAlertText() The specific alert text.

       $alert.getAlertName() The name of the alert.

       $alert.getAlertState() The alert state (OK, WARNING, CRITICAL, or

       UNKNOWN)

       $alert.getServiceName() The name of the service that the alert is defined for.

       $alert.hasComponentName() True if the alert is for a specific service component.

       $alert.getComponentName() The component, if any, that the alert is defined for.

       $alert.hasHostName() True if the alert was triggered for a specific host.

       $alert.getHostName() The hostname, if any, that the alert was triggered for.

       $ambari.getServerUrl() The Ambari Server URL.

       $ambari.getServerVersion() The Ambari Server version.

       $ambari.getServerHostName() The Ambari Server hostname.

       $dispatch.getTargetName() The notification target name.

       $dispatch.getTargetDescription() The notification target description.

       $summary.getAlerts(service,alertStaAte li)st of all alerts for a given service or alert state (OK|

       WARNING|CRITICAL|UNKNOWN)

       $summary.getServicesByAlertState(Aal elirsttS otaf tael)l services for a given alert state (OK|

       WARNING|CRITICAL|UNKNOWN)

       $summary.getServices() A list of all services that are reporting an alert in the

       notification.

       $summary.getCriticalCount() The CRITICAL alert count.

       $summary.getOkCount() The OK alert count.

       $summary.getTotalCount() The total alert count.

       $summary.getUnknownCount() The UNKNOWN alert count.

       $summary.getWarningCount() The WARNING alert count.

       $summary.getAlerts() A list of all of the alerts in the notification.

       示例：Modify Alert EMAIL Subject

       下面示例演示如何改變所有出站 email 通知的主題行(subject line), 包括一個硬編碼的識別符號：

   ① 下載 alert-templates.xml 代碼作為開始

   ② 在 Ambari Server 上，保存模板到一個位置，例如，/var/lib/ambariserver/ resources/alert-templates-custom.xml

   ③ 編輯 alert-templates-custom.xml 檔案并修改 <alerttemplate type="EMAIL"> 模板的主題行

           <subject>

           <![CDATA[Petstore Ambari has $summary.getTotalCount() alerts!]]>

           </subject>

       ④ 保存檔案

       ⑤ 瀏覽到 /etc/ambari-server/conf 目錄

       ⑥ 編輯 ambari.properties 檔案

       ⑦ 為新模板檔案的位置添加一條目

           alerts.template.file=/var/lib/ambari-server/resources/alerttemplates-custom.xml

    

       ⑧ 保存檔案并重啟 Ambari Server

   9. 使用 Ambari 核心服務 (Using Ambari Core Services)

   Ambari 核心服務可用于監控，分析，以及搜索集群主機的操作狀態，

   9.1 理解 Ambari 度量器 (Understanding Ambari Metrics)

   Ambari Metrics System (AMS) 在 Ambari 管理的集群上收集，聚集，并服務于 Hadoop 和系統度量

   9.1.1 AMS 體系結構 (AMS Architecture)

   AMS 有四個組件：Metrics Monitors, Hadoop Sinks, Metrics Collector, 以及 Grafana.

       ? Metrics Monitors    ：在集群的每部主機上收集系統級別的度量并發布到 Metrics Collector 上

       ? Hadoop Sinks        ：插入到 Hadoop 組件中用于發布 Hadoop 度量到 Metrics Collector 上

       ? Metrics Collector    ：是一個運行在集群上特定主機中的 daemon 并從注冊的發布者接收資料，Monitors 和 Sinks

       ? Grafana             ：是一個運行在集群上特定主機中的 daemon，并為在 Metrics Collector 中收集到的 metrics 的可視化提供預構建表盤

   9.1.2 使用 Grafana (Using Grafana)

   Ambari Metrics System 包括 Grafana 用于為高級可視化集群度量提供預構建表盤，

   9.1.2.1 訪問 Grafana (Accessing Grafana)

       ① Ambari Web 中，瀏覽到 Services > Ambari Metrics > Summary

       ② 選擇 Quick Links 然后選取 Grafana

       一個只讀版本的 Grafana 頁面在瀏覽器的一個新 tab 頁面打開  

   9.1.2.2 查看 Grafana 表盤(Viewing Grafana Dashboards)

   在 Grafana 主頁上，Dashboards 提供了一個 AMS 鏈接串列，Ambari server, Druid and HBase metrics.

   查看包含在串列中的特定 metric:

       ① 在 Grafana 中，瀏覽到 Dashboards

       ② 單擊 Dashboards 名稱

       ③ 查看更多表盤，單擊 Home 串列

       ④ 滾動查看這個串列

       例如，System - Servers

   9.1.2.3 在 Grafana 表盤上查看選擇的 Metrics (Viewing Selected Metrics on Grafana Dashboards)

   在表盤上，展開一個或多個行以查看詳細的度量， 例如：

   在 System - Servers 表盤上，單擊行名稱，例如單擊 System Load Average - 1 Minute

   這個行展開以顯示一個圖表顯示度量資訊，    

   9.1.2.4 查看選定主機的 Metrics (Viewing Metrics for Selected Hosts)

   默認情況下，Grafana 顯示集群上所有主機 metric. 通過從 Hosts  選單上選擇，可以限制顯示一個或幾個主機的 metric

       ① 展開 Hosts

       ② 選擇一個或多個主機名

   9.1.3 Grafana 表盤參考 (Grafana Dashboards Reference)

   Ambari Metrics System 包含的 Grafana 為集群 metrics 的高級可視化帶有預構建的表盤，

    

       ? AMS HBase Dashboards

       ? Ambari Dashboards

       ? HDFS Dashboards

       ? YARN Dashboards

       ? Hive Dashboards

       ? Hive LLAP Dashboards

       ? HBase Dashboards

       ? Kafka Dashboards

       ? Storm Dashboards

       ? System Dashboards

       ? NiFi Dashboard

   9.1.3.1 AMS HBase 表盤 (AMS HBase Dashboards)

   AMS HBase 指的是由 Ambari Metrics Service 獨立管理的 HBase 實體，它與集群的 HBase 服務沒有任何連接，AMS HBase 表盤跟蹤與常規 HBase 表盤

   相同的度量，只是 AMS 自身的實體，

   如下的 Grafana 表盤適用于  AMS HBase

       ? AMS HBase - Home

       ? AMS HBase - RegionServers

       ? AMS HBase - Misc

   9.1.3.1.1 AMS HBase 表盤 (AMS HBase - Home)

   AMS HBase - Home 表盤顯示 HBase 集群基本的統計資訊，這些儀表提供了 HBase 集群整體狀態的觀察，

       REGIONSERVERS / REGIONS

       -------------------------------------------------------------------------------------------------------------------------------------

       Num RegionServers                    : Total number of RegionServers in the cluster.

       Num Dead RegionServers                : Total number of RegionServers that are dead in the cluster.

       Num Regions                            : Total number of regions in the cluster.

       Avg Num Regions per RegionServer    : Average number of regions per RegionServer.

       NUM REGIONS/STORES

       Num Regions /Stores - Total            : Total number of regions and stores (column families) in the cluster.

       Store File Size /Count - Total        : Total data file size and number of store files.

       NUM REQUESTS

       Num Requests - Total                : Total number of requests (read, write and RPCs) in the cluster.

       Num Request - Breakdown - Total        : Total number of get,put,mutate,etc requests in the cluster.

       REGIONSERVER MEMORY

       RegionServer Memory - Average        : Average used, max or committed on-heap and offheap memory for RegionServers.

       RegionServer Offheap Memory - Average    : Average used, free or committed on-heap and offheap memory for RegionServers.

    MEMORY - MEMSTORE BLOCKCACHE

       Memstore - BlockCache - Average        : Average blockcache and memstore sizes for RegionServers.

       Num Blocks in BlockCache - Total    : Total number of (hfile) blocks in the blockcaches across all RegionServers.

       BLOCKCACHE

       BlockCache Hit/Miss/s Total            : Total number of blockcache hits misses and evictions across all RegionServers.

       BlockCache Hit Percent - Average    : Average blockcache hit percentage across all RegionServers.

       OPERATION LATENCIES - GET/MUTATE  

       Get Latencies - Average                : Average min, median, max, 75th, 95th, 99th percentile latencies for Get operation across

                                           all RegionServers.

       Mutate Latencies - Average            : Average min, median, max, 75th, 95th, 99th percentile latencies for Mutate operation across

                                           all RegionServers.

       OPERATION LATENCIES - DELETE/INCREMENT

       Delete Latencies - Average            : Average min, median, max, 75th, 95th, 99th percentile latencies for Delete operation across

                                           all RegionServers.

       Increment Latencies - Average        : Average min, median, max, 75th, 95th, 99th percentile latencies for Increment operation across

                                           all RegionServers.

       OPERATION LATENCIES - APPEND/REPLAY 

       Append Latencies - Average            : Average min, median, max, 75th, 95th, 99th percentile latencies for Append operation across

                                           all RegionServers.

       Replay Latencies - Average            : Average min, median, max, 75th, 95th, 99th percentile latencies for Replay operation across

                                           all RegionServers.

       REGIONSERVER RPC

       RegionServer RPC - Average            : Average number of RPCs, active handler threads and open connections across all RegionServers.

       RegionServer RPC Queues - Average    : Average number of calls in different RPC scheduling queues and the size of all requests in the

                                           RPC queue across all RegionServers.

       REGIONSERVER RPC  

       RegionServer RPC Throughput - Average    : Average sent and received bytes from the RPC across all RegionServers.

   9.1.3.1.2 AMS HBase 表盤 (AMS HBase - RegionServers)

   AMS HBase - RegionServers 儀表顯示在監控的 HBase 集群中的 RegionServers 度量，包括一些性能相關的資料，這些儀表幫助查看基本 I/O 資料，以及

   RegionServers 中進行負載比較，

   9.1.3.1.3 AMS HBase 表盤 (AMS HBase - Misc)

   AMS HBase - Misc 儀表顯示 HBase 集群相關的多方面的度量資訊，可以在某些任務中利用這些度量資訊，例如，除錯身份認證，授權問題，以及由

   RegionServers 產生的例外問題等，

   9.1.3.2 Ambari 表盤 (Ambari Dashboards)

   下面的儀表可用于 Ambari ：

       ? Ambari Server Database

       ? Ambari Server JVM

       ? Ambari Server Top N

   9.1.3.2.1 Ambari server 資料庫 (Ambari Server Database)

   顯示 Ambari server 資料庫的操作狀態，

       TOTAL READ ALL QUERY

       Total Read All Query Counter (Rate)        : Total ReadAllQuery operations performed.

       Total Read All Query Timer (Rate)        : Total time spent on ReadAllQuery.

       TOTAL CACHE HITS & MISSES

       Total Cache Hits (Rate)                    : Total cache hits on Ambari Server with respect to EclipseLink cache.

       Total Cache Misses (Rate)                : Total cache misses on Ambari Server with respect to EclipseLink cache.

       QUERY  

       Query Stages Timings                    : Average time spent on every query sub stage by Ambari Server

       Query Types Avg. Timings                : Average time spent on every query type by Ambari Server.

       HOST ROLE COMMAND ENTITY

       Counter.ReadAllQuery.HostRoleCommandEntity (Rate)    : Rate (num operations per second) in which ReadAllQuery operation on

                                                           HostRoleCommandEntity is performed.

       Timer.ReadAllQuery.HostRoleCommandEntity (Rate)        : Rate in which ReadAllQuery operation on HostRoleCommandEntity is performed.

       ReadAllQuery.HostRoleCommandEntity                    : Average time taken for a ReadAllQuery operation on HostRoleCommandEntity (

                                                           Timer / Counter).

   9.1.3.2.2 Ambari server JVM (Ambari Server JVM)

       JVM - MEMORY PRESSURE

       Heap Usage            : Used, max or committed on-heap memory for Ambari Server.

       Off-Heap Usage        : Used, max or committed off-heap memory for Ambari Server.

       JVM GC COUNT

       GC Count Par new /s    : Number of Java ParNew (YoungGen) Garbage Collections per second.

       GC Time Par new /s    : Total time spend in Java ParNew(YoungGen) Garbage Collections per second.

       GC Count CMS /s        : Number of Java Garbage Collections per second.

       GC Time Par CMS /s    : Total time spend in Java CMS Garbage Collections per second.

       JVM THREAD COUNT

       Thread Count        : Number of active, daemon, deadlock, blocked and runnable threads.

   9.1.3.2.3 Ambari Server Top N (Ambari Server Top N)

       READ ALL QUERY

       Top ReadAllQuery Counters    : Top N Ambari Server entities by number of ReadAllQuery operations performed.

       Top ReadAllQuery Timers        : Top N Ambari Server entities by time spent on ReadAllQuery operations.

       Cache Misses

       Cache Misses                : Top N Ambari Server entities by number of Cache Misses.

   9.1.3.3 Druid Dashboards  

   9.1.3.4 HDFS Dashboards

   如下 Grafana 儀表適用于 Hadoop Distributed File System (HDFS) 組件

       ? HDFS - Home

       ? HDFS - NameNodes

       ? HDFS - DataNodes

       ? HDFS - Top-N

       ? HDFS - Users

   9.1.3.5 YARN Dashboards

   如下 Grafana 儀表適用于 YARN:

       ? YARN - Home

       ? YARN - Applications

       ? YARN - MR JobHistory Server

       ? YARN - MR JobHistory Server

       ? YARN - NodeManagers

       ? YARN - Queues

       ? YARN - ResourceManager

   9.1.3.6 Hive Dashboards

   如下 Grafana 儀表適用于 Hive:

       ? Hive - Home

       ? Hive - HiveMetaStore

       ? Hive - HiveServer2

   9.1.3.7 Hive LLAP Dashboards

   如下 Grafana 儀表適用于 Hive LLAP:

       ? Hive LLAP - Heatmap

       ? Hive LLAP - Overview

       ? Hive LLAP - Daemon

   9.1.3.8 HBase Dashboards

   如下 Grafana 儀表適用于 Hive HBase:

       ? HBase - Home

       ? HBase - RegionServers

       ? HBase - Misc

       ? HBase - Tables

       ? HBase - Users

   9.1.3.9 Kafka Dashboards

   如下 Grafana 儀表適用于 Hive Kafka:

       ? Kafka - Home

       ? Kafka - Hosts

       ? Kafka - Topics  

   9.1.3.10 Storm Dashboards  

   如下 Grafana 儀表適用于 Hive Storm:

       ? Storm - Home

       ? Storm - Topology

       ? Storm - Components     

   9.1.3.11 System Dashboards  

   如下 Grafana 儀表適用于 Hive System:    

       ? System - Home

       ? System - Servers     

   9.1.3.12 NiFi Dashboards 

   如下 Grafana 儀表適用于 Hive NiFi:    

       ? NiFi-Home

   9.1.4 AMS 性能調優 (AMS Performance Tuning)

   要在環境中設定 Ambari Metrics System, 查看并自定義如下 Metrics Collector 配置選項：

       ? Customizing the Metrics Collector Mode

       ? Customizing TTL Settings

       ? Customizing Memory Settings

       ? Customizing Cluster-Environment-Specific Settings

       ? Moving the Metrics Collector

       ? (Optional) Enabling Individual Region, Table, and User Metrics for HBase

   9.1.4.1 自定義 Metrics Collector 模式 (Customizing the Metrics Collector Mode)

   Metrics Collector 利用 Hadoop 技術構建，例如 Apache HBase, Apache Phoenix, and Apache Traffic Server (ATS).    Collector 可存盤度量資料到本地

   檔案系統，成為 embedded mode, 或使用外部 HDFS, 成為 distributed mode. 默認情況下，Collector 運行于嵌入模式，在嵌入模式下，Collector 獲取

   資料并把度量資料寫入到運行 Collector 主機的本地檔案系統，

       重要提示：

           運行嵌入模式時，應該確認 hbase.rootdir 和 hbase.tmp.dir 有足夠的大小容納資料，并且負載要輕，目錄配置在

               Ambari Metrics > Configs > Advanced > ams-hbasesite

           所在磁區要有足夠的大小，并且負載不要繁重，例如：

           file:///grid/0/var/lib/ambari-metrics-collector/hbase.

           也要確認 TTL 設定合適，

   Collector 配置為分布式模式，它將度量資料寫入到 HDFS, 并且組件運行于分布式行程上，有助于管理 CPU 和記憶體消耗，

   切換 Metrics Collector 從嵌入模式到分布式模式：

       ① 在 Ambari Web 中, 瀏覽到 Services > Ambari Metrics > Configs

       ② 修改列于如下表格中的屬性值：

         

         

   +-----------------------+-------------------------------------------+-------------------------------+-------------------------------+

   | Configuration Section    | Property                                    | Description                    | Value                            |

   +-----------------------+-------------------------------------------+-------------------------------+-------------------------------+

   | General                |Metrics Service operation mode             | Designates whether to run in    |distributed                    |

   |                        |(timeline.metrics.service.operation.mode)    | distributed or embedded mode.    |                                |

   +-----------------------+-------------------------------------------+-------------------------------+-------------------------------+

   | Advanced amshbase-site| hbase.cluster.distributed                    | Indicates AMS will run in     |true                            |

   |                        |                                            | distributed mode.                |                                |

   +-----------------------+-------------------------------------------+-------------------------------+-------------------------------+

   | Advanced amshbase-site| hbase.rootdir 1                            |The HDFS directory location     |hdfs://$NAMENODE_FQDN:8020/    |

   |                        |                                            |where metrics will be stored    |apps/ams/metrics                |

   +-----------------------+-------------------------------------------+-------------------------------+-------------------------------+

       ③ Ambari Web > Hosts > Components 重啟 Metrics Collector

       如果集群配置為 NameNode 高可用性，設定 hbase.rootdir 值為 HDFS 名稱服務替代 NameNode 主機名稱：

           hdfs://hdfsnameservice/apps/ams/metrics

       可選地，可以在切換到分布式模式之前，將本地存盤的現有資料遷移到 HDFS，

       步驟：

           ① 為 ams 用戶創建目錄  

               su - hdfs -c 'hdfs dfs -mkdir -p /apps/ams/metrics'

           ② 停止 Metrics Collector

           ③ 將度量資料從 AMS 本地目錄復制到 HDFS 目錄，這是 hbase.rootdir 值，如：

               su - hdfs -c 'hdfs dfs -copyFromLocal /var/lib/ambari-metrics-collector/hbase/* /apps/ams/metrics'

               su - hdfs -c 'hdfs dfs -chown -R ams:hadoop /apps/ams/metrics'

           ④ 切換到分布式模式

           ⑤ 重啟 Metrics Collector

   9.1.4.2 自定義 TTL 設定 (Customizing TTL Settings)

   AMS 可以為聚集的度量設定 Time To Live (TTL), 通過 Ambari Metrics > Configs > Advanced ams-siteEach 自解釋的屬性名，以及控制度量值在其被

   清除之前保持的時間數量(單位，秒)，TTL 設定的時間值單位為秒，

    

   例如，假設正在運行一個單節點的沙箱(a single-node sandbox), 并且要確保不保存超過七天的資料，以降低磁盤空間消耗，可以設定任何以 .ttl 結尾的

   屬性值為 604800(七天的秒數)，

   可能要為 timeline.metrics.cluster.aggregator.daily.ttl 屬性設定這個值，控制每日聚集 TTL, 默認設定為 2 年，

   另外兩個消耗大量磁盤空間的屬性為：

       ? timeline.metrics.cluster.aggregator.minute.ttl     : 控制分鐘級聚集度量 TTL

       ? timeline.metrics.host.aggregator.ttl                : 控制基于主機精度的度量 TTL

   9.1.4.3 自定義 Memory 設定 (Customizing Memory Settings)

   因為 AMS 使用多個組件(例如 Apache HBase 和 Apache Phoenix) 來存盤度量和查詢，因此多個可調控的屬性可用于調優記憶體使用：

    

       +---------------------------+-------------------------------+-------------------------------------------------------------------+

       |         配置                |         屬性                    |        描述                                                        |

       +---------------------------+-------------------------------+-------------------------------------------------------------------+

       | Advanced ams-env            | metrics_collector_heapsize    | Heap size configuration for the Collector.                        |

       +---------------------------+-------------------------------+-------------------------------------------------------------------+

       | Advanced ams-hbase-env    | hbase_regionserver_heapsize    | Heap size configuration for the single AMS HBase Region Server.    |

       +---------------------------+-------------------------------+-------------------------------------------------------------------+

       | Advanced ams-hbase-env    | hbase_master_heapsize            | Heap size configuration for the single AMS HBase Master.            |

       +---------------------------+-------------------------------+-------------------------------------------------------------------+

       | Advanced ams-hbase-env    | regionserver_xmn_size            | Maximum value for the young generation heap size for the single    |

       |                            |                                | AMS HBase RegionServer.                                            |

       +---------------------------+-------------------------------+-------------------------------------------------------------------+

       | Advanced ams-hbase-env    | hbase_master_xmn_size            | Maximum value for the young generation heap size for the single    |

       |                            |                                | AMS HBase Master.                                                    |

       +---------------------------+-------------------------------+-------------------------------------------------------------------+

    

    

    

   9.1.4.4 自定義集群環境特定的設定 (Customizing Cluster-Environment-Specific Settings)

   對 AMS 的 Metrics Collector 模式，TTL 設定，記憶體設定，以及磁盤空間要求取決于集群的節點數量，下面表格列出對每種配置的建議和調優原則：

           +---------------+-----------+-----------+---------------+---------------+-----------------------------------+

           |集群環境         | 主機數量    | 磁盤空間    | Collector     | TTL            | Memory 設定                        |

           |                |            |            | 模式            |                |                                    |

           +---------------+-----------+-----------+---------------+---------------+-----------------------------------+

           |Single-Node    | 1            | 2GB        | embedded        |Reduce TTLs    |metrics_collector_heap_size=1024    |

           |Sandbox        |            |            |                |to 7 Days        |hbase_regionserver_heapsize=512    |

           |                |            |            |                |                |hbase_master_heapsize=512            |

           |                |            |            |                |                |hbase_master_xmn_size=128            |

           +---------------+-----------+-----------+---------------+---------------+-----------------------------------+

           |PoC            | 1-5        | 5GB        | embedded        |Reduce TTLs    |metrics_collector_heap_size=1024    |

           |                |            |            |                |to 30 Days        |hbase_regionserver_heapsize=512    |

           |                |            |            |                |                |hbase_master_heapsize=512            |

           |                |            |            |                |                |hbase_master_xmn_size=128            |

           +---------------+-----------+-----------+---------------+---------------+-----------------------------------+

           |Pre-Production    | 5-20        | 20GB        | embedded        |Reduce TTLs    |metrics_collector_heap_size=1024    |

           |                |            |            |                |to 3 Months    |hbase_regionserver_heapsize=1024    |

           |                |            |            |                |                |hbase_master_heapsize=512            |

           |                |            |            |                |                |hbase_master_xmn_size=128            |

           +---------------+-----------+-----------+---------------+---------------+-----------------------------------+

           |Production        | 20-50        | 50GB        | embedded        | n.a.            |metrics_collector_heap_size=1024    |

           |                |            |            |                |                |hbase_regionserver_heapsize=1024    |

           |                |            |            |                |                |hbase_master_heapsize=512            |

           |                |            |            |                |                |hbase_master_xmn_size=128            |

           +---------------+-----------+-----------+---------------+---------------+-----------------------------------+

           |Production        | 50-200    | 100GB        | embedded        | n.a.            |metrics_collector_heap_size=2048    |

           |                |            |            |                |                |hbase_regionserver_heapsize=2048    |

           |                |            |            |                |                |hbase_master_heapsize=2048            |

           |                |            |            |                |                |hbase_master_xmn_size=256            |

           +---------------+-----------+-----------+---------------+---------------+-----------------------------------+

           |Production        | 200-400    | 200GB        | embedded        | n.a.            |metrics_collector_heap_size=2048    |

           |                |            |            |                |                |hbase_regionserver_heapsize=2048    |

           |                |            |            |                |                |hbase_master_heapsize=2048            |

           |                |            |            |                |                |hbase_master_xmn_size=512            |

           +---------------+-----------+-----------+---------------+---------------+-----------------------------------+

           |Production        | 400-800    | 200GB        | distributed    | n.a.            |metrics_collector_heap_size=8192    |

           |                |            |            |                |                |hbase_regionserver_heapsize=122288    |

           |                |            |            |                |                |hbase_master_heapsize=1024            |

           |                |            |            |                |                |hbase_master_xmn_size=1024            |

           |                |            |            |                |                |regionserver_xmn_size=1024            |

           +---------------+-----------+-----------+---------------+---------------+-----------------------------------+

           |Production        | 800+        | 500GB        | distributed    | n.a.            |metrics_collector_heap_size=12288    |

           |                |            |            |                |                |hbase_regionserver_heapsize=16384    |

           |                |            |            |                |                |hbase_master_heapsize=16384        |

           |                |            |            |                |                |hbase_master_xmn_size=2048            |

           |                |            |            |                |                |regionserver_xmn_size=1024            |

           +---------------+-----------+-----------+---------------+---------------+-----------------------------------+

    

    

    

   9.1.4.5 移動 Metrics Collector (Moving the Metrics Collector)

   使用如下程序將 Ambari Metrics Collector 移動到一個新的主機上：

       ① 在 Ambari Web , 停止 Ambari Metrics 服務

       ② 執行下列 API 呼叫來洗掉當前的 Metric Collector 組件：

           curl -u admin:admin -H "X-Requested-By:ambari" - i -X    \

          DELETE http://ambari.server:8080/api/v1/clusters/cluster.name/hosts/metrics.collector.hostname/host_components/METRICS_COLLECTOR

       ③ 執行下列 API 呼叫在新主機上添加 Metric Collector：

           curl -u admin:admin -H "X-Requested-By:ambari" - i -X    \

           POST http://ambari.server:8080/api/v1/clusters/cluster.name/hosts/metrics.collector.hostname/host_components/METRICS_COLLECTOR

       ④ 在 Ambari Web, 導航到安裝了新 Metrics Collector 的主機上并單擊 Install the Metrics Collector

       ⑤ 在 Ambari Web, 啟動 Ambari Metrics 服務

   9.1.4.6 (可選)為 HBase 啟動單獨的 Region, Table, and User Metrics (Enabling Individual Region, Table, and User Metrics for HBase)

   不像 HBase RegionServer metrics, Ambari 默認禁用 per region, per table, and per user metrics, 因為這些 metrics 非常多因而會導致性能問題，

   如果要 Ambari 收集這些 metrics, 可以重新啟用它們，然而，要首先測驗這個選項并確認 AMS 性能可接受，

       ① 在 Ambari Server 上，瀏覽到如下位置：

           /var/lib/ambari-server/resources/common-services/HBASE/0.96.0.2.0/package/templates

       ② 編輯如下模板檔案：

           hadoop-metrics2-hbase.properties-GANGLIA-MASTER.j2

           hadoop-metrics2-hbase.properties-GANGLIA-RS.j2

       ③ 注釋掉或者洗掉下面的行

           *.source.filter.class=org.apache.hadoop.metrics2.filter.RegexFilter

           hbase.*.source.filter.exclude=.*(Regions|Users|Tables).*

       ④ 保存模板檔案并重啟 Ambari Server 使修改生效，

       重要提示：

           如果 Ambari 升級到一個新的版本，必須要重新對模板檔案進行上述修改

   9.1.5 AMS 高可用性 (AMS High Availability)

   Ambari 默認安裝 Ambari Metrics System (AMS) 到集群中一個 Metrics Collector 組件，Collector 是運行在集群的一個特定主機上的守護行程，從注冊

   的發布者接收資料，Monitors 和 Sinks .

   取決于需要，可以要求 AMS 有兩個 Collector 來形成高可用性情形，

   前提：

       必須部署 AMS 為分布式模式(not embedded)

   步驟：

       ① 在 Ambari Web 中，瀏覽到打算安裝另一個收集器的主機

       ② 在 Hosts 頁面，選取 +Add

       ③ 從串列上選取 Metrics Collector

         

           Ambari 安裝新的 Metrics Collector 并配置 HA 的 Ambari Metrics

           新安裝的收集器處于 "stopped" 狀態

       ④ 在 Ambari Web 中，啟動新的 Collector 組件

       Note：

       如果在安裝第二個 Collector 到集群中之前沒有將 AMS 切換為分布式模式，第二個收集器會被安裝，但不會啟動，

   9.1.6 AMS 安全性 (AMS Security)

   9.1.6.1 修改 Grafana 管理員密碼 (Changing the Grafana Admin Password)

   如果需要在初始安裝 Ambari 之后修改  Grafana 管理員密碼，可以直接在 Grafana 中修改密碼，然后在 Ambari Metrics 配置中做同樣的修改，

       (1) 在 Ambari Web 中, 瀏覽到 Services > Ambari Metrics, 選擇 Quick Links, 然后選取 Grafana 

           Grafana UI 以只讀方式打開    

       (2) 單擊 Sign In

       (3) 以管理員登錄，使用未更改的密碼 admin/admin

       (4) 單擊 admin 標簽以查看管理員資訊，單擊 Change password

       (5) 輸入未改變的密碼，輸入并確認新密碼，然后單擊 Change password 按鈕

       (6) 回到 Ambari Web > Services > Ambari Metrics, 然后瀏覽 Configs tab

       (7) 在 General 部分，使用新密碼更新并確認 Grafana Admin Password

       (8) 保存配置并重啟服務，如果提示，

   9.1.6.2 為 AMS 設定 HTTPS (Set Up HTTPS for AMS)  

   如果要限制訪問 AMS 通過 HTTPS 連接，必須提供一個證書，起初測驗的時候可以使用自簽名的證書，但不適用于生產環境，在獲得了一個證書之后，必須

   運行特定的安裝命令(setup command)，

   步驟：

       (1)    創建自己的 CA 證書(CA certificate)

           openssl req -new -x509 -keyout ca.key -out ca.crt -days 365

       (2)    匯入 CA 證書到信任站 (truststore)

           # keytool -keystore /<path>/truststore.jks -alias CARoot -import -file ca.crt -storepass bigdata

       (3) 檢查 truststore

           # keytool -keystore /<path>/truststore.jks -list

           Enter keystore password:

           Keystore type: JKS

           Keystore provider: SUN

           Your keystore contains 2 entries

           caroot, Feb 22, 2016, trustedCertEntry,

           Certificate fingerprint (SHA1):

           AD:EE:A5:BC:A8:FA:61:2F:4D:B3:53:3D:29:23:58:AB:2E:B1:82:AF

       (4) 為 AMS Collector 生成證書并存盤私鑰到 keystore.

           # keytool -genkey -alias c6401.ambari.apache.org -keyalg RSA -keysize 1024

           -dname "CN=c6401.ambari.apache.org,OU=IT,O=Apache,L=US,ST=US,C=US" -keypass

           bigdata -keystore /<path>/keystore.jks -storepass bigdata

       (5) 為 AMS collector 證書創建證書請求(certificate request)

           keytool -keystore /<path>/keystore.jks -alias c6401.ambari.apache.org -certreq -file c6401.ambari.apache.org.csr -storepass bigdata

       (6) 利用 CA 證書為證書請求簽名

           openssl x509 -req -CA ca.crt -CAkey ca.key -in c6401.ambari.apache.org.csr

           -out c6401.ambari.apache.org_signed.crt -days 365 -CAcreateserial -passin

           pass:bigdata

       (7) 把 CA 證書匯入到 keystore.

           keytool -keystore /<path>/keystore.jks -alias CARoot -import -file ca.crt -storepass bigdata

       (8) 匯入簽名的證書到 keystore.

           keytool -keystore /<path>/keystore.jks -alias c6401.ambari.apache.org -

           import -file c6401.ambari.apache.org_signed.crt -storepass bigdata

       (9) 檢查 keystore.

           caroot2, Feb 22, 2016, trustedCertEntry,

           Certificate fingerprint (SHA1):

           7C:B7:0C:27:8E:0D:31:E7:BE:F8:BE:A1:A4:1E:81:22:FC:E5:37:D7

           [root@c6401 tmp]# keytool -keystore /tmp/keystore.jks -list

           Enter keystore password:

           Keystore type: JKS

           Keystore provider: SUN

           Your keystore contains 2 entries

           caroot, Feb 22, 2016, trustedCertEntry,

           Certificate fingerprint (SHA1):

           AD:EE:A5:BC:A8:FA:61:2F:4D:B3:53:3D:29:23:58:AB:2E:B1:82:AF

           c6401.ambari.apache.org, Feb 22, 2016, PrivateKeyEntry,

           Certificate fingerprint (SHA1):

           A2:F9:BE:56:7A:7A:8B:4C:5E:A6:63:60:B7:70:50:43:34:14:EE:AF

       (10) 復制 /<path>/truststore.jks 檔案到所有節點的 /<path>/truststore.jks 并設定合適的訪問權限

       (11) 復制 /<path>/keystore.jks 檔案到 AMS 收集器節點只到 /<path>/keystore.jks 路徑，并設定合適的訪問權限，建議設定 ams 用戶為檔案 owner, 并設定

           訪問權限為 400

   (12) 在 Ambari Web 中，更新 AMS 配置，setams-site/timeline.metrics.service.http.policy=HTTPS_ONLY         

           ?ams-ssl-server/ssl.server.keystore.keypassword=bigdata

           ?ams-ssl-server/ssl.server.keystore.location=/<path>/keystore.jks

           ?ams-ssl-server/ssl.server.keystore.password=bigdata

           ?ams-ssl-server/ssl.server.keystore.type=jks

           ?ams-ssl-server/ssl.server.truststore.location=/<path>/truststore.jks

           ?ams-ssl-server/ssl.server.truststore.password=bigdata

           ?ams-ssl-server/ssl.server.truststore.reload.interval=10000

           ?ams-ssl-server/ssl.server.truststore.type=jks

           ?ams-ssl-client/ssl.client.truststore.location=/<path>/truststore.jks

           ?ams-ssl-client/ssl.client.truststore.password=bigdata

           ?ams-ssl-client/ssl.client.truststore.type=jks

           ?ssl.client.truststore.alias=<Alias used to create certificate for AMS. (Default is hostname)>

       (13) 重啟服務

       (14) 配置 Ambari server 使用 truststore

           # ambari-server setup-security

           Using python /usr/bin/python

           Security setup options...

           ===========================================================================

           Choose one of the following options:

           [1] Enable HTTPS for Ambari server.

           [2] Encrypt passwords stored in ambari.properties file.

           [3] Setup Ambari kerberos JAAS configuration.

           [4] Setup truststore.

           [5] Import certificate to truststore.

           ===========================================================================

           Enter choice, (1-5): 4

           Do you want to configure a truststore [y/n] (y)?

           TrustStore type [jks/jceks/pkcs12] (jks):jks

           Path to TrustStore file :/<path>/keystore.jks

           Password for TrustStore:

           Re-enter password:

           Ambari Server 'setup-security' completed successfully.

       (15) 配置 ambari server 在請求 AMS Collector 時使用 https 替代 http：

         

           # echo "server.timeline.metrics.https.enabled=true" >> /etc/ambari-server/conf/ambari.properties

       (16) 重啟 ambari server

   9.1.6.3 為 Grafana 設定 HTTPS (Set Up HTTPS for Grafana)       

   如果要限制訪問 Grafana 通過 HTTPS 連接，必須提供一個證書，起初測驗的時候可以使用自簽名的證書，但不適用于生產環境，在獲得了一個證書之后，

   必須運行特定的安裝命令(setup command)，

   步驟：

       (1) 登錄到 Grafana 主機上

       (2) 瀏覽到 Grafana 配置目錄

           cd /etc/ambari-metrics-grafana/conf/

       (3) 定位到證書

           如果要創建一個臨時的自簽名證書，可以運行：

           openssl genrsa -out ams-grafana.key 2048

           openssl req -new -key ams-grafana.key -out ams-grafana.csr

           openssl x509 -req -days 365 -in ams-grafana.csr -signkey ams-grafana.key -

           out ams-grafana.crt

             

       (4) 設定證書和秘鑰檔案的所有者和權限，讓 Grafana 可以訪問

           chown ams:hadoop ams-grafana.crt

           chown ams:hadoop ams-grafana.key

           chmod 400 ams-grafana.crt

           chmod 400 ams-grafana.key

           對于 non-root Ambari user, 使用：

           chmod 444 ams-grafana.crt

           讓 agent user 可以讀取檔案 

       (5) 在 Ambari Web, 瀏覽到 Services > Ambari Metrics > Configs

       (6) 在 Advanced ams-grafana-ini 部分更新如下屬性：

           protocol https

           cert_file /etc/ambari-metrics-grafana/conf/ams-grafana.crt

           cert-Key /etc/ambari-metrics-grafana/conf/ams-grafana.key

       (7) 保存配置并重啟服務，如果提示，

   9.2 Ambari 日志搜索 (Ambari Log Search, Technical Preview)

   下面幾節描述 Ambari Log Search 的技術概覽(Technical Preview), 只能在少于 150 個節點的非生產環境集群上使用，

   9.2.1 Ambari 日志搜索體系結構 (Log Search Architecture)

   Ambari Log Search 可以搜索由 Ambari-managed HDP 組件生成的日志，Ambari Log Search 依賴于由 Apache Solr 索引服務提供的 Ambari Infra 服務，

   兩個組件組成了 Log Search 解決方案：

       ? Log Feeder

       ? Log Search Server

   9.2.1.1 Log Feeder

   Log Feeder 組件分析組件日志，Log Feeder 被部署到集群的所有節點上，并與該節點上所有的組件日志互動，啟動時，Log Feeder 開始分析所有已知的

   組件日志并把它們發送給 Apache Solr 實體(由 Ambari Infra 服務管理) 以進行索引，

   默認情況下，只有 FATAL, ERROR, and WARN 日志被 Log Feeder 捕捉，可以利用 Log Search UI 過濾器設定來臨時或永久地添加其他日志級別，

   9.2.1.2 Log Search Server

   Log Search Server 承載著 Log Search UI web 應用程式，為 Ambari 提供 API, 并且 Log Search UI 訪問已索引的組件日志，作為本地或 LDAP 用戶登錄

   之后，可以利用 Log Search UI 可視化，瀏覽，以及搜索索引化了的組件日志，

   9.2.2 Installing Log Search

   Log Search 是 Ambari 2.4 及以后版本的內置服務，可以在一個新的安裝程序中通過 +Add Service 選單安裝， Log Feeders 自動安裝到集群的所有節點上

   可以手動將 Log Search Server 安裝到與 Ambari Server 同一部主機上，

   9.2.3 使用 Log Search (Using Log Search)

   使用 Log Search 包括如下活動：

       ? Accessing Log Search

       ? Using Log Search to Troubleshoot

       ? Viewing Service Logs

       ? Viewing Access Logs

   9.2.3.1 訪問 Log Search (Accessing Log Search)

   Log Search 安裝之后，可以利用如下三種方法搜索索引化的日志：

       ? Ambari Background Ops Log Search Link

       ? Host Detail Logs Tab

       ? Log Search UI

   9.2.3.1.1 Ambari 后臺操作日志搜索鏈接 (Ambari Background Ops Log Search Link)

   當執行生命周期操作時，例如啟動或停止服務，訪問日志可以有助于從潛在的失敗中恢復，這是非常重要的，這些日志在 Background Ops 中現在是可用的，

   Background Ops 也鏈接到 Host Detail Logs tab, 列出所有的索引化的日志檔案，并可以在一個主機上查看，

   9.2.3.1.2 Ambari 后臺操作日志搜索鏈接 (Ambari Background Ops Log Search Link)

   Logs tab 頁添加到每一個主機的 host detail 頁面，包含一個索引的串列，可查看的日志檔案，通過 service, component,  type 組織，可以通過一個

   到 Log Search UI 的鏈接打開并搜索這些檔案，

   9.2.3.1.3 Log Search UI

   Log Search UI 是一個特定目的構建的 web 應用程式用于搜索 HDP 組件日志，這個 UI 專注于快速訪問和從一個單點位置搜索日志，日志可以由日志級別，

   組件，以及可以搜索的關鍵字過濾，

   Log Search UI 可以從 Ambari Web 的 Log Search Service 的 Quick Links 訪問，

   9.2.3.2 利用 Log Search 進行故障處理(Using Log Search to Troubleshoot)

   要查找特定問題關聯的日志，在 UI 中使用 Troubleshooting 選項卡，選擇與該問題關聯的服務，組件，以及時間，例如，選擇 HDFS, UI  自動搜索 HDFS

   相關的組件，可以選擇一個昨天或上周的時間幀，或一個自定義的值，當準備好查看匹配的日志時，單擊 Go to Logs:

   9.2.3.3 查看服務日志 (Viewing Service Logs)

   Service Logs tab 可用于搜索橫跨所有組件日志，通過關鍵字或特定日志級別的過濾器，組件，以及時間區間，UI 經過組織，可以快速看到每個級別日志

   有多少日志捕捉到，查找關鍵字，包括排除的組件，匹配查詢的日志，

   9.2.3.4 查看訪問日志 (Viewing Access Logs)

   當要處理 HDFS 相關的問題時，可以發現搜索 HDFS 用戶訪問趨勢很有幫助，Access Logs tab 可以查看 HDFS 審計日志，聚集資料使用顯示 top ten HDFS

   用戶，以及 top ten  檔案系統資源訪問，這能幫助找到例外現象，或熱點和冷點資料集，

   9.3 Ambari Infra

   HDP 中很多服務依賴于核心服務來索引資料，例如，Apache Atlas 利用索引服務進行 lineage-free 文本搜索，Apache Ranger 對審計資料進行索引，

   Ambari Infra 的角色是為安裝堆疊上組件提供公共索引服務，

   當前， Ambari Infra Service 只有一個組件：Infra Solr Instance. Infra Solr Instance 是一個完全托管的 Apache Solr 安裝，默認情況下，Ambari

   Infra Service 在選擇安裝時，部署一個單節點的 SolrCloud 安裝，但可以安裝多個 Infra Solr Instances , 這樣就可以有一個分布式索引并為 Atlas,

   Ranger, and LogSearch 提供搜索，

   要安裝多個 Infra Solr Instances, 可以簡單地通過 Ambari 的 +Add Service 功能把它們添加到現有的集群主機上，部署的 Infra Solr Instances 的數量

   取決于集群的節點數量和部署的服務，

    

   因為一個 Ambari Infra Solr Instance 用于多個 HDP 組件，因此在重啟服務時要小心，避免擾亂這些依賴的服務， HDP 2.5 及以后版本，Atlas, Ranger,

   and Log Search 依賴于 Ambari Infra Solr Instance ，

       Note：

           Infra Solr Instance 是僅為 HDP 組件使用的，不支持第三方組件或應用程式，

   9.3.1 存檔和清理資料 (Archiving & Purging Data)

   大型集群會產生很多的日志內容，Ambari Infra 提供了一個便利工具用于存檔和清理不再需要的日志，

   工具成為 Solr Data Manager. Solr Data Manager 是一個 python 程式，安裝路徑為 /usr/bin/infra-solr-data-manager ，此程式使用戶可以快速存檔，

   洗掉，或保存 Solr 集合的資料，

   9.3.1.1 命令列選項 (Command Line Options)

    ● 操作模式(Operation Modes)

       -m MODE, --mode=MODE archive | delete | save

       使用的模式取決于要執行的操作：

       archive    : 用于將資料存盤到存盤媒體，并在存盤完成之后洗掉資料

       delete    : 即洗掉

       save    : 類似于 archive, 除了資料保存后不會被洗掉

       ● 連接到 Solr(Connecting to Solr)

       -s SOLR_URL, --solr-url=<SOLR_URL>

       URL 用于連接到特定的 Solr Cloud 實體

       例如，http://c6401.ambari.apache.org:8886/solr

       ● -c COLLECTION, --collection=COLLECTION

       Solr 集合(collection) 的名稱，如，'hadoop_logs'

       ● -k SOLR_KEYTAB,--solr-keytab=SOLR_KEYTAB   

       使用的 keytab 檔案，用于 kerberized Solr 實體

       ● -n SOLR_PRINCIPAL, --solr-principal=SOLR_PRINCIPAL   

       使用的 principal 名稱，用于 kerberized Solr 實體

       ● Record Schema

       -i ID_FIELD, --id-field=ID_FIELD    

       solr schema 中欄位名稱，用于唯一標識每條記錄

       -f FILTER_FIELD, --filter-field=FILTER_FIELD

       solr schema 中用于過濾掉的欄位名稱，如，'logtime'

       -o DATE_FORMAT, --date-format=DATE_FORMAT

       The custom date format to use with the -d DAYS field to match log entries that are older than a certain number of days.

       -e END

       Based on the filter field and date format, this argument configures the date that should be used as the end of the date range. If you

       use '2018-08-29T12:00:00.000Z', then any records with a filter field that is after that date will be saved, deleted, or archived

       depending on the mode.

    

    

       -d DAYS, --days=DAYS

       Based on the filter field and date format, this argument configures the number days before today should be used as the end of the range.

       If you use '30', then any records with a filter field that is older than 30 days will be saved, deleted, or archived depending on the mode.

       -q ADDITIONAL_FILTER, --additional-filter=ADDITIONAL_FILTER

       Any additional filter criteria to use to match records in the collection

       ● Extracting Records

       -r READ_BLOCK_SIZE, --read-block-size=READ_BLOCK_SIZE    

       The number of records to read at a time from Solr. For example: '10' to read 10 records at a time.

       -w WRITE_BLOCK_SIZE, --write-block-size=WRITE_BLOCK_SIZE

       The number of records to write per output file. For example: '100' to write 100 records per file.

       -j NAME, --name=NAME name included in result files

       Additional name to add to the final filename created in save or archive mode.

       --json-file

       Default output format is one valid json document per record delimited by a newline. This option will write out a single valid JSON

       document containing all of the records.

       -z COMPRESSION, --compression=COMPRESSION none | tar.gz | tar.bz2 | zip | gz

       Depending on how output files will be analyzed, you have the choice to choose the optimal compression and file format to use for output

       files. Gzip compression is used by default.

       ● Writing Data to HDFS

       -a HDFS_KEYTAB, --hdfs-keytab=HDFS_KEYTAB

       The keytab file to use when writing data to a kerberized HDFS instance.

       -l HDFS_PRINCIPAL, --hdfs-principal=HDFS_PRINCIPAL

       The principal name to use when writing data to a kerberized HDFS instance

       -u HDFS_USER, --hdfs-user=HDFS_USER

       The user to connect to HDFS as

       -p HDFS_PATH, --hdfs-path=HDFS_PATH

       The path in HDFS to write data to in save or archive mode.

       ● Writing Data to S3

       -t KEY_FILE_PATH, --key-file-path=KEY_FILE_PATH

       The path to the file on the local file system that contains the AWS Access and Secret Keys. The file should contain the keys in this

       format: <accessKey>,<secretKey>

       -b BUCKET, --bucket=BUCKET

       The name of the bucket that data should be uploaded to in save or archive mode.

       -y KEY_PREFIX, --key-prefix=KEY_PREFIX

       The key prefix allows you to create a logical grouping of the objects in an S3 bucket. The prefix value is similar to a directory name

       enabling you to store data in the same directory in a bucket. For example, if your Amazon S3 bucket name is logs, and you set prefix

       to hadoop/, and the file on your storage device is hadoop_logs_-_2017-10-28T01_25_40.693Z.json.gz, then the file would be identified

       by this URL: http://s3.amazonaws.com/logs/hadoop/hadoop_logs_-_2017-10-28T01_25_40.693Z.json.gz

       -g, --ignore-unfinished-uploading

       To deal with connectivity issues, uploading extracted data can be retried. If you do not wish to resume uploads, use the -g flag to

       disable this behaviour.

       ● Writing Data Locally  

       -x LOCAL_PATH, --local-path=LOCAL_PATH

       The path on the local file system that should be used to write data to in save or archive mode

       ● 示例

       □ 洗掉索引的資料 (Deleting Indexed Data)：

       delete 模式 (-m delete), 程式從 Solr collection 中洗掉資料，這個模式利用過濾器欄位(-f FITLER_FIELD) 選項來控制哪些資料從索引中洗掉，

       下面的命令會從 hadoop_logs collection 中洗掉日志項，August 29, 2017 以前創建的，使用 -f 選項指定的 Solr collection 欄位作為過濾器欄位，

       -e 選項標識要洗掉的區間結尾

       infra-solr-data-manager -m delete -s ://c6401.ambari.apache.org:8886/solr -c hadoop_logs -f logtime -e 2017-08-29T12:00:00.000Z

       □ 存檔索引資料 (Archiving Indexed Data)

       archive 模式，程式從 Solr collection 中獲取資料并寫出到 HDFS 或 S3, 然后洗掉資料，

       程式會從 Solr 抓取資料并在達到寫入塊大小，或 Solr 中沒有匹配的資料時創建檔案，程式跟蹤抓取記錄的進度，由過濾欄位和 id 欄位排序，并且

       總是會保存它們最后的值，一旦檔案寫入，利用配置的壓縮型別對其進行壓縮，

       壓縮的檔案創建之后，程式創建一個命令檔案包含下一步的指導，在下一步操作期間遇到任何中斷或錯誤，程式會啟動保存的命令檔案，因此所有資料會

       是一致的，如果無效的配置導致錯誤，一致性失敗， -g 選項可用于忽略保存的命令檔案，程式支持將資料寫入到 HDFS, S3, 或本地檔案，

       下面的命令會從 http://c6401.ambari.apache.org:8886/solr 訪問 solr collection hadoop_logs, 基于欄位的 logtime, 并抽取出每過 1 天，一次

       讀取 10 個檔案，寫出 100 個檔案到一個檔案，并復制這些 zip 檔案到本地 /tmp 目錄，

       infra-solr-data-manager -m archive -s http://c6401.ambari.apache.org:8886/solr -c hadoop_logs -f logtime -d 1 -r 10 -w 100 -x /tmp -v

       □ 保存索引資料 (Saving Indexed Data)

       保存資料類似于存檔資料，除了檔案創建和上傳之后不會被洗掉之外，建議在運行存檔模式之前使用 save 模式測驗，資料按預期的方式寫入，

       一下命令會存盤最后 3 天的 HDFS 審計日志到 HDFS 路徑 "/" hdfs 用戶，從 kerberized Solr 抓取資料，

       infra-solr-data-manager -m save -s http://c6401.ambari.apache.org:8886/solr -c audit_logs -f logtime -d 3 -r 10 -w 100

       -q type:\"hdfs_audit\" -j hdfs_audit -k /etc/security/keytabs/ambari-infra-solr.service.keytab -n

       infra-solr/[email protected] -u hdfs -p /

   9.3.2 Ambari Infra 性能調優 (Performance Tuning for Ambari Infra)

   利用 Ambari Infra 索引和存盤 Ranger 審計日志時，應正確調整 Solr 來處理每日的審計日志存盤的數量，下面幾節描述調整作業系統和 Solr 的建議，

   基于在環境中如何利用 Ambari Infra 和 Ranger

   9.3.2.1 作業系統調優 (Operating System Tuning)

   Solr 在建立索引和搜索時需要使用很多的網路連接，為了避免打開過多的網路連接，建議如下 sysctl 引數：

       net.ipv4.tcp_max_tw_buckets = 1440000

       net.ipv4.tcp_tw_recycle = 1

       net.ipv4.tcp_tw_reuse = 1

   這些設定可以永久性設定在 /etc/sysctl.d/net.conf 檔案中，或者運行時使用如下 sysctl 命令設定：

       sysctl -w net.ipv4.tcp_max_tw_buckets=1440000

       sysctl -w net.ipv4.tcp_tw_recycle=1

       sysctl -w net.ipv4.tcp_tw_reuse=1

   另外，應該提升 solr 的用戶行程數量以避免創建純新執行緒例外，這可以通過創建一個名稱為 etc/security/limits.d/infra-solr.conf 新檔案實作，其中

   包含如下內容：

       infra-solr - nproc 6000

   9.3.2.2 設定 JVM - GC (JVM - GC Settings)

   堆大小和垃圾回收設定對于生成環境索引很多的 Ranger 審計日志的 Solr 實體非常重要，對于生產環境的部署，建議設定 "Infra Solr Minimum Heap Size,"

   和 "Infra Solr Maximum Heap Size" 為 12 GB. 這些設定可以通過如下步驟實作：

       ① 在 Ambari Web 中，瀏覽到 Services > Ambari Infra > Configs

       ② 在 Settings tab, 可以看到有兩個滑動條控制 Infra Solr Heap Size

       ③ 設定 Infra Solr Minimum Heap Size 為 12GB 或 12,288MB

       ④ 設定 Infra Solr Maximum Heap Size 為 12GB 或 12,288MB

       ⑤ 單擊 Save 保存配置，然后按照 Ambari 提示重啟相關服務，

       在生產環境部署中使用 G1 作為垃圾回識訓制也是推薦的設定，要為 Ambari Infra Solr 實體設定 G1 垃圾回收，通過如下步驟實作：

       ① 在 Ambari Web 中，瀏覽到 Services > Ambari Infra > Configs

       ② 在 Advanced tab 展開 Advanced infra-solr-env

       ③ 在 infra-solr-env template 定位到多路 GC_TUNE 環境變數定義，以如下內容替換：

           GC_TUNE="-XX:+UseG1GC

               -XX:+PerfDisableSharedMem

               -XX:+ParallelRefProcEnabled

               -XX:G1HeapRegionSize=4m

               -XX:MaxGCPauseMillis=250

               -XX:InitiatingHeapOccupancyPercent=75

               -XX:+UseLargePages

               -XX:+AggressiveOpts"

       用于 -XX:G1HeapRegionSize 的值是基于 12GB Solr Maximum Heap Size. 如果為 Solr 選擇使用不同的堆大小, 參考下表建議：

         

               +-----------------------+---------------------------+

               | Heap Size                |    G1HeapRegionSize        |

               +-----------------------+---------------------------+

               | < 4GB                    | 1MB                        |

               +-----------------------+---------------------------+

               | 4-8GB                    | 2MB                        |

               +-----------------------+---------------------------+

               | 8-16GB                | 4MB                        |

               +-----------------------+---------------------------+

               | 16-32GB                | 8MB                        |

               +-----------------------+---------------------------+

               | 32-64GB                | 16MB                        |

               +-----------------------+---------------------------+

               | >64GB                    | 32MB                        |

               +-----------------------+---------------------------+

   9.3.2.3 環境特定的調節引數 (Environment-Specific Tuning Parameters)

   下面的每個建議都依賴于每日索引的審計記錄的數量，快速確定每日建立索引的審計記錄數量，利用如下命令：

   使用一個 HTTP client 例如 curl, 執行下列命令：

    

       curl -g "http://<ambari infra hostname>:8886/solr/ranger_audits/select?q=(evtTime:[NOW-7DAYS+TO+*])&wt=json&indent=true&rows=0"

    

   會收到類似如下的訊息：

    

       {

           "responseHeader":{

           "status":0,

           "QTime":1,

           "params":{

           "q":"evtTime:[NOW-7DAYS TO *]",

           "indent":"true",

           "rows":"0",

           "wt":"json"}},

           "response":{"numFound":306,"start":0,"docs":[]

       }}

       利用 response 的 numFound 元素值除以 7 獲得每天索引的審計日志數量，如果必要，也可以替換 curl 請求中的 '7DAYS' 為一個更寬泛的時間區間，

       可以使用下列關鍵字：

           ? 1MONTHS

           ? 7DAYS

    

       如果改變查詢的時間區間，確保除以合適的數值，每日的平均記錄數用于識別如下建議的應用環境，

       ● Less Than 50 Million Audit Records Per Day   

       基于 Solr REST API 呼叫，如果平均每日記錄數少于 50 million, 應用如下建議，在每個建議中，time to live, or TTL 控制一個檔案被保持在索引

       中多長時間被移除需要考慮進去，默認 TTL 為 90 days, 但有些用戶選擇更激進些，從索引移除檔案定為 30 days. 由于這個原因，對這兩種 TTL 設定

       提供建議，

       這些建議假設使用我們推薦的每個 Solr server 實體使用 12GB 堆大小，

       Default Time To Live (TTL) 90 days:

       ? Estimated total index size: ~150 GB to 450 GB

       ? Total number of primary/leader shards: 6

       ? Total number of shards including 1 replica each: 12

       ? Total number of co-located Solr nodes: ~3 nodes, up to 2 shards per node(does not include replicas)

       ? Total number of dedicated Solr nodes: ~1 node, up to 12 shards per node(does not include replicas)

       ● 50 - 100 Million Audit Records Per Day

       50 to 100 million records ~ 5 - 10 GB data per day.

       Default Time To Live (TTL) 90 days:

       ? Estimated total index size: ~ 450 - 900 GB for 90 days

       ? Total number of primary/leader shards: 18-36

       ? Total number of shards including 1 replica each: 36-72

       ? Total number of co-located Solr nodes: ~9-18 nodes, up to 2 shards per node(does not include replicas)

       ? Total number of dedicated Solr nodes: ~3-6 nodes, up    to 12 shards per node(does not include replicas)

       Custom Time To Live (TTL) 30 days:

       ? Estimated total index size: 150 - 300 GB for 30 days

       ? Total number of primary/leader shards: 6-12

       ? Total number of shards including 1 replica each: 12-24

       ? Total number of co-located Solr nodes: ~3-6 nodes, up to 2 shards per node(does not include replicas)

       ? Total number of dedicated Solr nodes: ~1-2 nodes, up to 12 shards per node(does not include replicas)

       ● 100 - 200 Million Audit Records Per Day

       100 to 200 million records ~ 10 - 20 GB data per day.

       Default Time To Live (TTL) 90 days:

       ? Estimated total index size: ~ 900 - 1800 GB for 90  days

       ? Total number of primary/leader shards: 36-72

       ? Total number of shards including 1 replica each:    72-144

       ? Total number of co-located Solr nodes: ~18-36 nodes, up to 2 shards per node(does not include replicas)

       ? Total number of dedicated Solr nodes: ~3-6 nodes, up to 12 shards per node (does not include replicas)

       Custom Time To Live (TTL) 30 days:

       ? Estimated total index size: 300 - 600 GB for 30 days

       ? Total number of primary/leader shards: 12-24

       ? Total number of shards including 1 replica each: 24-48

       ? Total number of co-located Solr nodes: ~6-12 nodes, up to 2 shards per node(does not include replicas)

       ? Total number of dedicated Solr nodes: ~1-3 nodes, up to 12 shards per node(does not include replicas)

   如果選擇使用至少 1 個副本來提供可用性，提升節點數量，如果要求高可用性，考慮配置中使用不小于 3 的 Solr 節點，

   如例子中演示的，較低的 TTL 要求較少的資源，如果要長期保留資料，可以利用 SolrDataManager 將資料存檔到長期存盤系統(HDFS, S3), 并提供 Hive 表以

   提供容易的資料查詢，這種策略下，熱點資料可以存盤在 Solr 中以提供 Ranger UI 的快速訪問，不活躍的資料存檔到 HDFS 或 S3, 可以通過 Ranger 訪問，

   9.3.2.4 添加新的 Shards (Adding New Shards)

   如果查看以上建議之后，需要添加額外的 shards 到現有部署，參考如下 Solr 檔案幫助理解如何完成這一任務：

       https://archive.apache.org/dist/lucene/solr/ref-guide/apache-solr-ref-guide-5.5.pdf

   9.3.2.5 記憶體溢位例外 (Out of Memory Exceptions)

   當利用 Ambari Infra 和 Ranger Audit 一起使用時，如果看到很多 Solr 實體以 Java "Out Of Memory" 例外退出，一個解決方案是通過啟用 DocValues

   來升級 Ranger Audit schema 使用更少的堆記憶體，這樣修改要求重新對資料建立索引而且具有破壞性，但非常有助于處理記憶體消耗，參考文章：

       https://community.hortonworks.com/articles/156933/restore-backup-ranger-audits-to-newly-collection.html

    

   參考鏈接：Ambari 操作指南 (Ambari Operations)

   https://blog.csdn.net/devalone/article/details/80781652

   https://blog.csdn.net/devalone/article/details/80800262

   https://blog.csdn.net/devalone/article/details/80813176

   https://blog.csdn.net/devalone/article/details/80826036

   https://blog.csdn.net/devalone/article/details/80839371

   https://blog.csdn.net/devalone/article/details/80854431

標籤：其他

上一篇：10年前，我就用 SQL注入漏洞黑了學校網站

下一篇：php陳述句：MySQL指定磁區表跨磁區根據時間條件快速查詢記錄的封裝函式