資訊專欄INFORMATION COLUMN
事件背景
某日接業務側反應elasticsearch查詢速度很慢，偶爾出結果但是多數會超時，報錯{"statusCode":502,"error":"Bad Gateway","message":"Client request timeout"}
分析過程
第一時間檢查手機短信，因為es集群節點服務掛掉會有告警產生的，檢查后發現并無告警發出。于是登錄服務器進一步分析；
此es集群共計5個節點，逐一登錄服務器查看進程和端口，發現所有進程都在，9200端口也正常，也都有正常的連接.
于是模擬業務反應的命令，使用kibana進行查詢，發現確實timeout，此時查看kibana日志，并無明顯異常出現。
因近期集群內新加入的業務較多，es集群為多個業務合用，于是第一反應是kibana的內存不夠，于是修改了kibana的jvm配置，并重啟kibana。此時發現啟動kibana無法連接es集群。報錯"warning","savedobjects-service"],"pid":26191,"message":"Unable to connect to Elasticsearch. Error: Request Timeout after 30000ms"}而且kibana的5601端口也打不開。
嘗試修改timeout參數由30000ms至60000ms，再次重啟報錯依舊。于是懷疑es問題，再次使用9200端口逐個檢查es，發現所有節點的9200都正常（包括最好定位問題的194節點）。
此時使用_cat/nodes命令檢查，發現從其他節點看不到194節點。
于是懷疑問題出現在194節點，再次進去194機器檢查，發現es的數據盤有一塊損壞,目錄/data10
因es集群有副本的機制，損壞一塊盤其實不影響數據的整體性的，但是這塊損壞的盤似乎導致了194節點的es服務hang死，被集群其他節點踢出，但是進程和端口卻又依舊存在，導致了告警的失效。
為了盡快恢復服務，我們修改了194節點的es配置，將path.data:內容注釋了data10這個損壞的路徑，然后重啟了194節點的es服務。
再次檢查_cat/nodes,發現已成功加入集群，登錄kibana也成功進入。
通知業務查詢，已經能夠跑出結果了。
此時的集群狀態為yellow，主要是損壞的盤中丟了副本，需要等待集群進行數據的同步完成。
最終es集群同步完成，集群恢復為 green狀態。
總結結論
elasticsearch的數據目錄故障會導致集群狀態異常，即使故障節點的服務和端口正常，甚至9200端口信息都正常；
單純的進程和端口告警已無法滿足監控es集群的狀態了；
定位問題后再回頭查看194的日志，其實能找到/data10的報錯的，但排查問題時因節點數過多沒有仔細查看每個es服務日志的上下文
后續考慮對磁盤報錯也進行監控，從而避免這種因硬件故障導致的服務異常出現。
更多精彩干貨分享
點擊下方名片關注
IT那活兒
文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。
轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/129806.html
摘要：年月日本文是關于記錄某次游戲服務端的性能優化此處涉及的技術包括引擎隨著游戲導入人數逐漸增加單個集合的文檔數已經超過經常有玩家反饋說卡特別是在服務器遷移后從核降到核卡頓更嚴重了遂開始排查問題確認服務器壓力首先使用命令查看總體情況此時占用不高 Last-Modified: 2019年6月13日11:08:19 本文是關于記錄某次游戲服務端的性能優化, 此處涉及的技術包括: MongoDB...
摘要：年月日本文是關于記錄某次游戲服務端的性能優化此處涉及的技術包括引擎隨著游戲導入人數逐漸增加單個集合的文檔數已經超過經常有玩家反饋說卡特別是在服務器遷移后從核降到核卡頓更嚴重了遂開始排查問題確認服務器壓力首先使用命令查看總體情況此時占用不高 Last-Modified: 2019年6月13日11:08:19 本文是關于記錄某次游戲服務端的性能優化, 此處涉及的技術包括: MongoDB...
閱讀 1346·2023-01-11 13:20
閱讀 1684·2023-01-11 13:20
閱讀 1132·2023-01-11 13:20
閱讀 1858·2023-01-11 13:20
閱讀 4100·2023-01-11 13:20
閱讀 2704·2023-01-11 13:20
閱讀 1385·2023-01-11 13:20
閱讀 3597·2023-01-11 13:20
