[Hadoop] Hadoop集羣通常須要關注的幾個重要指標

原文來自hackershell,轉載請註明出處

通用監控指標

對於每一個RPC服務應該監控

RpcProcessingTimeAvgTime(PRC處理的平均時間)

一般hdfs在異常任務突發大量訪問時，這個參數會忽然變得很大，致使其餘用戶訪問hdfs時，會感受到卡頓，從而影響任務的執行時間

CallQueueLength(RPC Call隊列的長度)

若是callqueue隊列數值一直處於較高的水平，例如對於NN來講CallQueue的長度等於handler*100，也就是說NN可能收到了大量的請求或者server在處理rpc請求時耗時很長，致使call堆積等

進程JVM監控

MemHeapUsedM(堆內存使用監控)

經過監控改參數能夠查看進程的gc時間和gc發生以後釋放多少內存和進程的內存使用狀況

ThreadsBlocked(線程阻塞數量)

分析當問題發生時進程的線程的阻塞情況

ThreadsWaiting(線程等待數量)

分析當問題發生時進程的線程的等待情況

NameNode監控指標

TotalFiles(總的文件數量)

監控和預警文件數的總量，能夠經過其看出是否有任務忽然大量寫文件和刪除大量文件

TotalBlocks(總的block數量)

表示集羣的block數量，做用同上

PercentUsed(集羣hdfs使用百分比)

監控集羣的hdfs的使用狀況，使用率不宜過高，由於須要預留磁盤空間給任務計算使用

BlockPoolUsedSpace(集羣該namespace的hdfs使用容量大小)

能夠監控不一樣namespace的hdfs的使用狀況

Total(集羣hdfs總容量大小)

顯示集羣總體容量狀況

Used(集羣hdfs已使用的容量大小)

集羣hdfs使用狀況，能夠預警是否須要增長機器和刪除無用數據

NumLiveDataNodes(存活的DN數量)

NumDeadDataNodes(丟失的DN數量)

丟失節點，若是過多可能會引發丟塊

VolumeFailuresTotal(壞盤的數量)

應該設定閥值，達到必定數量時處理

MissingBlocks(丟失的block數量)

丟失重要的塊會引發任務報錯

DataNode監控指標

ReadBlockOpAvgTime(讀取block的平均時間)

可選的監控選項，若是該機器在某個時段平均時間忽然升高，可能網絡有打滿或磁盤讀取速度存在問題

WriteBlockOpAvgTime(寫數據塊的平均時間)

可選的監控選項

ResouceManager監控指標

NumActiveNMs(NM存活節點數量監控)

NumLostNMs(NM丟失節點數量監控)

有時節點會由於磁盤空間不足等緣由致使進程退出，雖然集羣具備容錯機制，但當丟失節點達到必定數量以後，集羣計算資源至關於減小了，因此應當設置合理的閥值報警處理

NumUnhealthyNMs(NM不健康節點數量監控)

一般會由於磁盤問題致使節點不健康

集羣應用數量監控

AppsSubmitted(app提交數量)

以前集羣有出現過app的id號，生成很慢的狀況，能夠經過改數值和其餘參數去判斷提交減小的問題

AppsRunning(app的運行數量)

能夠經過改值去對比歷史同一時刻的app的運行數量是否差別很大，去判斷集羣究竟是否可能出現問題

AppsPending(app等待數量)

若是該數值很高，或則在某個queue的該數值很高，有多是由於app所在的隊列資源滿了，致使app沒法獲取資源，啓動master，若是資源沒滿，可能的一個緣由是app的所在隊列沒法在rm中有先獲取資源，或資源被預留所致使等

AppsCompleted(app完成數量)

應用完成的數量監控

AppsKilled(app被kill的數量)

應用被kill的數量監控

AppsFailed(app失敗數量)

若是AppsFailed數量升高，說明集羣的存在致使app批量失敗的操做

集羣資源使用量狀況監控

AllocatedMB(已分配的內存大小)

若是集羣用戶反應任務運行緩慢，應該及時檢查隊列資源的使用狀況和hdfs的響應速度

AllocatedVCores(已分配的核數量)

有時任務分配不上去，有多是核數已經用完

AllocatedContainers(已分配的Container數量)

已分配的Container數量

AvailableMB(可用的內存大小)

有遇到過在集羣反覆重啓NM後，致使集羣計算可用資源錯誤的bug

AvailableVCores(可能的核數量)

PendingMB(等待分配的內存大小)

PendingVCores(等待分配的核數量)

PendingContainers(等待分配的Container數量)

若是等待分配的Container比平常出現多出不少，應該檢查集羣是否有問題

ReservedMB(預留的內存大小)

以前遇到由於spark任務申請很大的資源，致使把整個集羣的資源都預留的狀況，這時應該適當的調整最大的分配Container的內存大小

ReservedVCores(預留的核數量)

同上

ReservedContainers(預留的Container數量)

Container由於資源不足，優先預留節點

集羣分配數據監控

AssignContainerCallNumOps(分配Container的次數)

咱們能夠經過該監控能夠知道RM每秒可以分配多少的Container，在高峯期是否可能存在瓶頸，通過社區的patch優化以後，RM的分配Container最大值能夠達到4k+

AssignContainerCallAvgTime(分配Container的平均時間)

若是時間忽然變大，說明可能遇到分配瓶頸等其餘問題

ContinuousScheduleCallNumOps(連續調度次數)

若是該數值沒有增長，說明連續調度線程出現問題

ContinuousScheduleCallAvgTime(連續調度平均時間)

連續調度的平均時間

NodeUpdateCallNumOps(NM心跳彙報次數)

NodeUpdateCallAvgTime(心跳彙報處理時間)

rm資源分配是經過每一次NM的心跳進行分配和領取Container的，若是該時間變長，則分配速度可能會存在降低

Linux機器監控

網絡帶寬狀況

經過監控DN的網絡狀況能夠查找，該節點是否在當時是熱節點，通常狀況下若是在該機器的網絡狀況已經滿了，會影響任務的正常運行速度

機器負載狀況

網絡丟包狀況

機器內存使用狀況

總 結

集羣監控指標屬於逐漸完善的一個過程，以上分享的是通常的重要經常使用指標，詳細的問題分析可能須要經過工具和不一樣指標配合才能找到問題，但願這篇文章可以給你們帶來用處,更多技術內容能夠繼續關注咱們公衆號的推送哦～