当我在Kubernetes集群部署Sentinel时，关于健康检查出现的问题
应用的健康检查 总是 DOWN 。经过观察 出现 "sentinel":{"status":"DOWN","details":{"dataSource":{},"enabled":true,"dashboard":{"description":"sentinel:8858 can't be connected","status":"DOWN"}} 但是我的确能在Sentinel-dashboard中观察到我的应用，并且它是正常的。但是因为健康检查的原因 导致Kubenetes的livenessProbe/readinessProbe都失败了。应用出现无限重启。 只有当我请求过一次应用后，健康检查才会变为 UP。 我现在的解决方法是 设置 management.health.sentinel.enabled=false 关闭Sentinel相关健康检查。
我希望只要能够在第一次应用健康检查中出现 UP ，或者能否告知我 ，为什么要设计成这种模式。
1、Sentinel version 1.7.0-1.7.2 SpringBoot 2.2.5 SpringCloud Hoxton.SR3
原提问者GitHub用户bbqtk
写回答
-
可以参考这个PR alibaba/spring-cloud-alibaba#671
Sentinel健康检查包含：检查控制台(Dashboard)和数据源(DataSource)是否正常。 设计逻辑如下：
1、检查控制台 （1) 如果没有配置控制台地址，则在明细里标记dashbord状态为UNKNOWN，描述信息为dashboard isn't configured （2) 如果配置了控制台地址，则通过heartbeatSender#sendHeartbeat向控制台发送一条心跳信息， 如果发送成功，则在明细里标记dashbord状态为UP; 如果失败则在明细里标记dashbord为DOWN，描述信息为控制台地址 can't be connected
2、检查数据源 获取所有配置的数据源，对每个类型的数据源通过AbstractDataSource#loadConfig加载一次数据，如果没有任何异常(即表示从数据源读取数据正常)，则在明细里标记该数据源状态为UP，如果出现异常则在明细里标记该数据源为DOWN 如果控制台和数据源状态有一个为DOWN，则Sentinel的健康状态为DOWN，反之为UP。
可以排查下控制台检查失败的原因，即为啥发送心跳失败，在Sentienl-record日志里看看。 推测有可能跟Spring容器里Bean以及Sentinel(是否eager)加载顺序有关。
当时提了PR，本机简单自测了下看没问题。平常在公司里都是做业务开发，没有啥机会在项目中实践，比如生产环境部署、容器化环境等等，其他情况没能考虑到，非常抱歉因为健康检查的原因给你使用上带来了困扰。
这里有个issue讨论健康检查的设计 alibaba/spring-cloud-alibaba#842 其中有提到，控制台状态不应影响整个Sentinel的健康状态。
issue里作者有建议两种方式：
1、状态永远是UP，但Dashbord那一段展示是否可连接
2、额外添加一个配置，控制是否检查Dashboard是否可连接的状态，并且默认应该设置为false 之前设计是因为考虑到，既然配置了控制台地址，那么检查跟控制台是否连通，好像也符合逻辑，这样能及时发现哪些应用跟控制台连接有问题。建议里状态保持UP，通过明细的connectable属性也能指示当前控制台是否可连。
个人觉得上面两种建议也挺不错，希望能改进和完善它
原回答者GitHub用户cdfive
2023-05-19 20:53:45赞同 展开评论 打赏
版权声明：本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。
阿里云拥有国内全面的云原生产品技术以及大规模的云原生应用实践，通过全面容器化、核心技术互联网化、应用 Serverless 化三大范式，助力制造业企业高效上云，实现系统稳定、应用敏捷智能。拥抱云原生，让创新无处不在。
