search

alibaba / nacos

an easy-to-use dynamic service discovery, configuration and service management platform for building cloud native applications.
https://nacos.io
Apache License 2.0
30.29k stars 12.84k forks source link

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

Closed Kl0513 closed 4 months ago

Kl0513 commented 6 months ago

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

image image image image

bwangll commented 5 months ago

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

Kl0513 commented 5 months ago

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

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

KomachiSion commented 5 months ago

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

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

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

Kl0513 commented 5 months ago

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

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

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

1.nacos部署方式是采用jar 2.磁盘目前使用率50%多点： image

  1. 日志/var/log/message有排查过，宕机时间段没有异常日志 4.没有整体宕机，只是某一个节点宕机
KomachiSion commented 5 months ago

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

Kl0513 commented 5 months ago

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

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

KomachiSion commented 5 months ago

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

Kl0513 commented 5 months ago

这个是正常的， 及时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->最新版本

KomachiSion commented 5 months ago

怎么看都像是这台机器有问题。。 连接根本就打不进去吧。

Kl0513 commented 5 months ago

怎么看都像是这台机器有问题。。 连接根本就打不进去吧。

应该是nacos节点宕机后，客户端与集群其他节点建立了长连接（重启宕机节点会有1min最大间隔时间），导致该宕机节点客户端连接数为0；通过OpenAPI接口/nacos/v2/core/loader/current/reloadCurrent手动调节集群负载后，可以观察到该宕机节点是有客户端连接的，而且整个集群的其他机器也分别宕机过，所以是可以正常链接的 最近有个节点又宕机了，拿到了最新日志（nacos.log）： image image

KomachiSion commented 5 months ago

这日志就是nacos server收到了 kill 指令了，出发了shutdown hook， 这么看来反而证明了是系统杀掉了 nacos进程。 建议还是排查下系统日志，以及调整下jvm参数等。