通常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的网络情况可以查找，该节点是否在当时是热节点，一般情况下如果在该机器的网络情况已经满了，会影响任务的正常运行速度
机器负载情况 网络丢包情况 机器内存使用情况 总 结集群监控指标属于逐渐完善的一个过程，以上分享的是一般的重要常用指标，详细的问题分析可能需要通过工具和不同指标配合才能找到问题，希望这篇文章能够给大家带来用处