一套很專業的監控方案：HDFS監控落地背後的思考
一、HDFS監控挑戰
-
HDFS是Hadoop生態的一部分，監控方案不僅需適用HDFS，其他元件如Yarn、Hbase、Hive等，也需適用
-
HDFS API提供的指標較多，部分指標沒必要實時採集，但故障時需能快速獲取到
-
Hadoop相關元件的日誌，比較重要，如問題定位、審計等
-
監控方案不僅能滿足監控本身，故障定位涉及指標也應覆蓋
二、Hadoop監控方案
Hadoop監控資料採集是通過HTTP API，或者JMX。實際中，用到比較多的產品主要有：CDH、Ambari，此外，還有部分工具，如Jmxtrans、HadoopExporter（用於Prometheus）。
CDH是一款開源的集部署、監控、操作等於一體的Hadoop生態元件管理工具，也提供收費版（比免費版多提供資料備份恢復、故障定位等特性）。CDH提供的HDFS監控介面在體驗上是非常優秀的，是對HDFS監控指標深入發掘之後的濃縮，比如HDFS容量、讀寫流量及耗時、Datanode磁碟重新整理耗時等。
圖1 CDH提供的HDFS監控介面
Ambari與CDH類似，同樣是開源工具，但它的擴充套件性要比較好，另外，它的資訊可以從機器、元件、叢集等不同維度展現，接近運維工程師使用習慣。
圖2 Ambari提供的HDFS監控介面
如果使用CDH，或者Ambari進行HDFS監控，也存在實際問題：
-
對應的Hadoop及相關元件版本不能自定義
-
不能很好的滿足大規模HDFS叢集實際監控需求
其他工具，如Jmxtrans目前還不能很好適配Hadoop，因此，實際的監控方案選型為：
-
採集：HadoopExporter，Hadoop HTTP API（說明：HDFS主要呼叫http://{domain}:{port}/jmx）
-
日誌：通過ELK來收集、分析
-
儲存：Prometheus
-
展現：Grafana，HDFS UI，Hue
-
告警：對接京東雲告警系統
三、HDFS監控指標
1、主要指標概覽
表1 HDFS主要監控指標概覽
2、黑盒監控指標
基本功能
檔案整個生命週期中，是否存在功能異常，主要監控建立、檢視、修改、刪除動作。
-
檢視時，需校對內容，有一種方式，可以在檔案中寫入時間戳，檢視時校對時間戳，這樣，可以根據時間差來判斷是否寫超時
-
切記保證生命週期完整，否則，大量監控產生的臨時檔案可能導致HDFS叢集垮掉
3、白盒監控指標
1）錯誤
Block丟失數量
採集項：MissingBlocks
如果出現塊丟失，則意味著檔案已經損壞，所以需要在塊丟失前，提前預判可能出現Block丟失風險（通過監控UnderReplicatedBlocks來判斷）。
不可用資料節點佔比
採集項：
在BlockPlacementPolicyDefault.java中的isGoodTarget定義了選取Datanode節點策略，其中有兩項是“節點是否在下線”、“是否有足夠儲存空間”，如果不可用數量過多，則可能導致選擇不到健康的Datanode，因此，必須保證一定數量的健康Datanode。
圖4 選取可用Datanode時部分判斷條件
錯誤日誌關鍵字監控
部分常見錯誤監控（主要監控Exception/ERROR），對應關鍵字：
IOException、NoRouteToHostException、SafeModeException、UnknownHostException。
未複製Block數
採集項：UnderReplicatedBlocks
UnderReplicatedBlocks在資料節點下線、資料節點故障等均會產生大量正在同步的塊數。
FGC監控
採集項：FGC
讀寫成功率
採集項：
monitor_write.status/monitor_read.status
根據Block實際讀寫流量匯聚計算，是對外SLA指標的重要依據。
資料盤故障
採集項：NumFailedVolumes
如果一個叢集有1000臺主機，每臺主機是12塊盤（一般儲存型機器標準配置），那麼這將會是1萬2000塊資料盤，按照機械盤平均季度故障率1.65%（資料儲存服務商Backblaze統計）計算，平均每個月故障7塊盤。若叢集規模再擴大，那麼運維工程師將耗費很大精力在故障盤處理與服務恢復上。很顯然，一套自動化的資料盤故障檢測、自動報修、服務自動恢復機制成為剛需。
除故障盤監控外，故障資料盤要有全域性性解決方案。在實踐中，以場景為維度，通過自助化的方式來實現對此問題處理。
圖5 基於場景實現的Jenkins自助化任務
2）流量
Block讀、寫次數
採集項：
採集Datanode資料進行匯聚計算。
網路進出流量
採集項： node_network_receive_bytes_total/ node_network_transmit_bytes_total
沒有直接可以使用的現成資料，需要通過ReceivedBytes（接收位元組總量）、SentBytes（傳送位元組總量）來計算。
磁碟I/O
採集項： node_disk_written_bytes_total/ node_disk_read_bytes_total
3）延遲
RPC處理平均時間
採集項：RpcQueueTimeAvgTime
採集RpcQueueTimeAvgTime（RPC處理平均時間）、SyncsAvgTime（Journalnode同步耗時）。
慢節點數量
採集項：SlowPeerReports
慢節點主要特徵是，落到該節點上的讀、寫較平均值差距較大，但給他足夠時間，仍然能返回正確結果。通常導致慢節點出現的原因除機器硬體、網路外，對應節點上的負載較大是另一個主要原因。實際監控中，除監控節點上的讀寫耗時外，節點上的負載也需要重點監控。
根據實際需要，可以靈活調整Datanode彙報時間，或者開啟“陳舊節點”（Stale Node）檢測，以便Namenode準確識別故障例項。涉及部分配置項：
-
dfs.namenode.heartbeat.recheck-interval
-
dfs.heartbeat.interval
-
dfs.namenode.avoid.read.stale.datanode
-
dfs.namenode.avoid.write.stale.datanode
-
dfs.namenode.stale.datanode.interval
4）容量
叢集總空間、空間使用率
採集項：PercentUsed
HDFS UI花費了很大篇幅來展現儲存空間相關指標，足以說明它的重要性。
空間使用率計算包含了處於“下線中”節點空間，這是一個陷阱。如果有節點處於下線狀態，但它們代表的空間仍計算在總空間，如果下線節點過多，存在這樣“怪象”：叢集剩餘空間很多，但已無空間可寫。
此外，在Datanode空間規劃時，要預留一部分空間。HDFS預留空間有可能是其他程式使用，也有可能是檔案刪除後，但一直被引用，如果“Non DFS Used”一直增大，則需要追查具體原因並優化，可以通過如下引數來設定預留空間：
-
dfs.datanode.du.reserved.calculator
-
dfs.datanode.du.reserved
-
dfs.datanode.du.reserved.pct
作為HDFS運維開發人員，需清楚此公式：Configured Capacity = Total Disk Space - Reserved Space = Remaining Space + DFS Used + Non DFS Used。
Namenode堆記憶體使用率
採集項：
HeapMemoryUsage.used/HeapMemoryUsage.committed
如果將此指標作為HDFS核心指標，也是不為過的。元資料和Block對映關係佔據了Namenode大部分堆記憶體，這也是HDFS不適合儲存大量小檔案的原因之一。堆記憶體使用過大，可能會出現Namenode啟動慢，潛在FGC風險，因此，堆記憶體使用情況需重點監控。
實際中，堆記憶體使用率增加，不可避免，給出有效的幾個方案：
-
調整堆記憶體分配
-
建立檔案生命週期管理機制，及時清理部分無用檔案
-
小檔案合併
-
使用HDFS Federation橫向擴充套件
儘管這些措施可以在很長時間內，有效降低風險，但提前規劃好叢集也是很有必要。
資料均衡度
採集項：
HDFS而言，資料儲存均衡度，一定程度上決定了它的安全性。實際中，根據各儲存例項的空間使用率，來計算這組資料的標準差，用以反饋各例項之間的資料均衡程度。
資料較大情況下，如果進行資料均衡則會比較耗時，儘管通過調整併發度、速度也很難快速的完成資料均衡。針對這種情況，可以嘗試優先下線空間已耗盡的例項，之後再擴容的方式來實現均衡的目的。
還有一點需注意，在3.0版本之前，資料均衡只能是節點之間的均衡，不能實現節點內部不同資料盤的均衡。
RPC請求佇列的長度
採集項：CallQueueLength（RPC請求佇列長度）。
檔案數量
採集項：FilesTotal
與堆記憶體使用率配合使用。每個檔案系統物件（包括檔案、目錄、Block數量）至少佔有150位元組堆記憶體，根據此，可以粗略預估出一個Namenode可以儲存多少檔案。根據檔案與塊數量之間的關係，也可以對塊大小做一定優化。
下線例項數
採集項：NumDecommissioningDataNodes
HDFS叢集規模較大時，實時掌握健康例項說，定期修復故障節點並及時上線，可以為公司節省一定成本。
5）其他
除上述主要指標外，伺服器、程序JVM、依賴服務（Zookeeper、DNS）等通用監控策略也需新增。
四、HDFS監控落地
Grafana儀表盤展現： 主要用於服務巡檢、故障定位（說明：Grafana官方提供的HDFS監控模板，資料指標相對較少）。
圖6 HDFS部分叢集Grafana儀表盤
ELK-Hadoop： 主要用於全域性日誌檢索，以及錯誤日誌關鍵字監控。
圖7 ES中搜索HDFS叢集日誌
圖8 日誌服務搜尋HDFS叢集日誌
Hue、HDFS UI： 主要用於HDFS問題排查與日常維護。
五、HDFS案例
案例1
DNS產生髒資料，導致Namenode HA故障。
-
發現方式： 功能監控、SLA指標異常
-
故障原因： DNS伺服器產生髒資料，致使Namenode主機名出錯，在HA切換時，因找到錯誤主機而失敗
-
優化建議 ： DNS作為最基礎服務，務必保證其資料正確與穩定，在一定規模情況下，切忌使用修改/etc/hosts方式來解決主機名問題，如果沒有高可用的內部DNS服務，建議使用DNSMasq來搭建一套DNS伺服器
案例2
機架分組不合理，導致HDFS無法寫入。
-
發現方式： 功能監控寫異常偶發性告警
-
故障原因： HDFS開啟機架感知，不同分組機器資源分配不合理，部分分組儲存資源耗盡，在選擇Datanode時，找不到可用節點
-
優化建議： 合理分配各機架上的例項數量，並分組進行監控。在規模較小情況下，可用考慮關閉機架感知功能
附
HDFS監控自定義任務：