oom-killer故障排查

上午上班路上發現系統異常，疑似發生故障，到了單位趕緊開始排查。

【排查步驟】

一看應用日誌zg.log和wc.log，發現資料庫凌晨3點半離線。

二看/var/log/secure，發現有世界各地的嗅探記錄，沒有特別的線索，但是應該要增加防護，避免被攻擊。這是後話。

三看/var/log/messages，發現裡面有OOM-killer，發生時間點在3:30:55，與wc.log中報錯的時間向差不遠，但是由於wc.js中沒有寫明錯誤發生時的具體時間，導致診斷問題時不能。應該用logger規範日誌。

oom-kiler是由mysqld觸發的，但是在我的伺服器上並沒有使用到這個進程。提交了工單詢問mysql有啥用，小哥回復這個進程沒有用了，可以關掉。

查看mg.log發現，存在server is very slow的描述。

【初步診斷】

因為前一天在dev上新部署了一個wc的docker，加上原有的mongo docker，有兩個docker在運行，推斷是資源不足導致的oom-killer。

【恢復服務】

重啟mongo docker：dcgo mongodb_mydb_01，啟動正常

重啟wc docker：wechatygo，啟動後會報timeout的錯誤。決定重新啟動操作系統。

重啟 linux

重啟mongo docker

重啟wc docker：一切正常。

【故障重現】

在www伺服器上啟動dc的批量計算和導出步驟。

用tail –f同時觀察wc.log和mg.log、/var/log/messages

結果：oom-killer被觸發，但這次不是mysqld觸發的。

【小結】

內存小是導致進程崩潰的直接原因。當內存不足時，引發oom-killer的可能並不是mongo，可能是其他進程。

啟動兩個docker對1G內存的伺服器來說，顯得很吃力。todo可以考慮使用公司法人賬號來申請免費資源，來跑高負載的應用。

dev伺服器上應該啟用安全訪問防護。

【改進】

wc失效的時候，應該發送簡訊通知管理員。

日誌都加上時間戳

優化部署方案

出現oom-killer的伺服器，都應重啟來充分釋放資源

【排錯思路SOP】

從上到下：應用程序日誌->資料庫日誌->操作系統日誌(messages、secure)

時間軸：按照故障時間點附近

多個日誌的內容結合分析，提出診斷意見

重現問題，驗證診斷意見

制定解決方案，特性層面，在日誌上增加時間戳；架構層面：將dc和wc部署在同一個伺服器，讓mongo在單獨伺服器上

【wc需改進】

接斷開disconnect的日誌中增加時間信息，便於診斷。

「收到event事件」要加上時間信息。

docker中若使用到主機名，則應該在docker中的/etc/host中增加ip地址和主機名的記錄。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！