碰到过好几次这种服务器意外重启后HDFS核心服务挂掉的情况，结合你提到的Cloudera环境（scm-server和agent正常，但HDFS、Hive服务状态异常），咱们一步步来定位解决：

1. 先确认8020端口是否真的在监听 #

8020是HDFS NameNode的RPC通信端口，连接拒绝大概率是这个端口没被监听。先跑命令验证：

sudo netstat -tulpn | grep 8020
# 或者用更现代的ss命令
sudo ss -tulpn | grep 8020

如果没有任何输出，说明NameNode根本没启动起来，这时候直接去看NameNode的启动日志找原因。

2. 扒NameNode日志找启动失败根源 #

Cloudera环境下NameNode的日志默认在/var/log/hadoop-hdfs/目录，重点看hadoop-hdfs-namenode-$(hostname).log文件：

# 快速看最新的100行日志
tail -n 100 /var/log/hadoop-hdfs/hadoop-hdfs-namenode-$(hostname).log

常见的启动失败原因包括：

• 元数据损坏：fsimage和edits日志不匹配，这时候会在日志里看到类似corrupt edits的报错
• 权限错误：NameNode的工作目录/var/lib/hadoop-hdfs/dfs/name/权限不对，必须是hdfs:hdfs所属
• 磁盘空间不足：NameNode存储元数据的磁盘满了，导致无法加载元数据

3. 手动尝试启动NameNode并检查状态 #

既然Cloudera Manager显示服务状态异常，先手动启动NameNode试试：

sudo systemctl start hadoop-hdfs-namenode
# 查看启动状态
sudo systemctl status hadoop-hdfs-namenode

如果启动失败，根据报错信息处理：

• 若是元数据损坏，先执行文件系统检查：hdfs namenode -fsck /
• 若是edits日志问题，尝试恢复：hdfs namenode -recover

4. 修复NameNode后再处理Hive服务 #

HiveMetastore和HiveServer2完全依赖HDFS正常运行，所以先确保NameNode正常、8020端口能连上后，再处理Hive：

• 查看HiveMetastore日志：tail -n 100 /var/log/hive/hive-metastore-$(hostname).log
• 查看HiveServer2日志：tail -n 100 /var/log/hive/hive-server2-$(hostname).log
  手动启动Hive服务：

sudo systemctl start hive-metastore
sudo systemctl start hive-server2

5. 同步Cloudera Manager的服务状态 #

有时候scm-server和agent虽然运行正常，但服务状态会出现不同步。可以登录Cloudera Manager控制台操作：

• 进入HDFS服务页面，点击「操作」→「重启」，选择仅重启NameNode
• 待HDFS恢复后，再重启Hive相关服务
• 若还是有问题，先执行「操作」→「刷新配置」，再重新启动所有相关服务

6. 验证Datanode是否正常连接 #

NameNode启动后，确认Datanode是否成功注册：

hdfs dfsadmin -report

如果Datanode没连上，检查Datanode日志/var/log/hadoop-hdfs/hadoop-hdfs-datanode-$(hostname).log，常见原因是：

• 防火墙/网络规则限制了Datanode和NameNode的通信
• Datanode的VERSION文件（在/var/lib/hadoop-hdfs/dfs/data/current/下）里的clusterID和NameNode不匹配，这时候可以删除该文件后重启Datanode

内容的提问来源于stack exchange，提问作者Neha