事故背景交代：
滌生大數(shù)據(jù)花費重金購得幾臺較高配置的阿里云服務(wù)器機器，構(gòu)建了一整套以cdh為核心的大數(shù)據(jù)課程教學(xué)、學(xué)員實操練習(xí)環(huán)境、但是，就是這個但是，以為集群規(guī)模目前相對較小。不會有什么幺蛾子發(fā)生，于是運維中最核心的監(jiān)控沒并有完善到集群。

事故發(fā)生：

2023年4月18日的清晨，在企業(yè)微信溝通群中，我們的spark課程大佬健哥反饋說我們內(nèi)部使用的wiki服務(wù)出現(xiàn)編輯內(nèi)容后保存報錯的問題，這里做個說明，為了讓小白學(xué)員有真實的企業(yè)操作環(huán)境體驗，我們在管理學(xué)員上使用的現(xiàn)在大多數(shù)公司使用的wiki服務(wù)。

問題排查一：

基于以上wiki服務(wù)的報錯，一開始懷疑是網(wǎng)絡(luò)的問題，首先查看了阿里云的網(wǎng)絡(luò)監(jiān)控，再次查看了我們的vpn服務(wù)監(jiān)控（因為我們在集群安全防護上，是將所有的主機服務(wù)都隱藏在阿里云內(nèi)網(wǎng)的，學(xué)員的對教學(xué)環(huán)境資源的訪問都是需要通過VPN認證登錄）還有其他內(nèi)部服務(wù)的訪問也都是沒有問題的，這足以說明網(wǎng)絡(luò)上是健康的。

于是打算登錄通過jumpserver服務(wù)登錄主機（這里做一個說明：我們提供給學(xué)員的練習(xí)平臺是完全cp中小型企業(yè)的實際操作環(huán)境的，有基于web的【滌生數(shù)據(jù)開發(fā)平臺】，也會有基于centos7系統(tǒng)的終端下shell 指令的練習(xí)操作，這一步就需要通過跳板機的認證授權(quán)，登錄到特定的主機），通過檢查wiki的服務(wù)日志來定位問題，此時發(fā)現(xiàn)jumpserver服務(wù)登錄也出現(xiàn)的問題，無法正常登錄，此時想起來，jumpserver服務(wù)和wiki服務(wù)是在一臺主機上部署的，多年運維的直覺告訴我，有可能是主機層面出現(xiàn)問題了。才會有兩個服務(wù)同時故障。于是立馬通過cm的控制臺查看主機資源的指標狀態(tài)，一看嚇一大跳，此刻文字表達不出（我草），各位看官請看下圖：

于是只能通過后門（登錄主機，基于管理員用戶留有后門，以備在jumpserver出現(xiàn)異常情況下登錄主機排查問題）登錄其中一臺主機（這里當然是jumpserver和wiki服務(wù)所在主機）通過df -h指令一看，果然所有的磁盤都被寫滿，慶幸的是主機還沒有完全卡死，常規(guī)的運維指定還可以正常操作。于是發(fā)現(xiàn)磁盤寫滿是因為datanode的數(shù)據(jù)目錄存儲很大導(dǎo)致，由此判斷是有異常的大文件被寫入hdfs存儲系統(tǒng)，將整個hdfs的存儲容量打滿了。

處理問題：

既然問題已經(jīng)找到，此時只需要確認hdfs寫入的大文件，然后刪除大文件就可以解決問題，于是執(zhí)行了最常規(guī)的操作指令

hdfs dfs -count -s hdfs:///

報錯，尷尬了，因為所有的磁盤寫滿了，所有整個hadoop集群的服務(wù)也受到影響，導(dǎo)致整個集群都掛了，于是眼下之急只能是擴充磁盤容量或者從主機層面直接釋放磁盤容量。

說干就干，擴充磁盤容量是不可能了，因為老板沒錢?。?strong>多推薦點學(xué)員，看官老爺們），具體查看磁盤的存儲文件，發(fā)現(xiàn)其他的日志文件也占據(jù)不小的存儲空間，（簡直就是看到了救命稻草），刪除此部分文件，應(yīng)該可以恢復(fù)磁盤的正常讀寫，進而將整體服務(wù)拉起來，后面也就迎刃而解了。

果然，和我們預(yù)料的一樣，磁盤在釋放出來一定量的存儲空間后，wiki服務(wù)，jumpserver服務(wù)都可以正常運作，唯獨（此處眼中已經(jīng)泛起了淚花）在拉起hdfs集群時namenode不能正常拉起。

問題排查二：

既然namenode不愿意正常運行，坑定是哪里出現(xiàn)了毛病，那不怕，咱干的就是這個，哪里有問題，就修哪里。

最常規(guī)的排查思路，看日志，只要日志看的好，80%的問題基本都能解決了。果不其然，日志中顯示，namenode一開始是可以正常拉起的，但是在拉起一段時間后其中一個節(jié)點就掛掉了，而且從日志中可以發(fā)現(xiàn)，問題出現(xiàn)在HDFS啟動時無法拉取JournalNode對應(yīng)的數(shù)據(jù)，應(yīng)該是JournalNode服務(wù)出現(xiàn)異常，于是通過查看JournalNode的服務(wù)日志繼續(xù)深扒問題，于是乎，有了下面一段重要日志的出現(xiàn)：

從上面的日志文件中可知，因為是磁盤寫滿導(dǎo)致的JournalNode宕機，所以導(dǎo)致了JournalNode維護的edits文件損壞。

重點提示：HDFS啟動如果報錯是拉取JournalNode對應(yīng)的數(shù)據(jù)異常，此類錯誤的原因大概率為JournalNode異常。

我們可以基于以下三點來排查處理問題：

觀察JournalNode的啟動狀態(tài)和日志。

? ? ? ? ?如果JournalNode的日志無明顯異常，可考慮NameNode節(jié)點到JournalNode節(jié)點的網(wǎng)絡(luò)聯(lián)通性。

? ? ? ? ?如果JournalNode出現(xiàn)上述異常日志，可以在集群中找到一個健康的JournalNode節(jié)點并通過將此節(jié)點上數(shù)據(jù)全部復(fù)制到其他節(jié)點來修復(fù)其他異常的JournalNode節(jié)點。

? ? ? ? ?如果JournalNode出現(xiàn)上述異常日志，且所有的節(jié)點都出現(xiàn)異常，此時需要刪除其中一個節(jié)點以edits_inprogress開頭的文件，然后同步所有的文件到其他JournalNode節(jié)點。

最終解決：

本次集群的故障就是所有的JournalNode節(jié)點的數(shù)據(jù)文件發(fā)生損壞，處理手段也是刪除其中一個節(jié)點的edits_inprogress開頭的文件，然后同步到其他所有JournalNode節(jié)點，重啟整個集群后，集群正常運行。

然后定位到hdfs的異常文件，刪除此文件，磁盤恢復(fù)正常存儲水平。所有服務(wù)恢復(fù)正常運行。

問題復(fù)盤：

復(fù)盤本次事故的原因，觸發(fā)點很簡單，就是沒有及時監(jiān)控主機磁盤，導(dǎo)致磁盤寫滿，進而引發(fā)一連串的問題發(fā)生，所以基于此，我們眼下需要做的就是完善告警機制。于是就安排起來了。

這里我們選用的也是當下比較火的三個搭檔promethues+grafana+altermanager（小廣告打一波：滌生大數(shù)據(jù)的運維課程體系中有關(guān)于這三個組件的詳細使用教程以及詳細的企業(yè)實戰(zhàn)案例，有需要的老鐵可以私聊）

自定義webhook對接altermanager，通過企業(yè)微信機器人發(fā)送實時告警。

結(jié)尾：

手擼webhook python小代碼分享一波。

更多關(guān)于大數(shù)據(jù)集群運維、優(yōu)化、升級等相關(guān)問題的交流，可以關(guān)注我們的公眾號：滌生大數(shù)據(jù)