ABRTD進程引發(fā)ES血案的故事

IT那活兒發(fā)布于2023-01-11 13:20 / 3589人閱讀

故事描述

某通信集團割接，數(shù)據(jù)同步驗證日志一致性時，連接ES失敗，無法寫入和讀取，es數(shù)據(jù)寫入不了，影響最新日志入es，應用割接大部分廠商需要查詢最新的日志，間接影響到了割接進度,為了保障業(yè)務(wù)恢復，秉承先搶通后搶修原則，在上級領(lǐng)導及業(yè)務(wù)廠商溝通下，立即啟用應急處理措施，進行切換至災備ES,切換后索引讀寫正常，通知廠商恢復業(yè)務(wù)。

故事發(fā)生過程

晚上吃完飯，和同事一起趕現(xiàn)場做好支撐準備，我們說，今天割接非常順利，沒什么異常，早點回去休息，正要回去的時候，突然有個業(yè)務(wù)系統(tǒng)說，查詢?nèi)罩井惓＃覀凂R上查詢一下手機短信，未發(fā)現(xiàn)什么異常短信，是否是業(yè)務(wù)誤報，不管了，以‘飛奔‘的速度跑回現(xiàn)場，所有領(lǐng)導已在現(xiàn)場，下面我們就展開了一系列分析。

我們這套ES是6主機24節(jié)點的集群，專門提供業(yè)務(wù)日志寫入，打開kibana看所有集群節(jié)點也都正常，看狀態(tài)也是Green 。

但是集群寫入失敗，肯定存在問題，于是看看節(jié)點情況，結(jié)果節(jié)點的索引信息獲取失敗，ES集群命令已經(jīng)查不到ES集群節(jié)點信息及索引信息，此時需通過日志來分析為什么會如此。

分析ES集群日志，發(fā)現(xiàn)日志中最早的報錯信息發(fā)生在5點33分39秒左右，報錯信息為連接超時導致無法獲取集群和索引信息，并且其它節(jié)點也有超時現(xiàn)象

存在ES節(jié)點超時，就會觸發(fā)ES集群索引分片重新路由分配，分片移動到其它節(jié)點導致磁盤占比上升，引發(fā)es集群自動觸發(fā)提高磁盤水位，過高的IO和負載使整個集群Hang住，

此時ES級別分析完成，是185節(jié)點與集群通信失敗超時，處于假死狀態(tài)，而為什么185節(jié)點會這樣，我們進一步對操作系統(tǒng)進行分析，通過自動化運維平臺，發(fā)現(xiàn)6臺主機，有其中一個主機的負載故障前非常高，于是對操作日志進行分析，檢查操作系統(tǒng)messages信息，發(fā)現(xiàn)185存在系統(tǒng)守護進程abrtd異常導致連接數(shù)過多及主機hang現(xiàn)象，息abrtd: Too many clients, refusing connections to /var/run/abrt/abrt.socketAug 21 05:33:37 hnes09 kernel: INFO: task java:21133 blocked for more than 120 seconds.Aug 21 05:33:37 hnes09 kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.

我們通過日志發(fā)現(xiàn)引發(fā)這臺主機的‘罪魁禍首’是abrtd進程引起，而該進程是在操作系統(tǒng)BUG或異常情況會觸發(fā)，由于是開源的centos未有相應dump生成，只能先重啟主機解決。

重啟主機并重啟ES集群，查看 es日志顯示集群狀態(tài)正常，集群包含的6臺主機共24個節(jié)點正常加入集群，集群恢復正常，kibana訪問正常。為了防止后續(xù)重蹈覆轍，在其它的未發(fā)生故障的主機進行梳理，并停止abrtd進程服務(wù)，至此整個事件告一段落。

故事發(fā)生引發(fā)的思考

在我們未來的運維場景越來越復雜的情況下，開源組件會越來越多，業(yè)務(wù)使用開源的場景也會增多，單純的技術(shù)深度已無法滿足未來的需求，我們應該從架構(gòu)設(shè)計出發(fā)，在出現(xiàn)問題的時候架構(gòu)上做冗余，秉承‘業(yè)務(wù)優(yōu)先，先搶通后搶修’的原則，在日常運維中使用平臺工具代替手工勞作。真正意義實現(xiàn)’故障來了我不背鍋’。