通用監控指標
對於每個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的網絡情況可以查找，該節點是否在當時是熱節點，一般情況下如果在該機器的網絡情況已經滿了，會影響任務的正常運行速度
機器負載情況
網絡丟包情況
機器內存使用情況