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

[bwangll]

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

[Kl0513]

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

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

[KomachiSion]

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

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

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

[Kl0513]

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

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

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

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

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

[KomachiSion]

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

[Kl0513]

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

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

[KomachiSion]

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

[Kl0513]

这个是正常的， 及时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监控截图：


负载最高节点：

4.获取集群链接负载信息：curl -X GET http://ip:8848/nacos/v2/core/loader/current/cluster

补充下：我把4个节点的负载通过接口/nacos/v2/core/loader/current/reloadCurrent ，全部平衡到avg=39还是有节点宕机；但是宕机时刻系统或进程的内存/CPU/IO/磁盘/JVM gc都比较平稳，这就nacos负载过大导致宕机相悖了。哎！！！

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

[KomachiSion]

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

[Kl0513]

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

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