我不在的大半年，大資料服務基本沒問題，只過來維護過一兩次
2024年大半年，大資料服務都比較穩定，我也只過來維護過一兩次。8月份我又過來了，交接完離職同事的工作，本來沒什麼事情。
StatHub頁面服務狀態不重新整理
StatHub是一個叢集管理/應用編排/程序守護工具，可以用來高效的管理服務叢集。具有節點程序管理和應用管理功能。
StatHub包括master和agent兩個部分：
stat-server，即master，提供服務編排介面。
stat-agent，執行在工作節點，守護工作程序。
StatHub原始碼地址：https://github.com/rm-vrf/stat
在這工作的另一家公司的大資料研發說，StatHub頁面服務狀態不重新整理。我說你的服務是正常的嗎？他說是正常的。我說不用管它，等哪天有空我再看看。
完蛋了，刪了不該刪的資料夾
閒下來之後，我就嘗試解決StatHub的問題。其實以前是有解決方案的，就是查詢各伺服器節點上的.stat_agent資料夾中的app和proc資料夾中的大小為0的檔案並刪除，就可以了。
但是我一時半會沒想起來這個解決方案，於是想著透過重啟解決，我重啟了不正常節點的stat-agent，又多次重啟了stat-server，都不行。
我想，是不是什麼快取造成的，.stat_server這個資料夾最開始部署StatHub的時候肯定是不存在的，它應該是自動生成的，我先停了stat-server，再把它刪了，然後重啟試試。於是，我就這樣刪除了.stat-server，重啟StatHub成功，.stat-server資料夾又自動重新生成了。但是很快我就發現了一個嚴重問題，StatHub頁面上的那100多個服務全沒了！頁面空了！
跑路吧，要失業了，臥槽！
雖然100多個服務脫離管理了，但服務應該都還是在正常執行的，只要服務不掛，一時半會是沒有問題的。
怎麼辦？恢復資料？那個伺服器很重要，上面跑了不少重要的服務，萬一搞壞了，就真的完了。
找到方法，慢慢恢復StatHub頁面的服務管理
好在，我發現stat-agent所在的20多臺伺服器上的.stat_agent資料夾中的proc資料夾中的各服務的程序資訊都在(另一個重要的app資料夾在stat-server重啟後被自動清空了)，那裡面有服務的名稱和啟動命令，可以用來在StatHub頁面中重新錄入服務資訊，主要是啟動引數，因為有些java和spark服務的啟動引數比較複雜。於是我把20多臺伺服器上的proc資料夾中的服務名稱和啟動命令做了備份。然後，先恢復了2、3個服務的管理，但是服務狀態重新整理不出來，也無法正常停止和啟動服務，我只能到服務所在機器上，敲Linux命令檢視服務執行狀態。
修改StatHub原始碼，解決服務狀態不正常的問題
開啟StatHub的原始碼，發現遍歷各節點資訊時，加了try catch，但只catch了ResourceAccessException異常，其它異常會導致for迴圈掛了，所有節點和程序資訊都獲取失敗了。所以我修改了程式碼，加了一個catch (Exception e)，並列印日誌，提交，重新發布啟動stat-server，檢視stat-server日誌，確定了異常節點，把異常節點伺服器上的大小為0的檔案刪除，服務狀態就正常了。
又出現新情況，StatHub頁面節點列表中162這臺機器的節點資訊不見了
因為某原因重啟162節點上的stat-agent後，StatHub頁面節點列表中162這臺機器的節點資訊不見了。最後發現是伺服器出了問題，mount命令，卡一會，一堆掛載，不知為何。df -hl命令也會卡一會才出來資訊，這個問題導致stat-agent遍歷磁碟資訊時，卡住了。
ClickHouse也出問題了，一個服務插入資料時頻繁報Too many parts異常
之前解決過一次，思路就是增加每次批次插入的資料量，以減少插入次數。當時服務暫時穩定了，我以為解決了，其實並沒有解決。服務消費的kafka的topic共有78個分割槽，rdd.foreachPartition的並行度是78，太大了，怎麼減少並行度呢？當時我並不知道怎麼解決。這次，我把程式碼改成了rdd.coalesce(1).foreachPartition，coalesce的作用是減少分割槽，這樣就可以減少資料插入ClickHouse的並行度，我把並行度設定為1。按理說問題應該解決了，但還是報Too many parts異常，資料插入成功幾次失敗幾次。
重啟ClickHouse
沒有什麼是重啟解決不了的，如果不行，就再重啟一次。
於是我就決定重啟4個節點的ClickHouse服務。
重啟第3個節點時，伺服器突然失聯，我就重啟個ClickHouse就把伺服器搞掛了？好在有驚無險，過了一會，又連上了。
重啟第4個節點時，發現起不來了啊！檢視監控頁面，發現所有寫入ClickHouse的服務，都報紅了！我又重啟了依賴的zookeeper服務，又多次重啟了ClickHouse，都不行。
部分報錯資訊：DB::Exception: The local set of parts of table 'xxx' doesn't look like the set of parts in ZooKeeper: xxx billion rows of xxx billion total rows in filesystem are suspicious. ... Cannot attach table 'xxx' from metadata file /var/lib/clickhouse/metadata/xxx/xxx.sql from query ATTACH TABLE ...
百度搜到一個類似問題https://support.huaweicloud.com/intl/zh-cn/trouble-mrs/mrs_03_0281.html，步驟太多，沒太看明白，不敢操作。
解決問題，重啟ClickHouse成功
我注意到報錯資訊中的metadata file，心生一計，把錯誤日誌中提到的那兩個.sql檔案改名成xxx.sql.bak備份一下，然後重啟ClickHouse，成功了！然後把那兩個檔案又改名回來。然後觀察那些寫入ClickHouse的服務，全都正常了，部分服務失敗了沒有自動重啟就手動重啟了一下。然後發現Too many parts的問題也解決了。
162伺服器也正常了
另一家公司的大資料研發，經過準備工作，重啟了這臺機器解決了問題。
StatHub頁面的服務管理恢復了大半
經過這幾天的手動錄入，StatHub頁面的服務管理恢復了大半。
我把stat-server所在伺服器上的.stat_server資料夾中的app和choreo資料夾做了備份。以前沒想到這個資料夾如此重要，也沒想過會被刪，從來沒有備份過。
剩下的服務，慢慢錄入，或者等服務出問題需要重啟的時候再錄入也行。
這一個多星期的工作是無中生有嗎？
也不全是
- StatHub頁面服務狀態不正常，還是需要處理的。但是我犯了錯誤，把不該刪的資料夾刪除了。經過這次教訓，我做了備份(後來全域性搜尋一個檔案的時候，發現以前同事是有備份的，但備份時間是2020年，時間久遠，很多服務啟動引數不一樣了，備份只能僅供參考了)。
- ClickHouse出問題是遲早的，因為之前寫的spark服務，始終沒有最佳化好，資料插入並行度太大。
- 162伺服器早就有問題了，但只要不重啟stat-agent就沒事。
問題處理的差不多了
還有一個問題，StatHub頁面的100多個服務，只恢復了大半。恢復服務管理，是需要重啟服務的，很多服務並不是我寫的，也不是我部署的，我不熟悉，萬一起不來，影響了業務，就會造成不必要的麻煩。但服務脫離管理，萬一哪天掛了，又不知道，也會給排查問題造成麻煩。