場景
1.k8s微服務觸發重啟
容器配置的健康檢查採用actuator
curl 127.0.0.1:8080/actuator/health
2.容器重啟鉤子回撥
curl -X POST http://127.0.0.1:8080/actuator/shutdown
最終原因是因為呼叫第三方服務，超時設定3秒，重試3次，三方服務掛起導致tomcat連線池佔滿,健康檢查請求進不來
總結
反思當時
當時是使用者反饋才發現
1.首先觸發重啟需要進行告警
2.關於監測還需要透過error日誌激增來進行告警，其實日誌也有感知
3.呼叫其他服務還是需要熔斷降級，增對高併發場景，我們設定超時時間就算設定1秒，也會導致請求掛起一秒，
上熔斷降級，短期內大量異常，直接熔斷,過時間再少量嘗試，正常了再放開
經驗總結
當出現大面積超時排查步驟
1.結合jvm的執行緒來看當前活躍執行緒數量,主要看幾種執行緒狀態的數量 比如runable。
2.透過日誌量看error是否激增，差異是啥
3.有鏈路追蹤，可以結合鏈路追蹤檢視是否有大量耗時介面，和平均響應時間拉長,以及快速定位介面
4.結合資料庫掛起的慢查詢
執行緒狀態誤區
1.本質問題是執行緒佔滿了導致,後續服務恢復看執行緒數量飽和度還是較高如下圖
2.原因是這個服務是個併發較高的介面執行緒池有幾個核心引數 核心執行緒數量 最大執行緒數量 執行緒佇列 回收時間
3.其實這裡面大量的執行緒是TIme_Waiting的執行緒,如果是paring的非runable過程中等待的是正常的
還需要結合佇列中的任務數量
1.正常的
這種表示非核心執行緒在poll的時候嘗試拿任務,指定時間內拿不到就表示空閒，觸發回收(可以研究一下這裡原始碼)
2.掛起的
業務掛起的都能看出來run掛起的
