spring health

為什么

我們新JavaScript客戶端應用程序會定期調用Grails后端的/health端點，以確定離線狀態。 事情開始變得“??有趣”。

我們免費獲得該端點，因為Grails基于Spring Boot，而Spring Boot帶有一個名為Spring Boot Actuator的子項目。

這給了我們許多端點 ，使我們可以監視我們的應用程序并與之交互，包括/health返回健康信息。

因此，我們的JS客戶端會檢查它是否可以到達此/health端點（每隔幾秒鐘執行一次），以確定用戶是在線還是離線。 沒什么好想的，以后我們可能會切換到僅使用Google主頁之類的東西，但是現在可以了。

健康檢查失敗

在localhost一切似乎總是很好，但是一旦我有了Jenkins管道，最終在每次構建后將應用程序部署到我們的測試服務器上，然后我們開始在那里驗證應用程序，一切就變得很有趣。

通常情況下，我們的通話情況非常好。

GET https://tst.example.com/health 200 () GET https://tst.example.com/health 200 () GET https://tst.example.com/health 200 () etc

每隔幾秒鐘，我們就會在Chrome檢查器中看到錯誤累積的情況。 運行狀況檢查將失敗，并且HTTP狀態代碼503 Service unavailable長時間503 Service unavailable 。

GET https://tst.example.com/health 503 () GET https://tst.example.com/health 503 () GET https://tst.example.com/health 503 () etc

過了一會兒，我們會再次接到好電話！

GET https://tst.example.com/health 200 () GET https://tst.example.com/health 200 () etc

這些失敗請求的響應只是說

{"status":"DOWN"}

從設計上來說，這不是很描述。

我當然沒有寫任何healh指標自己會這樣，為什么會“下降”？

經驗豐富的Spring Booters知道它將在類路徑上獲取任何運行狀況指示器，并且默認情況下帶有一些。 實際使用的是一個謎，因為默認情況下，Spring Boot將該端點歸類為“敏感”，因此不會向外界暴露太多信息。

我必須通過設置以下設置來使運行狀況檢查更加“簡陋”：

endpoints.health.sensitive: false

現在，手動調用端點即可顯示競爭者！

{"status":"DOWN","diskSpace":{"status":"DOWN","total":8579448832,"free":20480,"threshold":10485760},"db":{"status":"UP","database":"H2","hello":1} }

“關閉”的一般狀態是現在明確列出的（在本例中為2）自動配置的運行狀況指示器的匯總結果。

當我看到以下內容時，立即想到的是：

• 我為什么還沒有去除H2
• 嘿，測試服務器上的磁盤空間已經用完了嗎？

H2數據庫是所有Grails應用程序中的默認依賴項，但是我們的應用程序不使用它-不在生產環境中也不用于測試-因此，我們一定要從依賴項中刪除它。 不用擔心。

關于磁盤空間，這是很好的DiskSpaceHealthIndicator （實際上是自動配置的指示器的一部分 ），告訴我事情不健康 。

它的默認閾值為10485760字節或10 MB ，這是應該可用的最小磁盤空間。

而且……只有20 kb的可用空間？ 總共8場演出。

這是一個相當低的數字

在最初的0.7秒內，我不相信健康指標，您能想象嗎？

因此，我通過SSH進入測試服務器，以使用df實用程序檢查可用磁盤空間：

[Ted@server-01t ~]$ df -h Filesystem Size Used Avail Use% Mounted on /dev/mapper/rhel-root 8.0G 8.0G 20K 100% / ...

是的，至少健康檢查證明了事實的真相：實際上只剩下一小塊空間。

我將其轉給配置此機器的IT同事進行調查。 似乎早先的實驗中已經有一些Java堆轉儲占用了空間-有人告訴我將盡快刪除它。

最好也檢查其他節點。

[Ted@server-02t ~]$ df -h Filesystem Size Used Avail Use% Mounted on /dev/mapper/rhel-root 8.0G 5.3G 2.8G 66% /

那兒有足夠的空間。

等一下？ “其他節點？” 是的，我們有2個測試服務器01t和02t 。

那時，我意識到：我看到的行為是由于負載均衡器將請求轉發到tst.example.com到server-01t或另一個server-02t 。 其中之一是磁盤空間不足，這說明該服務器上Grails應用程序的運行狀況指示器顯示“關閉”，從而導致HTTP 503。

當通過Chrome Inspector觀察這些運行狀況調用（這些請求由我們的JS客戶端不斷發出）時，只剩下一個小問題：為什么我們會有（有時50倍）“漲”（ 200 ），然后一連串的“跌” ”（ 503 ），然后按照看似隨機的順序？

負載平衡器應使我們“固定”在JS客戶端首次發出請求的那個節點上，因為我們這樣配置服務器。

如果負載均衡器將每個請求 （發送給tst.example.com ）輪流發送給服務器1或2，我期望會有更多（隨機）響應，例如“ up” ， “ down” ， “ down” ， “ up” ，“ “向下” ， “向上” ， “向上” ， “向下” ， “向上” 。

好吧，在我觀察此行為的窗口期間，似乎團隊的其余成員仍在開發功能，并…推向Jenkins挑選的Git，并將其部署到兩臺服務器上。 由于將應用程序串行重新部署到ech服務器，因此負載平衡器“看到”該應用程序在一臺服務器上的不可用（具有足夠的磁盤空間： “ up” ， “ up” ， “ up” ， “ up” ， “ up” ” ）在部署期間將流量重定向到另一臺服務器 （幾乎沒有磁盤空間： “關閉” ， “關閉” ， “關閉” ））…

…不久之后就用新的WAR更新，并再次在另一臺服務器上結束請求（具有足夠的磁盤空間： “ up” ， “ up” ， “ up” ， “ up” ， “ up” ）。

再花3個小時浪費我的生命。 包括一些時間在這里記下這些東西（但我認為這是值得的）

學過的知識

了解你的過程

知道有一個負載均衡器和多個節點（以及它們如何工作）會有所幫助。 而且CI服務器不斷將新版本部署到正在調查的環境中并沒有幫助。 但是完全知道這確實有助于澄清觀察到的行為。

了解您的框架的“明智”默認設置。

如果使用Grails 3和Spring Boot，請了解從類路徑“自動配置”的內容 ，進行檢查并確保它確實是您想要的 。

我們將擺脫H2并檢查我們實際需要的運行狀況指標，可能會完全禁用自動配置。 我們清理了導致堆滿的Java堆轉儲。 我們已經再次確認Unix團隊將監視操作系統，包括磁盤空間，因此我們至少不再需要DiskSpaceHealthIndicator

翻譯自: https://www.javacodegeeks.com/2017/10/why-is-springs-health-down-down-up-up-up-and-down-again.html

spring health

總結

以上是生活随笔為你收集整理的spring health_为什么Spring的Health会再次向下，向下，向上，向上，向上和向下？...的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。