Ambari 學習指南
做用： html
Hadoop 是用在商業主機網絡集羣上的大規模、分佈式的數據存儲和處理基礎架構。監控和管理如此複雜的分佈式系統是不簡單的。爲了管理這種複雜性， node
Apache Ambari 從集羣節點和服務收集了大量的信息，並把它們表現爲容易使用的，集中化的接口：Ambari Web python
功能： web
顯示諸如服務特定的摘要、圖表以及警報信息 shell
建立和管理 HDP 集羣並執行基本的操做任務，例如啓動和中止服務，向集羣 數據庫
中添加主機，以及更新服務配置 apache
執行集羣管理任務，例如啓用 Kerberos 安全以及執行 Stack 升級 json
使用： bootstrap
-
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：配置歷史
-
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
-
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 以外的腳本管理機架映射信息了。
-
管理服務 (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/c6401.ambari.apache.org@AMBARI.APACHE.ORG -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)
http://www.javashuo.com/article/p-ozzgawxh-dr.html
http://www.javashuo.com/article/p-fwsvonku-ee.html
https://blog.csdn.net/devalone/article/details/80813176
http://www.javashuo.com/article/p-ftbbclov-kk.html
- 1. Ambari 操做指南 (Ambari Operations) 之一
- 2. Ambari 操做指南 (Ambari Operations) 之二
- 3. Ambari 操做指南 (Ambari Operations) 之四
- 4. Ambari 操做指南 (Ambari Operations) 之六
- 5. 學習指南
- 6. MangoDB 學習指南
- 7. Mqtt學習指南
- 8. Spring學習指南
- 9. redis 學習指南
- 10. BERT學習指南
- 更多相關文章...
- • SQL 指南 - 網站建設指南
- • HTML 指南 - 網站建設指南
- • Tomcat學習筆記（史上最全tomcat學習筆記）
- • 適用於PHP初學者的學習線路和建議
-
每一个你不满意的现在，都有一个你没有努力的曾经。