项目采用 consul 作为注册中心, 服务跑了一段时间后,某些服务就从注册中心消失,无法被其他服务访问,但服务本身还是正常的,内部直接 /actuator/health 返回的也是 UP
消失基本都是在服务接收到大量外部连接的时候。
该怎么排查这个问题,目前没有日志看到服务注册断开。
项目采用 consul 作为注册中心, 服务跑了一段时间后,某些服务就从注册中心消失,无法被其他服务访问,但服务本身还是正常的,内部直接 /actuator/health 返回的也是 UP
消失基本都是在服务接收到大量外部连接的时候。
该怎么排查这个问题,目前没有日志看到服务注册断开。
1
tms Jul 16, 2021
看 consul 的健康检查日志
|
2
fkdog Jul 16, 2021
info 里没记录那就临时切到 debug 级别看 warning 和 debug 信息.
|
3
th00000 Jul 16, 2021
线上跑了好久了 没出过你这个问题, Consul 如果健康检查通过应该不会出现摘掉服务的情况
你访问 health check api 没问题的时间不代表 Consul 访问的时候没问题 服务流量大的时候 health check api 可能来不及响应 你应当先查服务的监控, 看当时 CPU 占用是怎样的, JVM 是怎样的, GC 有没有问题, 有没有 STW 时间过长, 超过了 health check 的 timeout |
4
xuanbg Jul 17, 2021
应该是你的健康检查某些时候没有响应造成的。我遇到过的是邮件服务的健康检查超时造成服务间歇性下线,后来在配置里面把邮件的健康检查 disable 就好了。
|
5
jimmyismagic OP |
6
th00000 Jul 19, 2021
@jimmyismagic #5 关于 Consul health check 超时后的重连接, 建议你阅读以下官方文档, 应该都有写
关于 4 楼的 disable health check 的做法, 在线上环境是万万不可的 |
7
tms Jul 19, 2021
@jimmyismagic consul 端临时切换到 debug 的 log 级别才能看到 health check 日志。不过根据你说的,估计是代码逻辑造成的问题了,按理来说 health check api 不应该因为其他业务逻辑时间长来不及响应。
|
8
jimmyismagic OP @tms 已知的问题就是连接过多,一旦过多,就会注册丢失,但是问题是,丢失之后就不会有其他连接进来,负载也变小,但就是无法注册上
|
9
NCE Jul 19, 2021
看下调用方是否有超时熔断策略。
我猜测你的服务没有做压力测试就上线了。 |
10
ThisDay Jul 20, 2021
检查下是不是有这个配置项 health-check-critical-timeout: 60s
|
11
tms Jul 20, 2021
@jimmyismagic 首先确认服务是否有主动重新注册,再看 consul 是否拒绝了注册。
|