阿里技术架构内部总结：HDFS监控落地的思考
|
慢节点主要特征是，落到该节点上的读、写较平均值差距较大，但给他足够时间，仍然能返回正确结果。通常导致慢节点出现的原因除机器硬件、网络外，对应节点上的负载较大是另一个主要原因。实际监控中，除监控节点上的读写耗时外，节点上的负载也需要重点监控。 根据实际需要，可以灵活调整Datanode汇报时间，或者开启“陈旧节点”(Stale Node)检测，以便Namenode准确识别故障实例。涉及部分配置项：
4)容量 集群总空间、空间使用率 采集项：PercentUsed HDFS UI花费了很大篇幅来展现存储空间相关指标，足以说明它的重要性。 空间使用率计算包含了处于“下线中”节点空间，这是一个陷阱。如果有节点处于下线状态，但它们代表的空间仍计算在总空间，如果下线节点过多，存在这样“怪象”：集群剩余空间很多，但已无空间可写。 此外，在Datanode空间规划时，要预留一部分空间。HDFS预留空间有可能是其他程序使用，也有可能是文件删除后，但一直被引用，如果“Non DFS Used”一直增大，则需要追查具体原因并优化，可以通过如下参数来设置预留空间：
作为HDFS运维开发人员，需清楚此公式：Configured Capacity = Total Disk Space - Reserved Space = Remaining Space + DFS Used + Non DFS Used。 Namenode堆内存使用率 采集项： HeapMemoryUsage.used/HeapMemoryUsage.committed 如果将此指标作为HDFS核心指标，也是不为过的。元数据和Block映射关系占据了Namenode大部分堆内存，这也是HDFS不适合存储大量小文件的原因之一。堆内存使用过大，可能会出现Namenode启动慢，潜在FGC风险，因此，堆内存使用情况需重点监控。 实际中，堆内存使用率增加，不可避免，给出有效的几个方案：
尽管这些措施可以在很长时间内，有效降低风险，但提前规划好集群也是很有必要。 数据均衡度 采集项：  HDFS而言，数据存储均衡度，一定程度上决定了它的安全性。实际中，根据各存储实例的空间使用率，来计算这组数据的标准差，用以反馈各实例之间的数据均衡程度。 数据较大情况下，如果进行数据均衡则会比较耗时，尽管通过调整并发度、速度也很难快速的完成数据均衡。针对这种情况，可以尝试优先下线空间已耗尽的实例，之后再扩容的方式来实现均衡的目的。 还有一点需注意，在3.0版本之前，数据均衡只能是节点之间的均衡，不能实现节点内部不同数据盘的均衡。 RPC请求队列的长度 采集项：CallQueueLength(RPC请求队列长度)。 文件数量 采集项：FilesTotal 与堆内存使用率配合使用。每个文件系统对象(包括文件、目录、Block数量)至少占有150字节堆内存，根据此，可以粗略预估出一个Namenode可以保存多少文件。根据文件与块数量之间的关系，也可以对块大小做一定优化。 下线实例数 采集项：NumDecommissioningDataNodes HDFS集群规模较大时，实时掌握健康实例说，定期修复故障节点并及时上线，可以为公司节省一定成本。 5)其他 除上述主要指标外，服务器、进程JVM、依赖服务(Zookeeper、DNS)等通用监控策略也需添加。 四、HDFS监控落地 Grafana仪表盘展现：主要用于服务巡检、故障定位(说明：Grafana官方提供的HDFS监控模板，数据指标相对较少)。  HDFS部分集群Grafana仪表盘 ELK-Hadoop：主要用于全局日志检索，以及错误日志关键字监控。  ES中搜索HDFS集群日志  日志服务搜索HDFS集群日志 Hue、HDFS UI：主要用于HDFS问题排查与日常维护。 五、HDFS案例 案例1： DNS产生脏数据，导致Namenode HA故障。
案例2： （编辑：辽源站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |