HDFS 监控背后那些事儿，构建 Hadoop 监控共同体

我就是我 2022-11-01 10:58 311阅读 0赞

**[运维][Link 1][开源][Link 2][最佳实践][Link 3]

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 为 Cloudera 公司开源的一款集部署、监控、操作等于一体的 Hadoop 生态组件管理工具，也提供收费版（比免费版多提供数据备份恢复、故障定位等特性）。CDH 提供的 HDFS 监控界面在体验上是非常优秀的，是对 HDFS 监控指标深入发掘之后的浓缩，比如 HDFS 容量、读写流量及耗时、Datanode 磁盘刷新耗时等。

![113916b9b70d05114e4ac1ad31620049.png][]

图 1 CDH 提供的 HDFS 监控界面

Ambari 与 CDH 类似，它是 Hortonworks 公司（与 Cloudera 公司已合并）开源。它的扩展性要比较好，另外，它的信息可以从机器、组件、集群等不同维度展现，接近运维工程师使用习惯。

![5b4d58acd1ceb664e397b9a384bc55c3.png][]

图 2 Ambari 提供的 HDFS 监控界面

如果使用 CDH，或者 Ambari 进行 HDFS 监控，也存在实际问题：

*  对应的 Hadoop 及相关组件版本不能自定义
 *  不能很好的满足大规模 HDFS 集群实际监控需求

其他工具，如 Jmxtrans 目前还不能很好适配 Hadoop，因此，实际的监控方案选型为：

*  采集：HadoopExporter，Hadoop HTTP API（说明：HDFS 主要调用 http://\{domain\}:\{port\}/jmx）
 *  日志：通过 ELK 来收集、分析
 *  存储：Prometheus
 *  展现：Grafana，HDFS UI，Hue
 *  告警：对接京东云告警系统

## HDFS 监控指标 ##

### 主要指标概览 ###

表 1 HDFS 主要监控指标概览

![9655a1fab775a1bcce2b321bcc34aa29.png][]

### 黑盒监控指标 ###

基本功能：文件整个生命周期中，是否存在功能异常，主要监控创建、查看、修改、删除动作。

*  查看时，需校对内容，有一种方式，可以在文件中写入时间戳，查看时校对时间戳，这样，可以根据时间差来判断是否写超时
 *  切记保证生命周期完整，否则，大量监控产生的临时文件可能导致 HDFS 集群垮掉

### 白盒监控指标 ###

错误

**Block 丢失数量**

采集项：MissingBlocks

如果出现块丢失，则意味着文件已经损坏，所以需要在块丢失前，提前预判可能出现 Block 丢失风险（通过监控 UnderReplicatedBlocks 来判断）。

**不可用数据节点占比**

采集项：

![8ca4500b6bcdfc5bbe794c95f19bc0c6.png][]

在 BlockPlacementPolicyDefault.java 中的 isGoodTarget 定义了选取 Datanode 节点策略，其中有两项是“节点是否在下线”、“是否有足够存储空间”，如果不可用数量过多，则可能导致选择不到健康的 Datanode，因此，必须保证一定数量的健康 Datanode。

![2b96cf3fe9fe2bbf4a803bcf2b5ff430.png][]

图 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 块盘。若集群规模再扩大，那么运维工程师将耗费很大精力在故障盘处理与服务恢复上。很显然，一套自动化的数据盘故障检测、自动报修、服务自动恢复机制成为刚需。

除故障盘监控外，故障数据盘要有全局性解决方案。在实践中，以场景为维度，通过自助化的方式来实现对此问题处理。

![f88c0d152835bc621705636ab8585c7b.png][]

图 5 基于场景实现的 Jenkins 自助化任务

流量

**Block 读、写次数**

采集项：

![38de500741b18e4bfd48398f60a7351f.png][]

采集 Datanode 数据进行汇聚计算。

**网络进出流量**

采集项：

node\_network\_receive\_bytes\_total/ node\_network\_transmit\_bytes\_total

没有直接可以使用的现成数据，需要通过 ReceivedBytes（接收字节总量）、SentBytes（发送字节总量）来计算。

**磁盘 I/O**

采集项：node\_disk\_written\_bytes\_total/ node\_disk\_read\_bytes\_total

延迟

**RPC 处理平均时间**

采集项：RpcQueueTimeAvgTime

采集 RpcQueueTimeAvgTime（RPC 处理平均时间）、SyncsAvgTime（Journalnode 同步耗时）。

**慢节点数量**

采集项：SlowPeerReports

慢节点主要特征是，落到该节点上的读、写较平均值差距较大，但给他足够时间，仍然能返回正确结果。通常导致慢节点出现的原因除机器硬件、网络外，对应节点上的负载较大是另一个主要原因。实际监控中，除监控节点上的读写耗时外，节点上的负载也需要重点监控。

根据实际需要，可以灵活调整 Datanode 汇报时间，或者开启“陈旧节点”（Stale Node）检测，以便 Namenode 准确识别故障实例。涉及部分配置项：

*  dfs.namenode.heartbeat.recheck-interval
 *  dfs.heartbeat.interval
 *  dfs.namenode.avoid.read.stale.datanode
 *  dfs.namenode.avoid.write.stale.datanode
 *  dfs.namenode.stale.datanode.interval

容量

**集群总空间、空间使用率**

采集项：PercentUsed

HDFS UI 花费了很大篇幅来展现存储空间相关指标，足以说明它的重要性。

空间使用率计算包含了处于“下线中”节点空间，这是一个陷阱。如果有节点处于下线状态，但它们代表的空间仍计算在总空间，如果下线节点过多，存在这样“怪象”：集群剩余空间很多，但已无空间可写。

此外，在 Datanode 空间规划时，要预留一部分空间。HDFS 预留空间有可能是其他程序使用，也有可能是文件删除后，但一直被引用，如果“Non DFS Used”一直增大，则需要追查具体原因并优化，可以通过如下参数来设置预留空间：

*  dfs.datanode.du.reserved.calculator
 *  dfs.datanode.du.reserved
 *  dfs.datanode.du.reserved.pct

作为 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 Federation 横向扩展

尽管这些措施可以在很长时间内，有效降低风险，但提前规划好集群也是很有必要。

**数据均衡度**

采集项：

![572f62d351bda35516470010f83e366f.png][]

HDFS 而言，数据存储均衡度，一定程度上决定了它的安全性。实际中，根据各存储实例的空间使用率，来计算这组数据的标准差，用以反馈各实例之间的数据均衡程度。数据较大情况下，如果进行数据均衡则会比较耗时，尽管通过调整并发度、速度也很难快速的完成数据均衡。针对这种情况，可以尝试优先下线空间已耗尽的实例，之后再扩容的方式来实现均衡的目的。还有一点需注意，在 3.0 版本之前，数据均衡只能是节点之间的均衡，不能实现节点内部不同数据盘的均衡。

**RPC 请求队列的长度**

采集项：CallQueueLength（RPC 请求队列长度）。

**文件数量**

采集项：FilesTotal

与堆内存使用率配合使用。每个文件系统对象（包括文件、目录、Block 数量）至少占有 150 字节堆内存，根据此，可以粗略预估出一个 Namenode 可以保存多少文件。根据文件与块数量之间的关系，也可以对块大小做一定优化。

**下线实例数**

采集项：NumDecommissioningDataNodes

HDFS 集群规模较大时，实时掌握健康实例说，定期修复故障节点并及时上线，可以为公司节省一定成本。

其他

除上述主要指标外，服务器、进程 JVM、依赖服务（Zookeeper、DNS）等通用监控策略也需添加。

## HDFS 监控落地 ##

Grafana 仪表盘展现：主要用于服务巡检、故障定位（说明：Grafana 官方提供的 HDFS 监控模板，数据指标相对较少）

![7b073aa5628a69c6f02df7ab7db410df.png][]

图 6 HDFS 部分集群 Grafana 仪表盘

ELK-Hadoop：主要用于全局日志检索，以及错误日志关键字监控

![47cbb219c200b9d7b639553188ead7d6.png][]

图 7 ES 中搜索 HDFS 集群日志

![dad82df98720e858a9e5a762b4b0209e.png][]

图 8 日志服务搜索 HDFS 集群日志

Hue、HDFS UI：主要用于 HDFS 问题排查与日常维护

## HDFS 案例 ##

### 案例 1 ###

DNS 产生脏数据，导致 Namenode HA 故障

发现方式：功能监控、SLA 指标异常

故障原因：DNS 服务器产生脏数据，致使 Namenode 主机名出错，在 HA 切换时，因找到错误主机而失败

优化建议：DNS 作为最基础服务，务必保证其数据正确与稳定，在一定规模情况下，切忌使用修改/etc/hosts 方式来解决主机名问题，如果没有高可用的内部 DNS 服务，建议使用 DNSMasq 来搭建一套 DNS 服务器

### 案例 2 ###

机架分组不合理，导致 HDFS 无法写入

发现方式：功能监控写异常偶发性告警

故障原因：HDFS 开启机架感知，不同分组机器资源分配不合理，部分分组存储资源耗尽，在选择 Datanode 时，找不到可用节点

优化建议：合理分配各机架上的实例数量，并分组进行监控。在规模较小情况下，可用考虑关闭机架感知功能

附：

HDFS 监控自定义任务：

[https://github.com/cloud-op/monitor][https_github.com_cloud-op_monitor]

[Link 1]: https://www.infoq.cn/topic/operation
[Link 2]: https://www.infoq.cn/topic/opensource
[Link 3]: https://www.infoq.cn/topic/best-practices
[113916b9b70d05114e4ac1ad31620049.png]: /images/20221024/cd332dc139a64f17bd23083c30b32266.png
[5b4d58acd1ceb664e397b9a384bc55c3.png]: /images/20221024/7210a426f1da480484994e48cd727f75.png
[9655a1fab775a1bcce2b321bcc34aa29.png]: /images/20221024/e51b97a799d047e1b777c349462e4580.png
[8ca4500b6bcdfc5bbe794c95f19bc0c6.png]: /images/20221024/f983e04120ed4087b0363290e424a27c.png
[2b96cf3fe9fe2bbf4a803bcf2b5ff430.png]: /images/20221024/4f500f3867bd492192823932124cc08b.png
[f88c0d152835bc621705636ab8585c7b.png]: /images/20221024/e6038c1f6d4a43ad9c1f0ff58b926b2f.png
[38de500741b18e4bfd48398f60a7351f.png]: /images/20221024/4b0246186fe54b08b223fa3d2a90405b.png
[572f62d351bda35516470010f83e366f.png]: /images/20221024/fd225589e95a4885809ca79780919d88.png
[7b073aa5628a69c6f02df7ab7db410df.png]: /images/20221024/9964027b25894ed6b3cf3604a2ef12c5.png
[47cbb219c200b9d7b639553188ead7d6.png]: /images/20221024/92283459e4f545d9b2058f04a00cbee1.png
[dad82df98720e858a9e5a762b4b0209e.png]: /images/20221024/a5338d6992a44b7096fc05e740ac4d29.png
[https_github.com_cloud-op_monitor]: https://github.com/cloud-op/monitor