这是一个创建于 1553 天前的主题，其中的信息可能已经有所发展或是发生改变。
项目采用 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