乍一看紅的不少挺嚇人，但仔細查看會發現，其實所有的報錯都指向同一處，node11節點。嘗試登錄無果，ping對應IP無反應。

這種情況下，基本斷定node11服務器異常宕掉了。本著老鳥的敏覺性，檢查hdfs可用性及數據塊，不過也不用過分擔心，畢竟咱是大數據平臺，掛一臺服務器不影響整體可用性。檢查確認所有hdfs數據塊顯示均為健康狀態，也意味著后臺數據并未受到任何影響，管理節點也已從node11節點成功漂移。

雖說只是測試環境，但畢竟是機器掛掉了，本著閉環服務思維，還是需要快速恢復的。說時遲，那時快，那時不如這時快，迅速掏出手機聯系主機側重啟服務器。服務器起來后迅速登錄，習慣性df一把，發現根目錄使用率100%。檢查使用詳情，發現某個測試應用程序跑飛了，又沒人看（測試環境都是這命啊），結果打了幾百G的日志。二話不說直接聯系應用側詢問是否可以直接清理，得到確認后，予以清理。

問題定位解決，雖然是大數據平臺，但是宕掉的機器服務還是需要恢復的，不然禁不起再垮一輪。恢復node11各個服務后，平臺恢復正常。但只是眨了一下眼，journalnode的綠色一閃而過，過后還是紅色依舊。

快速登錄服務器檢查journalnode日志，發現node11的journalnode服務有問題，一直在報錯檢測到valid length，進入journalnode的數據目錄，查看journalnode的edits時間，發現最新的并不是當前時間，與另外兩個journalnode時間不一致，且一直不刷新。

綜前分析，此前的根目錄滿導致node11節點最新的edits文件已經無法正常寫入，進而導致journalnode服務重啟，journalnode服務重啟后無法與另外的journalnode正常同步。

好在我們的journalnode有少數服從多數機制，停止有問題的node11節點的journalnode服務，直接mv掉node11節點的所有edits文件（注意只移走edits開頭文件，VERSION等其他信息需要保留，這可是身份信息，處理不當會導致同步edits失敗），然后再次啟動journalnode服務，發現node11已經可以與其他兩個節點正常同步了。

本次的故障解決完成，后續會繼續給大家帶來關于大數據平臺用到的相關組件的運維分享，敬請期待。