一套很专业的监控方案：HDFS监控落地背后的思考
|
副标题[/!--empirenews.page--]
基于京东云的实战经验，我们今天来聊聊HDFS相关的监控。 Hadoop分布式文件系统(HDFS)被设计成适合运行在通用硬件(commodity hardware)上的分布式文件系统。 HDFS能提供高吞吐量的数据访问，非常适合大规模数据集上的应用。在大数据生态圈中，HDFS是最重要的底层分布式文件系统，它的稳定性关乎整个生态系统的健康。 本文介绍了HDFS相关的重要监控指标，分享指标背后的思考。 一、HDFS监控挑战 HDFS是Hadoop生态的一部分，监控方案不仅需适用HDFS，其他组件如Yarn、Hbase、Hive等，也需适用 HDFS API提供的指标较多，部分指标没必要实时采集，但故障时需能快速获取到 Hadoop相关组件的日志，比较重要，如问题定位、审计等 监控方案不仅能满足监控本身，故障定位涉及指标也应覆盖 二、Hadoop监控方案 Hadoop监控数据采集是通过HTTP API，或者JMX。实际中，用到比较多的产品主要有：CDH、Ambari，此外，还有部分工具，如Jmxtrans、HadoopExporter(用于Prometheus)。 CDH是一款开源的集部署、监控、操作等于一体的Hadoop生态组件管理工具，也提供收费版(比免费版多提供数据备份恢复、故障定位等特性)。CDH提供的HDFS监控界面在体验上是非常优秀的，是对HDFS监控指标深入发掘之后的浓缩，比如HDFS容量、读写流量及耗时、Datanode磁盘刷新耗时等。
图1 CDH提供的HDFS监控界面 Ambari与CDH类似，同样是开源工具，但它的扩展性要比较好，另外，它的信息可以从机器、组件、集群等不同维度展现，接近运维工程师使用习惯。
图2 Ambari提供的HDFS监控界面 如果使用CDH，或者Ambari进行HDFS监控，也存在实际问题：
其他工具，如Jmxtrans目前还不能很好适配Hadoop，因此，实际的监控方案选型为：
三、HDFS监控指标 1、主要指标概览
表1 HDFS主要监控指标概览 2、黑盒监控指标 基本功能 文件整个生命周期中，是否存在功能异常，主要监控创建、查看、修改、删除动作。 查看时，需校对内容，有一种方式，可以在文件中写入时间戳，查看时校对时间戳，这样，可以根据时间差来判断是否写超时 切记保证生命周期完整，否则，大量监控产生的临时文件可能导致HDFS集群垮掉 3、白盒监控指标 1)错误 Block丢失数量 采集项：MissingBlocks 如果出现块丢失，则意味着文件已经损坏，所以需要在块丢失前，提前预判可能出现Block丢失风险(通过监控UnderReplicatedBlocks来判断)。 不可用数据节点占比 采集项： 在BlockPlacementPolicyDefault.java中的isGoodTarget定义了选取Datanode节点策略，其中有两项是“节点是否在下线”、“是否有足够存储空间”，如果不可用数量过多，则可能导致选择不到健康的Datanode，因此，必须保证一定数量的健康Datanode。
图4 选取可用Datanode时部分判断条件 错误日志关键字监控 部分常见错误监控(主要监控Exception/ERROR)，对应关键字： IOException、NoRouteToHostException、SafeModeException、UnknownHostException。 未复制Block数 采集项：UnderReplicatedBlocks UnderReplicatedBlocks在数据节点下线、数据节点故障等均会产生大量正在同步的块数。 FGC监控 采集项：FGC 读写成功率 采集项： monitor_write.status/monitor_read.status 根据Block实际读写流量汇聚计算，是对外SLA指标的重要依据。 数据盘故障 采集项：NumFailedVolumes 如果一个集群有1000台主机，每台主机是12块盘(一般存储型机器标准配置)，那么这将会是1万2000块数据盘，按照机械盘平均季度故障率1.65%(数据存储服务商Backblaze统计)计算，平均每个月故障7块盘。若集群规模再扩大，那么运维工程师将耗费很大精力在故障盘处理与服务恢复上。很显然，一套自动化的数据盘故障检测、自动报修、服务自动恢复机制成为刚需。 除故障盘监控外，故障数据盘要有全局性解决方案。在实践中，以场景为维度，通过自助化的方式来实现对此问题处理。 图5 基于场景实现的Jenkins自助化任务 2)流量 Block读、写次数 （编辑：晋中站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
