網站首頁 建站套餐 客戶案例 建站優勢 主機域名 關于黑羽 聯系黑羽

資訊中心
了解網站建設資訊引領網站建設開發方向
阿里技術架構內部總結: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磁盤刷新耗時等。

阿里技術架構負責人內部總結:HDFS監控落地的思考

CDH提供的HDFS監控界面

Ambari與CDH類似,同樣是開源工具,但它的擴展性要比較好,另外,它的信息可以從機器、組件、集群等不同維度展現,接近運維工程師使用習慣。

阿里技術架構負責人內部總結:HDFS監控落地的思考

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、主要指標概覽

阿里技術架構負責人內部總結:HDFS監控落地的思考

HDFS主要監控指標概覽

2、黑盒監控指標

基本功能

文件整個生命周期中,是否存在功能異常,主要監控創建、查看、修改、刪除動作。

查看時,需校對內容,有一種方式,可以在文件中寫入時間戳,查看時校對時間戳,這樣,可以根據時間差來判斷是否寫超時

切記保證生命周期完整,否則,大量監控產生的臨時文件可能導致HDFS集群垮掉

3、白盒監控指標

1)錯誤

Block丟失數量

采集項:MissingBlocks

如果出現塊丟失,則意味著文件已經損壞,所以需要在塊丟失前,提前預判可能出現Block丟失風險(通過監控UnderReplicatedBlocks來判斷)。

不可用數據節點占比

采集項:

阿里技術架構負責人內部總結:HDFS監控落地的思考

在BlockPlacementPolicyDefault.java中的isGoodTarget定義了選取Datanode節點策略,其中有兩項是“節點是否在下線”、“是否有足夠存儲空間”,如果不可用數量過多,則可能導致選擇不到健康的Datanode,因此,必須保證一定數量的健康Datanode。

阿里技術架構負責人內部總結:HDFS監控落地的思考

選取可用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塊盤。若集群規模再擴大,那么運維工程師將耗費很大精力在故障盤處理與服務恢復上。很顯然,一套自動化的數據盤故障檢測、自動報修、服務自動恢復機制成為剛需。

除故障盤監控外,故障數據盤要有全局性解決方案。在實踐中,以場景為維度,通過自助化的方式來實現對此問題處理。

阿里技術架構負責人內部總結:HDFS監控落地的思考

基于場景實現的Jenkins自助化任務

2)流量

Block讀、寫次數

采集項:

阿里技術架構負責人內部總結:HDFS監控落地的思考

采集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監控落地的思考

HDFS而言,數據存儲均衡度,一定程度上決定了它的安全性。實際中,根據各存儲實例的空間使用率,來計算這組數據的標準差,用以反饋各實例之間的數據均衡程度。

數據較大情況下,如果進行數據均衡則會比較耗時,盡管通過調整并發度、速度也很難快速的完成數據均衡。針對這種情況,可以嘗試優先下線空間已耗盡的實例,之后再擴容的方式來實現均衡的目的。

還有一點需注意,在3.0版本之前,數據均衡只能是節點之間的均衡,不能實現節點內部不同數據盤的均衡。

RPC請求隊列的長度

采集項:CallQueueLength(RPC請求隊列長度)。

文件數量

采集項:FilesTotal

與堆內存使用率配合使用。每個文件系統對象(包括文件、目錄、Block數量)至少占有150字節堆內存,根據此,可以粗略預估出一個Namenode可以保存多少文件。根據文件與塊數量之間的關系,也可以對塊大小做一定優化。

下線實例數

采集項:NumDecommissioningDataNodes

HDFS集群規模較大時,實時掌握健康實例說,定期修復故障節點并及時上線,可以為公司節省一定成本。

5)其他

除上述主要指標外,服務器、進程JVM、依賴服務(Zookeeper、DNS)等通用監控策略也需添加。

四、HDFS監控落地

Grafana儀表盤展現:主要用于服務巡檢、故障定位(說明:Grafana官方提供的HDFS監控模板,數據指標相對較少)。

阿里技術架構負責人內部總結:HDFS監控落地的思考

HDFS部分集群Grafana儀表盤

ELK-Hadoop:主要用于全局日志檢索,以及錯誤日志關鍵字監控。

阿里技術架構負責人內部總結:HDFS監控落地的思考

ES中搜索HDFS集群日志

阿里技術架構負責人內部總結:HDFS監控落地的思考

日志服務搜索HDFS集群日志

Hue、HDFS UI:主要用于HDFS問題排查與日常維護。

五、HDFS案例

案例1:

DNS產生臟數據,導致Namenode HA故障。

  • 發現方式:功能監控、SLA指標異常
  • 故障原因:DNS服務器產生臟數據,致使Namenode主機名出錯,在HA切換時,因找到錯誤主機而失敗
  • 優化建議:DNS作為最基礎服務,務必保證其數據正確與穩定,在一定規模情況下,切忌使用修改/etc/hosts方式來解決主機名問題,如果沒有高可用的內部DNS服務,建議使用DNSMasq來搭建一套DNS服務器

案例2:

機架分組不合理,導致HDFS無法寫入。

  • 發現方式:功能監控寫異常偶發性告警
  • 故障原因:HDFS開啟機架感知,不同分組機器資源分配不合理,部分分組存儲資源耗盡,在選擇Datanode時,找不到可用節點
  • 優化建議:合理分配各機架上的實例數量,并分組進行監控。在規模較小情況下,可用考慮關閉機架感知功能
網頁制作的服務
網站開發服務
自貢黑羽網絡品牌建站
自貢本地做網站就選黑羽網絡
Tel:0813-5104030 15348110304 QQ或微信:22232591
地址:四川省自貢市自流井區丹佳大街泰豐大廈寫字樓19樓10號
Copyright © 2018-2058 自貢黑羽網絡科技有限公司 All rights reserved. ICP備案號 : ICP備12014994號-1 技術支持:黑羽網絡
自貢網站建設,網頁設計制作與開發,自貢網絡公司推薦品牌,關鍵詞: 自貢網站制作 自貢做網站 自貢網絡公司 自貢網頁制作 自貢做網站 網站地圖xml 網站地圖html 網站地圖txt
中国竞彩网计算机