通用監控指標

對於每個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的網路情況可以查詢，該節點是否在當時是熱節點，一般情況下如果在該機器的網路情況已經滿了，會影響任務的正常執行速度

機器負載情況

網路丟包情況

機器記憶體使用情況