可以參考這個(gè)PR alibaba/spring-cloud-alibaba#671

Sentinel健康檢查包含：檢查控制臺(tái)(Dashboard)和數(shù)據(jù)源(DataSource)是否正常。 設(shè)計(jì)邏輯如下：

1、檢查控制臺(tái) （1) 如果沒有配置控制臺(tái)地址，則在明細(xì)里標(biāo)記dashbord狀態(tài)為UNKNOWN，描述信息為dashboard isn't configured （2) 如果配置了控制臺(tái)地址，則通過heartbeatSender#sendHeartbeat向控制臺(tái)發(fā)送一條心跳信息， 如果發(fā)送成功，則在明細(xì)里標(biāo)記dashbord狀態(tài)為UP; 如果失敗則在明細(xì)里標(biāo)記dashbord為DOWN，描述信息為控制臺(tái)地址 can't be connected

2、檢查數(shù)據(jù)源 獲取所有配置的數(shù)據(jù)源，對(duì)每個(gè)類型的數(shù)據(jù)源通過AbstractDataSource#loadConfig加載一次數(shù)據(jù)，如果沒有任何異常(即表示從數(shù)據(jù)源讀取數(shù)據(jù)正常)，則在明細(xì)里標(biāo)記該數(shù)據(jù)源狀態(tài)為UP，如果出現(xiàn)異常則在明細(xì)里標(biāo)記該數(shù)據(jù)源為DOWN 如果控制臺(tái)和數(shù)據(jù)源狀態(tài)有一個(gè)為DOWN，則Sentinel的健康狀態(tài)為DOWN，反之為UP。

可以排查下控制臺(tái)檢查失敗的原因，即為啥發(fā)送心跳失敗，在Sentienl-record日志里看看。 推測(cè)有可能跟Spring容器里Bean以及Sentinel(是否eager)加載順序有關(guān)。

當(dāng)時(shí)提了PR，本機(jī)簡(jiǎn)單自測(cè)了下看沒問題。平常在公司里都是做業(yè)務(wù)開發(fā)，沒有啥機(jī)會(huì)在項(xiàng)目中實(shí)踐，比如生產(chǎn)環(huán)境部署、容器化環(huán)境等等，其他情況沒能考慮到，非常抱歉因?yàn)榻】禉z查的原因給你使用上帶來了困擾。

這里有個(gè)issue討論健康檢查的設(shè)計(jì) alibaba/spring-cloud-alibaba#842 其中有提到，控制臺(tái)狀態(tài)不應(yīng)影響整個(gè)Sentinel的健康狀態(tài)。

issue里作者有建議兩種方式：

1、狀態(tài)永遠(yuǎn)是UP，但Dashbord那一段展示是否可連接

2、額外添加一個(gè)配置，控制是否檢查Dashboard是否可連接的狀態(tài)，并且默認(rèn)應(yīng)該設(shè)置為false 之前設(shè)計(jì)是因?yàn)榭紤]到，既然配置了控制臺(tái)地址，那么檢查跟控制臺(tái)是否連通，好像也符合邏輯，這樣能及時(shí)發(fā)現(xiàn)哪些應(yīng)用跟控制臺(tái)連接有問題。建議里狀態(tài)保持UP，通過明細(xì)的connectable屬性也能指示當(dāng)前控制臺(tái)是否可連。

個(gè)人覺得上面兩種建議也挺不錯(cuò)，希望能改進(jìn)和完善它

原回答者GitHub用戶cdfive

相關(guān)知識(shí)

Kubernetes健康檢查實(shí)戰(zhàn)：命令行方式監(jiān)控Pod狀態(tài)與性能優(yōu)化
Kubernetes下Java應(yīng)用的健康檢查機(jī)制
4、健康檢查
[云原生] Kubernetes（k8s）健康檢查詳解與實(shí)戰(zhàn)演示（就緒性探針 和 存活性探針）
k8s健康檢查 spring k8s健康檢查探針多個(gè)地址
微服務(wù)平臺(tái) TSF 健康檢查
spring boot 應(yīng)用在 k8s 中的健康檢查（一）
Kubernetes
如何為托管到SAE的應(yīng)用配置健康檢查
阿里云 健康檢查

網(wǎng)址: 當(dāng)我在Kubernetes集群部署Sentinel時(shí)，關(guān)于健康檢查出現(xiàn)的問題 http://m.u1s5d6.cn/newsview1195421.html