有些事還是經歷過了才知道“小心駛得萬年船”的道理啊。最近筆者幫一個客戶安裝HDP2。6。5版本的大資料平臺，最重要的是，這次安裝的背景是生產環境的雲平臺遷移，不是普通的開發階段或者上線階段。
剛開始拿到系統，自然一片空白，因此有些掉以輕心了。由於是雲平臺且是新到位的環境，為了方便安裝，便直接開了全部網路訪問來安裝。經過一兩天的折騰（過程自不必詳述，不是本文的重點），終於完成一個master節點、一個standby節點+3個datanode節點的hdp安裝。由於經驗不足，加上工作疏忽，忘記了提醒客戶調整網路策略，於是兩天後悲劇就發生了。
最開始出現的症狀是，mapreduce任務和hive任務都跑的巨慢，
深入看看，發現有兩個問題，1。是yarn的nodemanger起不來，2是yarn資源管理上出現了一些奇怪的程序，如下：
很明顯，看到dr。who這麼異常的使用者，我們馬上感覺不對勁，各種百度找原因，最後確認我們中毒了。重點關注到的是下面的文章，但是很遺憾，沒用給出對應的解決方案。
網上找了一些資源，一開始就是蒙的，只能求助於雲平臺。雖然工作很久了，但是以前的Linux環境大多都是內部網路，第一次接觸到Linux中毒的情況。結果雲平臺又是斷網查殺，又是重啟，可是最終還是沒能解決我們的問題，唯一給出的訊息就是，經過診斷，三臺datanode中毒了，另外兩臺maser節點沒問題。當時距離遷移結束尚有四五天的時間，於是在苦惱兩天以後，決定重新安裝datanode。雲平臺給的建議也是重灌系統。
經過一番苦戰，我們把三臺datanode節點下線以後，直接重置系統，全部清空。然後安裝ambari-agent，讓ambari-server和ambari-agent建立通訊，在三個ambari-agent上初始化客戶端+datanode+nodemaneger等。初始化完成以後，也遇到一個問題，這裡也記錄一下。需要執行hdfs hadoop dfsadmin -safemode leave讓叢集離開安全模式，然後刪除丟失檔案的目錄。重新安裝以後，經過一番折騰，恢復資料和檔案，終於把叢集又執行起來了。
然而，命運總是喜歡開玩笑。在系統穩定執行一週後，由於雲平臺管理人員的失誤，本應針對應用伺服器開放8080埠的需求誤操作成對所有云平臺開放8080埠，於是已經在生成環境的伺服器再次出現故障，nodemanger每次一啟動就down掉。聯絡雲廠商，再次殺掉，折騰了一臺以後未見任何進展。我們利用週末時間翻遍了百度、谷歌、必應的各種文章以後，仍未找到合理的解決方案。
在週一即將到來、系統即將迎來大面積訪問的關頭，我們都做好了要再次重灌datanode的準備，然而另外一位同事部署的kafka程式及spark程式不願意再次配合修改，因此我們只能選擇再推遲一天重灌來解決此問題。
在週日的晚上十一點多，點的外賣到了一個多小時還沒吃的時候，我最後一次嘗試解除安裝一個節點的nodemanger然後重灌，在啟動的時候偶然遇到錯誤，提示裡面有dr。who的錯誤，讓我意識了這麼多次nodemanger一啟動就down掉並且不報錯可能跟這個病毒有關。
於是我開始在網上查詢相關資料。最有用的是下面這篇博文，https：//www。cnblogs。com/daxiangfei/p/9198856。html，然而內容過於簡單，只給瞭解題思路，沒用給解題步驟。
參照本文的說明，我現實在yarn使用者的crontab找到系統定時任務，雖然已經註釋，但是我還是手動刪掉了。
由於定時任務是yarn使用者的，根據經驗，我就開始檢視yarn使用者的程序，ps -ef|grep yarn，於是看到了四個很奇怪的程序，很明顯，這就是所謂的挖礦程式。二話不說，我就kill掉了四個程序，然後再次啟動nodemanger。在啟動過程中我還不是檢視yarn的使用者的程序，想看看是不是有命令會殺掉nodemanger經常。
結果就看到了，挖礦程式是伴隨這個nodemanger啟動的，這是，我有兩個懷疑，第一，這個挖礦程式修改了nodemanger啟動指令碼，嵌入到了nodemanger啟動過程中；第二，nodemanger容器中包含挖礦程式，導致nodemanger一啟動就要執行挖礦任務，“不堪重負累死了”。從表面上看第一個推理比較合理，於是我認真查詢挖礦程序對應的指令碼並且進行各種刪除，但是多次重啟以後還是存在挖礦程式同步啟動的情況。於是只能嘗試第二種思路，第二個設想從其它博文中看到一句命令後就驗證了。yarn top命令可以檢視yarn正在執行的程序。
這樣問題請很清晰了，大量的dr。who的挖礦程式在yarn佇列中是提交狀態，所以nodemanger一啟動就需要開始幹活，資源不足或者被挖礦程式搶佔了CPU資源所以導致nodemanger啟動後馬上就悄悄的死掉了。認識到來這一點，我開始查詢yarn的其他命令列以及怎麼殺死這些任務。
在嘗試幾次批次查殺後發現程序依然沒有減少，於是網上百度查詢yarn批次查殺程序的方法。
最後終於找到一個非常好用的命令。在我執行的時候，奇蹟出現，dr。who的程序在一個一個得減少，慢慢的mapreduce就出現了，再到後來全部是mapreduce任務和hive任務。這個命令真的很神奇，殺了一堆有害程序，但是對合理的程序全部保留。
# 刪除處於ACCEPTED狀態的任務
for i in `yarn application -list | grep -w ACCEPTED | awk ‘{print $1}’ | grep application_`； do yarn application -kill $i； done
這是我終於看到了曙光。我在保障所有節點的yarn使用者crontab裡面沒用定時任務以後，登入ambari開始啟動nodemanger。正當我點開頁面的時候，奇蹟出現了，所有的nodemanger滿血復活。
等我重新提交任務以後，yarn平臺也正是恢復正常，tez和mapreduce任務正常執行。
於是，在產生更嚴重的生產事故之前，hdp平臺就這樣被我修復了。經過一天的穩定執行，平臺也安然無恙。至此，我修復了一次重大的生成事故。
最後補充說一下，可能由於挖礦程式的升級，“檢查/tmp和/var/tmp目錄，刪除java、ppc、w。conf等異常檔案”這一條已經完全失效了，找不到任何對應的檔案。 總結一下，遠端木馬透過yarn的8080埠提交了包含挖礦程式的shell指令碼任務給yarn執行，yarn執行以後就產生了crontab定時任務和挖礦程序。由於木馬一次性提交了大量（大概一兩百個）的相同任務給yarn，所以殺死一兩個並不能解決問題，只有全部殺死，才能再次啟動nodemanger。
《資料中臺研習社》微信群，請新增微信：laowang5244，備註【進群】
分享、點贊、在看
，給個
三連擊
唄！
