基于京東云的實戰經驗，我們今天來聊聊HDFS相關的監控。

Hadoop分布式文件系統(HDFS)被設計成適合運行在通用硬件(commodity hardware)上的分布式文件系統。

HDFS能提供高吞吐量的數據訪問，非常適合大規模數據集上的應用。在大數據生態圈中，HDFS是最重要的底層分布式文件系統，它的穩定性關乎整個生態系統的健康。

本文介紹了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監控自定義任務：

https://github.com/cloud-op/monitor