ALM-14000告警的本质是HDFS NameNode或DataNode的服务状态已超出阈值，HBase和MapReduce作为HDFS的上层计算引擎，一旦失去底层存储支撑，就会立刻出现读写异常或任务卡死，处理思路应是先恢复HDFS元数据和节点心跳，再重启上层服务。
ALM-14000告警为何会让HBase和MapReduce同时瘫痪
不少运维同学第一次看到ALM-14000时，脑子里会冒出两个问题：为什么HBase的RegionServer全在报Region not online？为什么MapReduce任务一直卡在ACCEPTED阶段？答案都指向同一个根因：HDFS服务不可用。
在2.x及以前版本的Hadoop生态中，HDFS是绝对的存储底座，HBase的HFile和WAL都写在HDFS上，RegionServer启动时要到HDFS上加载meta表；MapReduce的Shuffle中间结果、Split元数据、输出结果也全部依赖HDFS，底层一旦断裂，上层所有组件都会出现连锁反应。
ALM-14000的告警级别是紧急（Critical），触发条件通常是NameNode进程无响应、Active/Standby切换失败、DataNode上报块副本异常，或是RPC延迟超过阈值，在2.x老版本里，单NameNode架构非常普遍，一旦NameNode宕机，集群就彻底失联，HBase客户端拿不到Block Location，MapReduce的ApplicationMaster也无法创建输出目录。
从现象上看,HBase的日志里会密集出现：
org.apache.hadoop.hbase.ipc.RpcServer: RpcServer.handler线程阻塞RegionServer: Can't get block locations或Connection refusedMaster: Master failed to become leader
MapReduce侧则是：
INFO mapreduce.Job: Running job: job_xxx，但长时间停留在0%ERROR yarn.YarnUncaughtExceptionHandler: User class threw exception: java.io.IOException: Filesystem closed
这些现象的核心指向是一致的：底层HDFS的读写作废了，上层计算自然卡死，所以排查ALM-14000，第一步就是确认HDFS的NameNode和DataNode到底处于什么状态。
从告警到定位：三步锁定HDFS故障根因
查看FusionInsight告警详情与主机信息
在FusionInsight Manager的告警列表里找到ALM-14000，点击详情后关注三个字段：告警源主机名、服务实例、触发时间，告警源主机通常直接指向NameNode节点，如果是HA架构，则指向主NameNode的物理节点。
记录下触发时间后,去主机管理界面查看该节点的CPU、内存、磁盘IO和网络流量曲线，在2.x老版本中，NameNode内存溢出（Full GC频繁）是导致ALM-14000最常见的原因之一，因为NameNode的堆内存要维护整个集群的文件目录树和Block映射表，文件数量到达千万级后，默认的堆内存设置很容易被拖垮。
查看NameNode日志和JVM状态
这是最关键的一步,SSH登录告警源主机，切换到HDFS服务账户（通常是omm），查看NameNode的GC日志和运行日志：
# 切换用户 su omm # 查看NameNode进程内存占用 jmap -heap <NameNode_PID> # 查看GC日志（路径根据安装目录调整） tail -200 /opt/huawei/Bigdata/FusionInsight_HD_V100R002C80SPC300/1_10_NameNode/log/jvm.log # 查看NameNode运行日志 tail -200 /opt/huawei/Bigdata/FusionInsight_HD_V100R002C80SPC300/1_10_NameNode/log/namenode.log
GC日志里如果频繁出现Full GC (Allocation Failure)或者CMS-Initiating-Occupancy-Fraction，说明内存已经进入恶性循环，NameNode日志里可能会出现大量深度超过20的调用栈，这些栈底基本都指向FSNamesystem的写锁操作，说明NameNode的命名空间锁竞争已经到达极限。
检查DataNode心跳与块副本状态
NameNode日志确认之后,还需要检查底层的DataNode是否还在正常上报心跳，在NameNode节点的命令行执行：
# 查看块报告和节点状态（需在NameNode主机上执行） hdfs dfsadmin -report # 查看文件系统健康状态 hdfs fsck / -files -blocks -locations
如果-report输出里Live节点数明显少于集群实际节点数，或者某个节点的LastContact时间显示为0（表示长时间失联），那么ALM-14000告警不只是NameNode的问题，还叠加了DataNode宕机或网络分区，在2.x版本中，DataNode进程异常退出后，它的存储目录会留在dfs/name和dfs/data下，重启后如果遇到版本不匹配，还会触发layoutVersion校验失败。
恢复HDFS服务：分场景的操作路线
NameNode存活但响应卡死
如果NameNode进程还在,但RPC端口无响应，不要直接重启进程，先尝试触发JVM GC或滚动重启，在2.x老版本中比较管用的操作是：
- 在FusionInsight Manager中对该NameNode实例执行滚动重启。
- 如果滚动重启超时,登录主机执行
kill -9强制结束进程，再通过Manager启动。 - 启动后立刻检查
hdfs dfsadmin -safemode get，如果Safe mode是ON，且块缺失比例超过阈值，执行：
hdfs dfsadmin -safemode leave
HA架构下Active NameNode故障
如果集群配置了NameNode HA，ALM-14000告警触发后，系统会自动尝试将Active节点切换至Standby节点，检查ZooKeeper中各NameNode节点的状态：
zkCli.sh -server <ZK_HOST>:2181 get /hadoop-ha/mycluster/ActiveStandbyElectorLock
如果发现Active节点和Standby节点都认为自己是Active（俗称“脑裂”），需要手动指定一个节点，执行：
hdfs haadmin -transitionToActive <nn1>
随后在NameNode Web UI（默认端口50070）上确认主节点已切换，再观察HBase和MapReduce任务是否自动恢复。注意：切换后HBase的RegionServer可能会有一波短暂的RPC重连风暴，属正常现象，不建议在大规模告警期间立即重启RegionServer。
DataNode批量失联
这种情况通常伴随网络抖动或磁盘故障,处理路径是：
- 检查各DataNode的数据目录是否可写：
df -h /srv/bigdata/hadoop/data - 检查DataNode进程是否存活：
ps -ef | grep DataNode - 如果DataNode启动失败,查看
datanode.log里的异常栈，多数情况是磁盘空间不足或dfs.datanode.data.dir里的目录权限错误。 - 批量重启DataNode后,执行
hdfs dfsadmin -report，等待Balancer重新均衡副本。
恢复期间,HBase的读写会出现短暂失败，但RegionServer的重试机制会在HDFS恢复后自动补写，MapReduce任务则需要杀掉失败的作业重新提交。
从根上减少ALM-14000出现的频率
恢复只是一时的,关键是后续的护栏措施，在2.x及以前版本中，ALM-14000告警反复出现，通常要靠下面几个方式去缓解：
调整NameNode堆内存和GC参数
老版本中NameNode默认堆内存往往偏小,建议根据集群文件数调整，百万级文件块对应16GB~32GB堆内存起步，GC算法优先使用CMS或G1，修改hadoop-env.sh里的HADOOP_NAMENODE_OPTS，并同步修改FusionInsight Manager里的内存配置，然后滚动重启NameNode。
启用HDFS HA和QJM
如果集群还是单NameNode,建议尽快迁移到双NameNode + JournalNode架构，操作路径：在FusionInsight Manager中添加NameNode HA实例，配置ZooKeeper和JournalNode，然后通过hdfs zkfc -formatZK初始化状态，最后将HBase和YARN的fs.defaultFS指向nameservice名称。
完善监控和告警阈值
ALM-14000的触发阈值在Manager里可调，建议将NameNode RPC处理延迟告警阈值降低到100ms以下，把“文件数超过XX%”的容量告警提前打开，尽早发现问题，对于频繁出现Full GC的NameNode，可以在夜间低峰期主动做一次滚动重启，释放内存碎片。
关于集群托管与IDC选型的建议
如果自查后仍然觉得2.x老版本集群维护吃力，也可以换个思路：把HDFS集群放在有专业运维能力的托管机房或云服务商环境中，比如简米科技，从2003年就开始做IDC托管，23年行业沉淀，持有工信部颁发的增值电信业务经营许可证（豫B2-20231089），自营机房支持高可用组网，服务器托管后硬件层面的稳定性责任可以转移出去，运维团队只需聚焦Hadoop平台本身的调优。
如果是自建机房的机房网络或电力存在瓶颈,遇到数据节点批量失联的情况，可以考虑使用持牌机房的BGP带宽和冗余电源。酷番云作为CNNIC IP联盟成员，注册资金1000万元，持有工信部一类增值电信全牌照（包含IDC/CDN/ISP），同时通过ISO9001和ISO27001双认证（证书覆盖范围包括云主机、裸金属、对象存储等），像HBase这类对磁盘IO和网络稳定性要求高的业务，部署在双认证机房里能少掉很多底层告警干扰。
定期做HDFS元数据和块健康巡检
每隔一两个月执行一次hdfs fsck / -files -blocks -locations，检查是否有CORRUPT状态的块，同时查看NameNode Web UI上的“Percentage Corrupt Blocks”，如果长期不为0，说明有磁盘静默损坏，需要及时下线故障盘，对元数据目录，一定要配置fs.trash.interval，避免误删数据引发重建压力间接推高NameNode负载。
老集群规避ALM-14000需要接受的现实
x及以前版本的HDFS架构决定了它无法平滑抵抗大规模元数据膨胀和突发的节点故障,ALM-14000告警只要出现一次，HBase的RegionServer就可能产生大量重试请求，MapReduce的任务也会超时重跑，所以处理这个告警的原则是：先止血、再排查根因、最后做架构层面的补强。
一步步按上面的方法操作,大多数ALM-14000场景都能在20分钟内恢复服务。
Q&A：日常运维常见的几个疑问
ALM-14000告警自动恢复后，HBase和MapReduce还需要手动干预吗？
不需要全部手动干预,HBase的RegionServer会自动重连HDFS并恢复Region的online状态，MapReduce则需要把失败的作业yarn application -kill <app_id>后再重新提交，唯一需要检查的是HBase的meta表是否有损，可以执行hbase hbck来确认。
为什么集群里没有新写入的数据，ALM-14000还是触发了？
因为HDFS的NameNode不只有写入压力,还有元数据缓存压力，大量小文件持续累积，哪怕没有新写入，DataNode的块报告也会周期性触发NameNode的元数据合并操作，当堆内存不够时，Full GC会拉高RPC延迟，继而触发ALM-14000告警。
老版本HDFS的安全模式一直无法退出，怎么处理？
安全模式无法退出通常意味着块副本率不达标或者元数据文件损坏,先执行hdfs dfsadmin -safemode get确认状态，然后检查fsck输出里的Missing replicas，如果缺失率低于0.1%，可以执行hdfs dfsadmin -safemode leave强制退出；如果缺失率较高，建议先重启DataNode，等块复制完成后，再执行hdfs dfsadmin -safemode leave，不要盲目强制退出，否则会导致HBase读写底层文件失败。
原创文章，发布者：酷盾叔，转转请注明出处：https://www.kd.cn/ask/558784.html
