Hadoop分布式文件系统（HDFS）被设计为适合运行在商品硬件上的分布式文件系统。HDFS可以提供??高吞吐量的数据访问，非常适合大规模数据集上的应用。在大数据生态中，HDFS是最重要的底层分布式文件系统，其稳定性关系到整个生态的健康。本文介绍HDFS相关的重要监控指标，分享指标背后的思考。1.HDFS监控挑战HDFS是Hadoop生态系统的一部分。监控方案不仅需要应用HDFS，还需要应用Yarn、Hbase、Hive等其他组件。HDFSAPI提供了很多指标，有些指标不需要实时采集。能够快速获取Hadoop相关组件的日志很重要。问题定位、审计等监控解决方案不仅可以满足监控本身，还可以覆盖故障定位涉及的指标。2、Hadoop监控方案Hadoop监控数据采集是通过HTTPAPI，即JMX。在实践中，使用最多的产品是：CDH、Ambari，此外还有一些工具，如Jmxtrans、HadoopExporter(forPrometheus)。CDH是一款开源的集部署、监控、运维为一体的Hadoop生态组件管理工具。它还提供付费版（比免费版多了数据备份与恢复、故障定位等功能）。CDH提供的HDFS监控接口，体验上非常优秀。是对HDFS的容量、读写流量和耗时、Datanode磁盘刷新耗时等HDFS监控指标深入探索后的浓缩。CDH提供的HDFS监控接口Ambari与CDH类似。它也是一个开源工具，但它的可扩展性更好。此外，它的信息可以从机器、组件、集群等不同维度展现，贴近运维工程师的使用习惯。如果Ambari提供的HDFS监控接口使用CDH或者Ambari进行HDFS监控，也存在实际问题：无法定制对应的Hadoop及相关组件版本，不能很好的满足大规模HDFS集群的实际监控需求。其他工具，例如Jmxtrans，目前不可用。不能很好的适配Hadoop，所以实际的监控方案选择是：采集：HadoopExporter，HadoopHTTPAPI（注：HDFS主要调用http://{domain}:{port}/jmx）日志：通过ELK采集。分析存储：PrometheusDisplay：Grafana、HDFSUI、HueAlarm：对接京东云报警系统三、HDFS监控指标1、主要指标概述HDFS主要监控指标2、黑盒监控指标基本功能在整个生命周期文件，是否有功能异常，主要监控创建、查看、修改、删除等动作。查看时，需要对内容进行校对。有一种方法是在文件中写入时间戳，查看时校对时间戳。这样就可以根据时间差来判断是否写超时了。请记住确保生命周期是完整的。否则，监控产生的大量临时文件可能会导致HDFS集群崩溃3.白盒监控指标1）缺失块数的集合项：MissingBlocks。如果缺少一个块，则表示文件已损坏。因此，需要在块丢失之前提前预测块丢失的风险（通过监控UnderReplicatedBlocks来判断）。数据节点不可用比例集合项：BlockPlacementPolicyDefault.java中的isGoodTarget定义了选择Datanode节点的策略，其中两个是“节点是否离线”和“是否有足够的存储空间”。如果不可用的太多，否则健康的Datanode可能不会被选中。因此，必须保证一定数量的健康Datanode。选择可用的Datanode时，一些判断条件，错误日志关键字监控，以及一些常见的错误监控（主要是监控Exception/ERROR），对应关键字：IOException,NoRouteToHostException,SafeModeException,UnknownHostException。UnreplicatedBlocks集合项：UnderReplicatedBlocksUnderReplicatedBlocks会在数据节点下线或数据节点故障时产生大量正在同步的块。FGC监控采集项：FGC读写成功率采集项：monitor_write.status/monitor_read.status是根据区块实际读写流量聚合计算的，是外部SLA指标的重要依据。数据盘故障采集项：NumFailedVolumes如果一个集群有1000台主机，每台主机有12块磁盘（一般存储机器的标准配置），那么这就是12000块数据盘，以机械盘平均季度故障率1.65%（数据存储服务提供商Backblaze统计），平均每月有7次磁盘故障。如果集群规模进一步扩大，运维工程师将花费大量精力在故障磁盘处理和业务恢复上。显然，一套自动化的数据盘故障检测、自动修复、自动服务恢复机制已经成为刚需。除了故障盘监控，还必须有一个全局的故障数据盘解决方案。在实践中，这个问题是以自助的方式解决的，以场景为维度。场景化Jenkins自助任务2）流量块读写次数采集项：采集Datanode数据进行聚合计算。网络出入流量采集项：node_network_receive_bytes_total/node_network_transmit_bytes_total没有现成的数据可以直接使用，需要通过ReceivedBytes（接收到的总字节数）和SentBytes（发送的总字节数）计算。DiskI/O采集项：node_disk_written_bytes_total/node_disk_read_bytes_total3)DelayedRPC处理平均时间采集项：RpcQueueTimeAvgTime采集RpcQueueTimeAvgTime（平均RPC处理时间），SyncsAvgTime（Journalnode同步耗时）。慢节点数收集项：SlowPeerReports慢节点的主要特点是落在该节点上的读写与平均值相去甚远，但如果有足够的时间，它仍然可以返回正确的结果。除了机器的硬件和网络之外，出现慢节点的主要原因是相应节点的负载过重。在实际监控中，除了监控节点上耗时的读写，还需要重点监控节点上的负载。根据实际需要，您可以灵活调整Datanode的上报时间，或者开启“StaleNode”检测，让Namenode能够准确识别故障实例。涉及到一些配置项：dfs.namenode.heartbeat.recheck-intervaldfs.heartbeat.intervaldfs.namenode.avoid.read.stale.datanodedfs.namenode.avoid.write.stale.datanodedfs.namenode.stale.datanode。interval4)Capacityclustertotalspace,spaceusagerate集合项：PercentUsedHDFSUI花费大量空间来显示存储空间相关指标，足以说明其重要性。空间使用计算包括“下线”节点的空间，这是一个陷阱。如果部分节点离线，它们所代表的空间仍然计入总空间。如果离线节点过多，就会出现这样的“怪异现象”：集群剩余空间很多，但是没有空间可写。另外，在规划Datanode空间时，要预留一部分空间。HDFS保留空间可能被其他程序使用，也可能是文件删除后，但已经被引用。如果“NonDFSUsed”不断增加，则需要追查具体原因并进行优化。可以通过以下参数设置预留空间：dfs.datanode.du.reserved.calculatordfs.datanode.du.reserveddfs.datanode.du.reserved.pct作为HDFS运维开发者，你需要知道这个公式：配置的容量=总磁盘空间-保留空间=剩余空间+DFS已用+非DFS已用。Namenode堆内存使用率收集项：HeapMemoryUsage.used/HeapMemoryUsage.committed把这个指标作为HDFS的核心指标一点也不为过。Metadata和Blockmappings占据了Namenode的大部分堆内存，这也是HDFS不适合存储大量小文件的原因之一。如果堆内存占用过大，Namenode可能启动缓慢，可能存在FGC风险。因此，需要仔细监控堆内存使用情况。实际上，堆内存使用量的增加是不可避免的。给出了几种行之有效的解决方案：调整堆内存分配，建立文件生命周期管理机制，及时清理一些无用文件和小文件，利用HDFSFederation横向扩展。从长远来看，可以有效降低风险，但提前做好集群规划也是很有必要的。数据平衡收集项：对于HDFS来说，数据存储平衡在一定程度上决定了它的安全性。在实践中，这组数据的标准差是根据每个存储实例的空间使用率来计算的，用于反馈每个实例之间的数据平衡程度。在大数据的情况下，虽然很难通过调整并发和速度来快速完成数据均衡，但进行数据均衡会比较耗时。对于这种情况，可以尝试先把空间已经用完的实例脱掉，再扩容，达到平衡的目的。还有一点需要注意的是，在3.0版本之前，数据均衡只能在节点之间进行均衡，无法实现一个节点内不同数据盘的均衡。RPC请求队列长度集合项：CallQueueLength（RPC请求队列长度）。文件数量收集项：FilesTotal与堆内存使用情况结合使用。每个文件系统对象（包括文件、目录和块的数量）至少占用150字节的堆内存。以此为基础，你可以粗略估计一个Namenode可以存储多少个文件。根据文件数量和块数量之间的关系，还可以对块大小进行一些优化。下线实例数采集项：NumDecommissioningDataNodes当HDFS集群规模较大时，实时监控健康实例，定期修复故障节点，及时上线，可为公司节省一定的成本。5）其他除了上述主要指标外，还需要添加服务器、进程JVM、依赖服务（Zookeeper、DNS）等通用监控策略。4、HDFS监控登陆Grafana仪表盘展示：主要用于服务巡检和故障定位（注：Grafana官方提供的HDFS监控模板，数据指标相对较少）。HDFS部分集群GrafanadashboardELK-Hadoop：主要用于全局日志检索和错误日志关键词监控。在ES中搜索HDFS集群日志搜索HDFS集群日志日志服务搜索HDFS集群日志Hue、HDFSUI：主要用于HDFS故障排除和日常维护。五、HDFS案例案例一：DNS产生脏数据，导致NamenodeHA失效。发现方法：功能监控，SLA指标异常故障原因：DNS服务器产生脏数据，导致Namenode主机名错误，HA切换时，因为找错主机而失败Stable。在一定规模内，不要使用修改/etc/hosts的方法来解决主机名问题。如果没有高可用的内部DNS服务，建议使用DNSMasq搭建DNS服务器。案例二：机架分组不合理，导致HDFS无法写入。发现方法：功能监控，写入异常，偶发告警，故障原因：HDFS开启机架感知，不同分组机器资源分配不合理，部分分组存储资源耗尽，选择Datanode找不到可用节点。机架上的实例数并分组进行监控。在规模较小的情况下，可以考虑关闭货架感知功能
