Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

nacos集群某个节点每间隔1天左右宕机,问题持续近3天了,麻烦大佬们给个排查思路,感谢!!! #12108

Open
Kl0513 opened this issue May 15, 2024 · 8 comments

Comments

@Kl0513
Copy link

Kl0513 commented May 15, 2024

nacos版本:2.1.0
集群节点数:4个
服务器配置(aws-ec2):8核16G
JVM参数:-Xms4g -Xmx4g -XX:+UseG1GC,其他参数默认
问题补充:nacos宕机时,服务器CPU/内存/磁盘都是健康状态,nacos日志也未找到对应error信息,重启后服务又正常

image
image
image
image

@bwangll
Copy link

bwangll commented May 17, 2024

看一下/var/log/message日志?是不是内核kill的

@Kl0513
Copy link
Author

Kl0513 commented May 17, 2024

看一下/var/log/message日志?是不是内核kill的

在该目录下看了宕机当天日志,没有相关异常,都是一些如下信息:
image

@KomachiSion
Copy link
Collaborator

nacos只会在磁盘满的时候自杀, 其他任何情况下都不会自行宕机(至少进程会存在)。

如果出现了机器整体宕机,或者进程消失, 那么应该是操作系统(或者k8s)执行的kill。

如果通过/var/log/message等系统相关日志以及k8s状态排查未果, 可以考虑更换一下机器后重试。

@Kl0513
Copy link
Author

Kl0513 commented May 24, 2024

nacos只会在磁盘满的时候自杀, 其他任何情况下都不会自行宕机(至少进程会存在)。

如果出现了机器整体宕机,或者进程消失, 那么应该是操作系统(或者k8s)执行的kill。

如果通过/var/log/message等系统相关日志以及k8s状态排查未果, 可以考虑更换一下机器后重试。

1.nacos部署方式是采用jar
2.磁盘目前使用率50%多点:
image
3. 日志/var/log/message有排查过,宕机时间段没有异常日志
4.没有整体宕机,只是某一个节点宕机

@KomachiSion
Copy link
Collaborator

那估计还是系统环境本身的问题,或者机器故障了,建议换一台机器试一下。

@Kl0513
Copy link
Author

Kl0513 commented May 29, 2024

那估计还是系统环境本身的问题,或者机器故障了,建议换一台机器试一下。

nacos宕机时间段,config-fatal.log出现如下日志,有没有可能是mysql导致的啊? 或者说是否需要增加mysql连接超时时间?
image

@KomachiSion
Copy link
Collaborator

这个是正常的, 及时mysql有问题,nacos也不会宕机。
怀疑是机器故障了,建议换一个机器试试。

@Kl0513
Copy link
Author

Kl0513 commented May 31, 2024

这个是正常的, 及时mysql有问题,nacos也不会宕机。 怀疑是机器故障了,建议换一个机器试试。

关于机器故障的问题专门找aws的工程师看了,经过验证没有问题;而且该相同类型EC2实例,我们买了有近20台,不同实例上部署很多springcloud微服务全家桶、nacos、seata等服务,但就是nacos会自己宕机,所以机器有故障可能性很低。
其次,通过Grafana+Prometheus与nacos openAPI观测,怀疑可能是集群负载不均导致某个节点负载过大引发宕机,理由如下:
1.springcloud集成是通过ip直连方式(未使用SLB模式):spring.cloud.nacos.discovery.server-addr: ip1:8848,ip2:8848,ip3:8848,ip4:8848(共4个节点),很容易导致客户端与服务端长链接集中于某一个nacos节点
2.当某1个nacos节点宕机时 长链接断开,与该宕机节点原有链接客户端会与剩余3个节点建立长链接;最终导致宕机节点重启后负载为0
3.promethuse监控截图:
image
image
负载最高节点:
image

4.获取集群链接负载信息:curl -X GET http://ip:8848/nacos/v2/core/loader/current/cluster
image
补充下:我把4个节点的负载通过接口/nacos/v2/core/loader/current/reloadCurrent ,全部平衡到avg=39还是有节点宕机;但是宕机时刻系统或进程的内存/CPU/IO/磁盘/JVM gc都比较平稳,这就nacos负载过大导致宕机相悖了。哎!!!

通过上述监控指标,是否需要采用SLB模式部署,或者是升级nacos版本2.1.0->最新版本

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants