0023-HOSTS配置问题导致集群异常故障分析

本文涉及的产品
日志服务 SLS,月写入数据量 50GB 1个月
注册配置 MSE Nacos/ZooKeeper,118元/月
服务治理 MSE Sentinel/OpenSergo,Agent数量 不受限
简介:

温馨提示:要看高清无码套图,请使用手机打开并单击图片放大查看。

1.问题现象

Hadoop集群HDFS、YARN、Hive等服务出现异常告警

重启集群异常告警任然存在大量告警

Cluster 1

HDFS

可用空间抑制...

NameNode 运行状况抑制...
HDFS 金丝雀抑制...

DataNode (ip-172-31-10-118) 日志文件

NameNode 连接抑制...

DataNode (ip-172-31-5-190) 日志文件

NameNode 连接抑制...

DataNode (ip-172-31-9-33) 日志文件

NameNode 连接抑制...

Hive Metastore Server (ip-172-31-6-148)  日志文件

Hive Metastore Canary 抑制...

Impala Daemon (ip-172-31-10-118)  日志文件

进程状态抑制...

Impala Daemon (ip-172-31-5-190)  日志文件

进程状态抑制...

Impala Daemon (ip-172-31-9-33)  日志文件

进程状态抑制...

NameNode (ip-172-31-6-148) 日志文件

安全模式状态抑制...

Server (ip-172-31-5-190) 日志文件

Quorum 成员资格抑制...

Zookeeper服务“Quorum 成员资格”告警

CM节点上的所有服务的角色日志不能正常通过ClouderaManager控制台查看,显示如下错误:

2.问题复现

集群环境:

  • CDH5.12.0
  • 集群服务(HDFS/Hive/YARN/Zookeeper/Hue/Impala/Kudu/Oozie)

1.还原现场配置,所有服务器hosts配置文件配置

127.0.0.1   ip-172-31-10-156.ap-southeast-1.compute.internal
127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6

172.31.8.141 ip-172-31-8-141.ap-southeast-1.compute.internal
172.31.1.175 ip-172-31-1-175.ap-southeast-1.compute.internal
172.31.9.186 ip-172-31-9-186.ap-southeast-1.compute.internal
172.31.10.156 ip-172-31-10-156.ap-southeast-1.compute.internal

配置中的第一行配置为多出的异常配置。

在主机上ping自己的hostname显示

2.重启集群服务

CM出现如下大量告警

Cluster 1

HDFS
可用空间抑制...
    NameNode 运行状况抑制...
    HDFS 金丝雀抑制...
DataNode (ip-172-31-10-118)  日志文件
NameNode 连接抑制...
DataNode (ip-172-31-5-190)  日志文件
NameNode 连接抑制...
DataNode (ip-172-31-9-33)  日志文件
NameNode 连接抑制...
    Hive Metastore Server (ip-172-31-6-148)  日志文件
Hive Metastore Canary 抑制...
HiveServer2 (ip-172-31-6-148)  日志文件
进程状态抑制...
    Impala Daemon (ip-172-31-10-118)  日志文件
进程状态抑制...
    Impala Daemon (ip-172-31-5-190)  日志文件
进程状态抑制...
    Impala Daemon (ip-172-31-9-33)  日志文件
进程状态抑制...
NameNode (ip-172-31-6-148)  日志文件
安全模式状态抑制...
Server (ip-172-31-5-190)  日志文件
Quorum 成员资格抑制...
    ip-172-31-10-118
代理状态抑制...
    ip-172-31-5-190
代理状态抑制...
    ip-172-31-9-33
代理状态抑制...

Zookeeper与现场告警一致,且Zookeeper服务如下状态

在查看CM节点的日志出现如下异常“Connection refused”

Host列表监控状态

3.问题原因

集群在运行正常的情况下,所有节点的hosts文件被修改为127.0.0.1导致

4.解决方法

修改所有节点的hosts文件,将127.0.0.1行配置注释

重启集群服务恢复正常;

醉酒鞭名马,少年多浮夸! 岭南浣溪沙,呕吐酒肆下!挚友不肯放,数据玩的花!

温馨提示:要看高清无码套图,请使用手机打开并单击图片放大查看。

推荐关注Hadoop实操,第一时间,分享更多Hadoop干货,欢迎转发和分享。


原创文章,欢迎转载,转载请注明:转载自微信公众号Hadoop实操

相关实践学习
基于MSE实现微服务的全链路灰度
通过本场景的实验操作,您将了解并实现在线业务的微服务全链路灰度能力。
相关文章
|
28天前
|
Kubernetes 安全 Docker
在K8S中,在服务上线的时候Pod起不来怎么进行排查?
在K8S中,在服务上线的时候Pod起不来怎么进行排查?
|
28天前
|
Kubernetes Docker Perl
在K8S中,如果是因为开发写的镜像问题导致pod起不来该怎么排查?
在K8S中,如果是因为开发写的镜像问题导致pod起不来该怎么排查?
|
29天前
|
Prometheus Kubernetes 监控
在K8S中,如何排查与解决Pod频繁重启的问题?
在K8S中,如何排查与解决Pod频繁重启的问题?
|
4月前
|
存储
NameNode 故障无法重新启动解决方法
当NameNode进程挂掉时,若无数据丢失,可直接使用`hdfs --daemon start namenode`重启。但若数据丢失,需从SecondaryNameNode恢复。首先查看启动日志,确认因数据丢失导致的未启动成功问题。接着,将SecondaryNameNode的备份数据拷贝至NameNode的数据存储目录,目录路径在`core-site.xml`中设定。进入NameNode节点,使用`scp`命令从SecondaryNameNode复制数据后,重启NameNode进程,故障即可修复。
|
11月前
|
运维 Java 调度
预发部署时机器总是重启两次的“简单”排查
本文只是总结下线上问题的排查过程,不讲方法论,没有大道理,行文会较为随意,注重的是排查思路,希望对同学们日常研发工作有所帮助~
107817 25
|
安全 Linux 网络安全
Kibana 最常见的“启动报错”或“无法连接ES集群服务”的故障原因及解决方案汇总
Kibana 最常见的“启动报错”或“无法连接ES集群服务”的故障原因及解决方案汇总
Kibana 最常见的“启动报错”或“无法连接ES集群服务”的故障原因及解决方案汇总
|
存储 弹性计算 监控
Logtail心跳问题排查手册(主机场景)
机器组有心跳是Logtail正常运行的重要基础,然而,机器组无心跳却是Logtail使用过程中非常常见的问题。事实上,这一类问题的排查有一套非常系统的流程,绝大多数问题均可在这个排查过程中得以解决。因此,本文将重点介绍如何系统排查主机场景下的机器组无心跳问题。
258 0
|
4月前
|
数据采集 监控 应用服务中间件
使用CloudLens排查iLogtail文件重复配置问题
本文主要介绍如何使用CloudLens for SLS定位和解决iLogtail日常使用中的常见问题之一:重复采集配置问题。
374 0
使用CloudLens排查iLogtail文件重复配置问题
服务启动失败排查方案
本篇文章带你从几大方面排查服务启动失败的问题
服务启动失败排查方案