某日接業(yè)務(wù)側(cè)反應(yīng)elasticsearch查詢速度很慢，偶爾出結(jié)果但是多數(shù)會(huì)超時(shí)，報(bào)錯(cuò){"statusCode":502,"error":"Bad Gateway","message":"Client request timeout"}

第一時(shí)間檢查手機(jī)短信，因?yàn)閑s集群節(jié)點(diǎn)服務(wù)掛掉會(huì)有告警產(chǎn)生的，檢查后發(fā)現(xiàn)并無告警發(fā)出。于是登錄服務(wù)器進(jìn)一步分析；

此es集群共計(jì)5個(gè)節(jié)點(diǎn)，逐一登錄服務(wù)器查看進(jìn)程和端口，發(fā)現(xiàn)所有進(jìn)程都在，9200端口也正常，也都有正常的連接.

于是模擬業(yè)務(wù)反應(yīng)的命令，使用kibana進(jìn)行查詢，發(fā)現(xiàn)確實(shí)timeout，此時(shí)查看kibana日志，并無明顯異常出現(xiàn)。

因近期集群內(nèi)新加入的業(yè)務(wù)較多，es集群為多個(gè)業(yè)務(wù)合用，于是第一反應(yīng)是kibana的內(nèi)存不夠，于是修改了kibana的jvm配置，并重啟kibana。此時(shí)發(fā)現(xiàn)啟動(dòng)kibana無法連接es集群。報(bào)錯(cuò)"warning","savedobjects-service"],"pid":26191,"message":"Unable to connect to Elasticsearch. Error: Request Timeout after 30000ms"}而且kibana的5601端口也打不開。

嘗試修改timeout參數(shù)由30000ms至60000ms，再次重啟報(bào)錯(cuò)依舊。于是懷疑es問題，再次使用9200端口逐個(gè)檢查es，發(fā)現(xiàn)所有節(jié)點(diǎn)的9200都正常（包括最好定位問題的194節(jié)點(diǎn)）。

此時(shí)使用_cat/nodes命令檢查，發(fā)現(xiàn)從其他節(jié)點(diǎn)看不到194節(jié)點(diǎn)。

于是懷疑問題出現(xiàn)在194節(jié)點(diǎn)，再次進(jìn)去194機(jī)器檢查，發(fā)現(xiàn)es的數(shù)據(jù)盤有一塊損壞,目錄/data10

因es集群有副本的機(jī)制，損壞一塊盤其實(shí)不影響數(shù)據(jù)的整體性的，但是這塊損壞的盤似乎導(dǎo)致了194節(jié)點(diǎn)的es服務(wù)hang死，被集群其他節(jié)點(diǎn)踢出，但是進(jìn)程和端口卻又依舊存在，導(dǎo)致了告警的失效。

為了盡快恢復(fù)服務(wù)，我們修改了194節(jié)點(diǎn)的es配置，將path.data:內(nèi)容注釋了data10這個(gè)損壞的路徑，然后重啟了194節(jié)點(diǎn)的es服務(wù)。

再次檢查_cat/nodes,發(fā)現(xiàn)已成功加入集群，登錄kibana也成功進(jìn)入。

通知業(yè)務(wù)查詢，已經(jīng)能夠跑出結(jié)果了。

此時(shí)的集群狀態(tài)為yellow，主要是損壞的盤中丟了副本，需要等待集群進(jìn)行數(shù)據(jù)的同步完成。

最終es集群同步完成，集群恢復(fù)為 green狀態(tài)。

1. elasticsearch的數(shù)據(jù)目錄故障會(huì)導(dǎo)致集群狀態(tài)異常，即使故障節(jié)點(diǎn)的服務(wù)和端口正常，甚至9200端口信息都正常；

2. 單純的進(jìn)程和端口告警已無法滿足監(jiān)控es集群的狀態(tài)了；

3. 定位問題后再回頭查看194的日志，其實(shí)能找到/data10的報(bào)錯(cuò)的，但排查問題時(shí)因節(jié)點(diǎn)數(shù)過多沒有仔細(xì)查看每個(gè)es服務(wù)日志的上下文

   

4. 后續(xù)考慮對(duì)磁盤報(bào)錯(cuò)也進(jìn)行監(jiān)控，從而避免這種因硬件故障導(dǎo)致的服務(wù)異常出現(xiàn)。

END

更多精彩干貨分享

點(diǎn)擊下方名片關(guān)注

IT那活兒