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