HDFS監(jiān)控挑戰(zhàn)

• HDFS是Hadoop生態(tài)的一部分，監(jiān)控方案不僅需適用HDFS，其他組件如Yarn、Hbase、Hive等，也需適用
• HDFS API提供的指標(biāo)較多，部分指標(biāo)沒(méi)必要實(shí)時(shí)采集，但故障時(shí)需能快速獲取到
• Hadoop相關(guān)組件的日志，比較重要，如問(wèn)題定位、審計(jì)等
• 監(jiān)控方案不僅能滿足監(jiān)控本身，故障定位涉及指標(biāo)也應(yīng)覆蓋

Hadoop監(jiān)控方案

Hadoop監(jiān)控?cái)?shù)據(jù)采集通過(guò)HTTP API，或者JMX。實(shí)際中，用到比較多的產(chǎn)品主要有：CDH、Ambari，此外，還有部分工具，如Jmxtrans、HadoopExporter(用于Prometheus)。

CDH為Cloudera公司開(kāi)源的一款集部署、監(jiān)控、操作等于一體的Hadoop生態(tài)組件管理工具，也提供收費(fèi)版(比免費(fèi)版多提供數(shù)據(jù)備份恢復(fù)、故障定位等特性)。CDH提供的HDFS監(jiān)控界面在體驗(yàn)上是非常優(yōu)秀的，是對(duì)HDFS監(jiān)控指標(biāo)深入發(fā)掘之后的濃縮，比如HDFS容量、讀寫(xiě)流量及耗時(shí)、Datanode磁盤(pán)刷新耗時(shí)等。

 

圖1 CDH提供的HDFS監(jiān)控界面

Ambari與CDH類似，它是Hortonworks公司(與Cloudera公司已合并)開(kāi)源。它的擴(kuò)展性要比較好，另外，它的信息可以從機(jī)器、組件、集群等不同維度展現(xiàn)，接近運(yùn)維工程師使用習(xí)慣。

 

圖2 Ambari提供的HDFS監(jiān)控界面

如果使用CDH，或者Ambari進(jìn)行HDFS監(jiān)控，也存在實(shí)際問(wèn)題：

• 對(duì)應(yīng)的Hadoop及相關(guān)組件版本不能自定義
• 不能很好的滿足大規(guī)模HDFS集群實(shí)際監(jiān)控需求

其他工具，如Jmxtrans目前還不能很好適配Hadoop，因此，實(shí)際的監(jiān)控方案選型為：

• 采集：HadoopExporter，Hadoop HTTP API(說(shuō)明：HDFS主要調(diào)用http://{domain}:{port}/jmx)
• 日志：通過(guò)ELK來(lái)收集、分析
• 存儲(chǔ)：Prometheus
• 展現(xiàn)：Grafana，HDFS UI，Hue
• 告警：對(duì)接京東云告警系統(tǒng)

HDFS監(jiān)控指標(biāo)

主要指標(biāo)概覽

表1 HDFS主要監(jiān)控指標(biāo)概覽

 

黑盒監(jiān)控指標(biāo)

基本功能

文件整個(gè)生命周期中，是否存在功能異常，主要監(jiān)控創(chuàng)建、查看、修改、刪除動(dòng)作。

• 查看時(shí)，需校對(duì)內(nèi)容，有一種方式，可以在文件中寫(xiě)入時(shí)間戳，查看時(shí)校對(duì)時(shí)間戳，這樣，可以根據(jù)時(shí)間差來(lái)判斷是否寫(xiě)超時(shí)
• 切記保證生命周期完整，否則，大量監(jiān)控產(chǎn)生的臨時(shí)文件可能導(dǎo)致HDFS集群垮掉

白盒監(jiān)控指標(biāo)

錯(cuò)誤

Block丟失數(shù)量

采集項(xiàng)：MissingBlocks

如果出現(xiàn)塊丟失，則意味著文件已經(jīng)損壞，所以需要在塊丟失前，提前預(yù)判可能出現(xiàn)Block丟失風(fēng)險(xiǎn)(通過(guò)監(jiān)控UnderReplicatedBlocks來(lái)判斷)。

不可用數(shù)據(jù)節(jié)點(diǎn)占比

采集項(xiàng)：

 

在BlockPlacementPolicyDefault.java中的isGoodTarget定義了選取Datanode節(jié)點(diǎn)策略，其中有兩項(xiàng)是“節(jié)點(diǎn)是否在下線”、“是否有足夠存儲(chǔ)空間”，如果不可用數(shù)量過(guò)多，則可能導(dǎo)致選擇不到健康的Datanode，因此，必須保證一定數(shù)量的健康Datanode。

 

圖4 選取可用Datanode時(shí)部分判斷條件

錯(cuò)誤日志關(guān)鍵字監(jiān)控

部分常見(jiàn)錯(cuò)誤監(jiān)控(主要監(jiān)控Exception/ERROR)，對(duì)應(yīng)關(guān)鍵字：

IOException、NoRouteToHostException、SafeModeException、UnknownHostException。

未復(fù)制Block數(shù)

采集項(xiàng)：UnderReplicatedBlocks

UnderReplicatedBlocks在數(shù)據(jù)節(jié)點(diǎn)下線、數(shù)據(jù)節(jié)點(diǎn)故障等均會(huì)產(chǎn)生大量正在同步的塊數(shù)。

FGC監(jiān)控

采集項(xiàng)：FGC

讀寫(xiě)成功率

采集項(xiàng)：

monitor_write.status/monitor_read.status

根據(jù)Block實(shí)際讀寫(xiě)流量匯聚計(jì)算，是對(duì)外SLA指標(biāo)的重要依據(jù)。

數(shù)據(jù)盤(pán)故障

采集項(xiàng)：NumFailedVolumes

如果一個(gè)集群有1000臺(tái)主機(jī)，每臺(tái)主機(jī)是12塊盤(pán)(一般存儲(chǔ)型機(jī)器標(biāo)準(zhǔn)配置)，那么這將會(huì)是1萬(wàn)2000塊數(shù)據(jù)盤(pán)，按照機(jī)械盤(pán)平均季度故障率1.65%(數(shù)據(jù)存儲(chǔ)服務(wù)商Backblaze統(tǒng)計(jì))計(jì)算，平均每個(gè)月故障7塊盤(pán)。若集群規(guī)模再擴(kuò)大，那么運(yùn)維工程師將耗費(fèi)很大精力在故障盤(pán)處理與服務(wù)恢復(fù)上。很顯然，一套自動(dòng)化的數(shù)據(jù)盤(pán)故障檢測(cè)、自動(dòng)報(bào)修、服務(wù)自動(dòng)恢復(fù)機(jī)制成為剛需。

除故障盤(pán)監(jiān)控外，故障數(shù)據(jù)盤(pán)要有全局性解決方案。在實(shí)踐中，以場(chǎng)景為維度，通過(guò)自助化的方式來(lái)實(shí)現(xiàn)對(duì)此問(wèn)題處理。

 

圖5 基于場(chǎng)景實(shí)現(xiàn)的Jenkins自助化任務(wù)

流量

Block讀、寫(xiě)次數(shù)

采集項(xiàng)：

 

采集Datanode數(shù)據(jù)進(jìn)行匯聚計(jì)算。

網(wǎng)絡(luò)進(jìn)出流量

采集項(xiàng)：

node_network_receive_bytes_total/ node_network_transmit_bytes_total 

沒(méi)有直接可以使用的現(xiàn)成數(shù)據(jù)，需要通過(guò)ReceivedBytes(接收字節(jié)總量)、SentBytes(發(fā)送字節(jié)總量)來(lái)計(jì)算。

磁盤(pán)I/O

采集項(xiàng)：node_disk_written_bytes_total/ node_disk_read_bytes_total

延遲

RPC處理平均時(shí)間

采集項(xiàng)：RpcQueueTimeAvgTime

采集RpcQueueTimeAvgTime(RPC處理平均時(shí)間)、SyncsAvgTime(Journalnode同步耗時(shí))。

慢節(jié)點(diǎn)數(shù)量

采集項(xiàng)：SlowPeerReports

慢節(jié)點(diǎn)主要特征是，落到該節(jié)點(diǎn)上的讀、寫(xiě)較平均值差距較大，但給他足夠時(shí)間，仍然能返回正確結(jié)果。通常導(dǎo)致慢節(jié)點(diǎn)出現(xiàn)的原因除機(jī)器硬件、網(wǎng)絡(luò)外，對(duì)應(yīng)節(jié)點(diǎn)上的負(fù)載較大是另一個(gè)主要原因。實(shí)際監(jiān)控中，除監(jiān)控節(jié)點(diǎn)上的讀寫(xiě)耗時(shí)外，節(jié)點(diǎn)上的負(fù)載也需要重點(diǎn)監(jiān)控。

根據(jù)實(shí)際需要，可以靈活調(diào)整Datanode匯報(bào)時(shí)間，或者開(kāi)啟“陳舊節(jié)點(diǎn)”(Stale Node)檢測(cè)，以便Namenode準(zhǔn)確識(shí)別故障實(shí)例。涉及部分配置項(xiàng)：

• 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

容量

集群總空間、空間使用率

采集項(xiàng)：PercentUsed

HDFS UI花費(fèi)了很大篇幅來(lái)展現(xiàn)存儲(chǔ)空間相關(guān)指標(biāo)，足以說(shuō)明它的重要性。

空間使用率計(jì)算包含了處于“下線中”節(jié)點(diǎn)空間，這是一個(gè)陷阱。如果有節(jié)點(diǎn)處于下線狀態(tài)，但它們代表的空間仍計(jì)算在總空間，如果下線節(jié)點(diǎn)過(guò)多，存在這樣“怪象”：集群剩余空間很多，但已無(wú)空間可寫(xiě)。

此外，在Datanode空間規(guī)劃時(shí)，要預(yù)留一部分空間。HDFS預(yù)留空間有可能是其他程序使用，也有可能是文件刪除后，但一直被引用，如果“Non DFS Used”一直增大，則需要追查具體原因并優(yōu)化，可以通過(guò)如下參數(shù)來(lái)設(shè)置預(yù)留空間：

• dfs.datanode.du.reserved.calculator
• dfs.datanode.du.reserved
• dfs.datanode.du.reserved.pct

作為HDFS運(yùn)維開(kāi)發(fā)人員，需清楚此公式：Configured Capacity = Total Disk Space - Reserved Space = Remaining Space + DFS Used + Non DFS Used。

Namenode堆內(nèi)存使用率

采集項(xiàng)：

HeapMemoryUsage.used/HeapMemoryUsage.committed 

如果將此指標(biāo)作為HDFS核心指標(biāo)，也是不為過(guò)的。元數(shù)據(jù)和Block映射關(guān)系占據(jù)了Namenode大部分堆內(nèi)存，這也是HDFS不適合存儲(chǔ)大量小文件的原因之一。堆內(nèi)存使用過(guò)大，可能會(huì)出現(xiàn)Namenode啟動(dòng)慢，潛在FGC風(fēng)險(xiǎn)，因此，堆內(nèi)存使用情況需重點(diǎn)監(jiān)控。

實(shí)際中，堆內(nèi)存使用率增加，不可避免，給出有效的幾個(gè)方案：

• 調(diào)整堆內(nèi)存分配
• 建立文件生命周期管理機(jī)制，及時(shí)清理部分無(wú)用文件
• 小文件合并
• 使用HDFS Federation橫向擴(kuò)展

盡管這些措施可以在很長(zhǎng)時(shí)間內(nèi)，有效降低風(fēng)險(xiǎn)，但提前規(guī)劃好集群也是很有必要。

數(shù)據(jù)均衡度

采集項(xiàng)：

 

HDFS而言，數(shù)據(jù)存儲(chǔ)均衡度，一定程度上決定了它的安全性。實(shí)際中，根據(jù)各存儲(chǔ)實(shí)例的空間使用率，來(lái)計(jì)算這組數(shù)據(jù)的標(biāo)準(zhǔn)差，用以反饋各實(shí)例之間的數(shù)據(jù)均衡程度。數(shù)據(jù)較大情況下，如果進(jìn)行數(shù)據(jù)均衡則會(huì)比較耗時(shí)，盡管通過(guò)調(diào)整并發(fā)度、速度也很難快速的完成數(shù)據(jù)均衡。針對(duì)這種情況，可以嘗試優(yōu)先下線空間已耗盡的實(shí)例，之后再擴(kuò)容的方式來(lái)實(shí)現(xiàn)均衡的目的。還有一點(diǎn)需注意，在3.0版本之前，數(shù)據(jù)均衡只能是節(jié)點(diǎn)之間的均衡，不能實(shí)現(xiàn)節(jié)點(diǎn)內(nèi)部不同數(shù)據(jù)盤(pán)的均衡。

RPC請(qǐng)求隊(duì)列的長(zhǎng)度

采集項(xiàng)：CallQueueLength(RPC請(qǐng)求隊(duì)列長(zhǎng)度)。

文件數(shù)量

采集項(xiàng)：FilesTotal

與堆內(nèi)存使用率配合使用。每個(gè)文件系統(tǒng)對(duì)象(包括文件、目錄、Block數(shù)量)至少占有150字節(jié)堆內(nèi)存，根據(jù)此，可以粗略預(yù)估出一個(gè)Namenode可以保存多少文件。根據(jù)文件與塊數(shù)量之間的關(guān)系，也可以對(duì)塊大小做一定優(yōu)化。

下線實(shí)例數(shù)

采集項(xiàng)：NumDecommissioningDataNodes

HDFS集群規(guī)模較大時(shí)，實(shí)時(shí)掌握健康實(shí)例說(shuō)，定期修復(fù)故障節(jié)點(diǎn)并及時(shí)上線，可以為公司節(jié)省一定成本。

其他

除上述主要指標(biāo)外，服務(wù)器、進(jìn)程JVM、依賴服務(wù)(Zookeeper、DNS)等通用監(jiān)控策略也需添加。

HDFS監(jiān)控落地

Grafana儀表盤(pán)展現(xiàn)：主要用于服務(wù)巡檢、故障定位(說(shuō)明：Grafana官方提供的HDFS監(jiān)控模板，數(shù)據(jù)指標(biāo)相對(duì)較少)

 

圖6 HDFS部分集群Grafana儀表盤(pán)

ELK-Hadoop：主要用于全局日志檢索，以及錯(cuò)誤日志關(guān)鍵字監(jiān)控

 

圖7 ES中搜索HDFS集群日志

 

圖8 日志服務(wù)搜索HDFS集群日志

Hue、HDFS UI：主要用于HDFS問(wèn)題排查與日常維護(hù)

HDFS案例

案例1

DNS產(chǎn)生臟數(shù)據(jù)，導(dǎo)致Namenode HA故障

發(fā)現(xiàn)方式：功能監(jiān)控、SLA指標(biāo)異常

故障原因：DNS服務(wù)器產(chǎn)生臟數(shù)據(jù)，致使Namenode主機(jī)名出錯(cuò)，在HA切換時(shí)，因找到錯(cuò)誤主機(jī)而失敗

優(yōu)化建議：DNS作為最基礎(chǔ)服務(wù)，務(wù)必保證其數(shù)據(jù)正確與穩(wěn)定，在一定規(guī)模情況下，切忌使用修改/etc/hosts方式來(lái)解決主機(jī)名問(wèn)題，如果沒(méi)有高可用的內(nèi)部DNS服務(wù)，建議使用DNSMasq來(lái)搭建一套DNS服務(wù)器

案例2

機(jī)架分組不合理，導(dǎo)致HDFS無(wú)法寫(xiě)入

發(fā)現(xiàn)方式：功能監(jiān)控寫(xiě)異常偶發(fā)性告警

故障原因：HDFS開(kāi)啟機(jī)架感知，不同分組機(jī)器資源分配不合理，部分分組存儲(chǔ)資源耗盡，在選擇Datanode時(shí)，找不到可用節(jié)點(diǎn)

優(yōu)化建議：合理分配各機(jī)架上的實(shí)例數(shù)量，并分組進(jìn)行監(jiān)控。在規(guī)模較小情況下，可用考慮關(guān)閉機(jī)架感知功能

附：

HDFS監(jiān)控自定義任務(wù)：

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

[[265257]]

作者：李子樹(shù)

京東云應(yīng)用研發(fā)部 

Hadoop分布式文件系統(tǒng)(HDFS)被設(shè)計(jì)成適合運(yùn)行在通用硬件(commodity hardware)上的分布式文件系統(tǒng)。HDFS能提供高吞吐量的數(shù)據(jù)訪問(wèn)，非常適合大規(guī)模數(shù)據(jù)集上的應(yīng)用。在大數(shù)據(jù)生態(tài)圈中，HDFS是最重要的底層分布式文件系統(tǒng)，它的穩(wěn)定性關(guān)乎整個(gè)生態(tài)系統(tǒng)的健康。本文介紹了HDFS相關(guān)的重要監(jiān)控指標(biāo)，分享指標(biāo)背后的思考。

【本文為51CTO專欄作者“京東云”的原創(chuàng)稿件，轉(zhuǎn)載請(qǐng)通過(guò)作者微信公眾號(hào)JD-jcloud獲取授權(quán)】 

戳這里，看該作者更多好文