故事背景
上周同僚收到tidb生産叢集告警，node_exporter元件發生了重新開機，與同僚交流了一下相關曆史告警，發現node_exporter元件總是時不時的重新開機，并觸發告警，并且整個叢集各個節點都有發生過這個現象。
這裡先簡單介紹下node_exporter元件相關背景以及它的作用：TiDB 使用開源時序資料庫 Prometheus 作為監控和性能名額資訊存儲方案，而node_exporter是Prometheus的名額資料收集元件。它負責從目标Jobs收集資料，并把收集到的資料轉換為Prometheus支援的時序資料格式。是以在部署叢集時，通常會在叢集的每個節點都分發并運作node_exporter元件。
經過我們對重新開機現象的排查确認，認為是node_exporter元件會偶發性的出現panic,導緻節點重新開機，經過與PingCap原廠的工程師回報這個問題後，建議我們嘗試将node_exporter元件的版本進行更新。
我們在本地鏡像源裡面檢查了一下node_exporter元件的版本，發現目前版本是v0.17.0版本，也是PingCap官方推出的最高版本，而prometheus官方已經推出了v1.3.1版本的node_exporter元件
是以後面計劃從prometheus官網下載下傳v1.3.1版本的node_exporter元件包，去不停機更新到我們的測試叢集中，在不影響服務的情況下更新，再觀察下能否解決這個panic的問題。
#node_exporter元件包下載下傳網址：https://github.com/prometheus/node_exporter
初期遇到的問題
目前叢集是本地離線鏡像源部署的，這種背景下，我初期大緻的的實施思路是這樣的：
1/下載下傳node_exporter元件包上傳到離線的生産環境中控機
2/使用
tiup mirror publish
将該元件包釋出到本地離線鏡像源tiup mirror publish | PingCAP Docs
3/使用
tiup install
或者
tiup update
更新node_exporter元件到v1.3.1版本
按照這種思路操作，我發現所有操作都是報 successfully！，但是去檢查各個節點的node_exporter二進制檔案還是v0.17.0版本，并且啟動的服務的日志也都是0.17.0版本，後面嘗試過更多官方可能的一些可能的操作，例如
tiup cluster patch
或者
tiup cluster upgrade
等，都沒發解決我的問題，後面自己做出了一些猜想：node_exporter元件不屬于“cluster”原生元件，是以并不能使用tiup的一些相關指令直接去更新，後面去開帖和社群的朋友們讨論了一波，似乎也論證了我的猜想。
讨論的文章：如何線上的将本地node_exporter元件從線上的v0.17.0更新到v1.3.1版本（prometheus已經有該版本，但是pingcap隻出了0.17.0版本） - TiDB / 部署&運維管理 - TiDB 的問答社群 (asktug.com)
線上更新node_exporter元件解決方案
序言
在前面經過一些嘗試與讨論工作之後，個人認為其實官方途徑暫時無法解決這個問題，後面我自己采取了一個”挂羊頭賣狗肉“的方式去解決了這個問題。由于之前在社群并沒有找到相關問題的解決方案，是以記錄一下解決過程分享給大家
測試環境簡介
1/整個測試用到5台虛拟機，分别用ip最後一位180，190，200，210，220簡稱，其中190是中控機
2/目前測試中控機有v5.4.0版本的離線鏡像源，v1.3.1版本的node_exporter元件包
解決方案實施步驟
1/确認目前節點node_exporter元件程序正常，以保證後續流程正常
指令：
tiup cluster exec tidb-test --command='ps -ef |grep node
#
tiup cluster exec
指令可以将要執行的指令，由中控機發送到叢集各個節點執行
2/用V1.3.1版本的node_exporter元件二進制檔案，去替換掉各節點V0.17.0版本的二進制檔案
2.1、确認節點node_exporter可執行檔案位置（如各節點部署目錄不同，後續指令需調整）
指令：
tiup cluster exec tidb-test --command='ls /tidb-deploy/monitor-9100/bin/node_exporter'
2.2、删除個節點node_exporter元件的二進制檔案
指令：
tiup cluster exec tidb-test --command='rm -rf /tidb-deploy/monitor-9100/bin/node_exporter/node_exporter'
2.3、将中控機v1.3.1版本node_expor二進制檔案分發到各個節點
指令：
tiup cluster push tidb-test /home/tidb/node_exporter-1.3.1.linux-amd64/node_exporter /tidb-deploy/monitor-9100/bin/node_exporter/node_exporter
#這裡需要确認指令中的目錄是否需要調整
#
tiup cluster push
指令可用來将中控機的檔案批量分發到叢集各個節點，這裡相當于分别執行了cp、scp指令複制傳輸檔案
2.4、賦予可執行權限
指令：
tiup cluster exec tidb-test --command='chmod u+x /tidb-deploy/monitor-9100/bin/node_exporter/node_exporter'
3/kill各個節點node_exporter程序，自動拉起程序後，驗證各節點啟動的node_exporter元件版本
3.1、先确認下之前分發到各個節點的可執行檔案版本
指令：tiup cluster exec tidb-test --command='/tidb-deploy/monitor-9100/bin/node_exporter/node_exporter --version'
3.2、Kill 各節點node_exporter程序：
指令：
tiup cluster exec tidb-test --command='pkill -9 node_exporter '
#這裡我直接将程序名中含node_exporter的所有程序全部kill了，執行前請先确認自己目前環境程序，是否會誤操作
3.3、短暫時間後（我這裡通常1min内），程序自己恢複，去檢查啟動日志，驗證啟動的node_exporter版本
#啟動日志位置
指令：
tiup cluster exec tidb-test --command='tail -n 100 /tidb-deploy/monitor-9100/log/node_exporter.log'
#日志中的時間為标準時間，比中原標準時間早8小時，是以日志中的06：43：33實際上是中原標準時間14：43：33
觀察日志：我在14：47看到日志中記錄在14：43：33啟動了node_exporter元件，且啟動的版本是1.3.1，說明：線上更新node_exporter元件成功！
解決擴容節點使用新版本的node_exporter元件的問題
序言
前面章節講述到，如何線上更新叢集node_exporter元件，但是作為一個優秀的dba,我們需要可持續性的解決問題，這裡很容易想到在未來如果該叢集進行了擴容，是否還會使用高版本的node_exporter元件呢？很顯然答案是否定的！
本章節就是講述如何保障後續擴容時也會使用高版本的元件
解決方案實施步驟
1/重新設定node_exporter-v1.3.1-linux-amd64.tar.gz包
#這一步重新設定的作用，會在後續FAQ專門解答
1.1、解壓node_exporter-v1.3.1-linux-amd64.tar.gz包
指令：
tar -zxvf node_exporter-v1.3.1-linux-amd64.tar.gz
解壓後發現，會得到檔案夾node_exporter-v1.3.1.linux-amd64
1.2、将檔案夾node_exporter-v1.3.1.linux-amd64改名為node_exporter
指令：
mv node_exporter-v1.3.1.linux-amd64 node_exporter
1.3、重新将node_exporter檔案夾打包成tar.gz包
指令：
tar zcvf node_exporter-v1.3.1-linux-amd64.tar.gz node_exporter
2/釋出&更換中控環境中的node_exporter元件的tar.gz包
2.1将目前鏡像源裡的key目錄發送到.tiup檔案夾下
指令：
cp -r /home/tidb/tidb-community-server-v5.1.3-linux-amd64/keys /home/tidb/.tiup/
#這裡為什麼要發送keys目錄,請參考：tiup mirror merge | PingCAP Docs
2.2、将新版本的元件包釋出到本地離線鏡像源
指令：
tiup mirror publish node_exporter v1.3.1 ./node_exporter-v1.3.1-linux-amd64.tar.gz node_exporter/node_exporter --key ./.tiup/keys/4d418a71219c1935-pingcap.json
#該指令詳解請參考：tiup mirror publish | PingCAP Docs
2.3、将中控機将.tiup中下原來0.17.0版本的tar.gz包删除
指令：
rm -rf /home/tidb/.tiup/storage/cluster/packages/node_exporter-v0.17.0-linux-amd64.tar.gz
2.4、将之前重新設定的1.3.1版本的node_exporter的tar.gz包發送到.tiup下
指令：
cp node_exporter-v1.3.1-linux-amd64.tar.gz /home/tidb/.tiup/storage/cluster/packages/node_exporter-v1.3.1-linux-amd64.tar.gz
2.5、賦予可執行權限
指令：
chmod u+x /home/tidb/.tiup/storage/cluster/packages/node_exporter-v1.3.1-linux-amd64.tar.gz
最後效果：
FAQ
**問題一：**為什麼要重新設定v1.3.1版本node_exporter元件的tar.gz包？直接git_hub下載下傳的不能用嗎？
**解答：**因為在後續進行擴容的過程中，會将
/home/tidb/.tiup/storage/cluster/packages/
下的node_exporter元件包發送到新增節點，而啟動時，會通過腳本調用啟動元件包中的node_exporter二進制檔案，而腳本中寫死的的調用路徑為node_exporter/node_exporter,第一個node_exporter為該元件包解壓後目錄的名字，是以我需要專門提前把解壓後的目錄名改成node_exporter
驗證方式：
1/找一個pingcap官方的node_exporter元件包解壓，你會發現解壓後目錄名是node_exporter
2/直接去檢視各節點調node_exporter的腳本内容，發現是寫死的
擴容測試
1/編輯擴容檔案（擴容一個220節點），執行擴容指令
指令：
vi scale-out-tikv.yaml
擴容指令：tiup cluster scale-out tidb-test scale-out-tikv.yaml
2/到擴容的220上确認node_exporter程序正常
3/檢視220上node_exporter元件的啟動日志，驗證啟動的node_exporter版本
4/驗證分發到220這個節點的可執行檔案node_exporter元件版本
測試結論：
經過之前的解決步驟後，後續的擴容完全會使用1.3.1版本的node_exporter元件，解決方案能解決擴容的問題！
其他相關FAQ
**問題一：**叢集版本進行更新後（離線更新），是否會将各個節點的已更新的node_exporter元件給覆寫掉？更新後再擴容還會使用高版本的node_exporter元件嗎？
**解答一：**叢集更新後，已更新的各個節點的node_exporter元件并不會被覆寫掉導緻版本回退，但是由于本地離線更新後鏡像源更換，會重新從新鏡像源裡面加載該鏡像源裡面node_exporter元件到.tiup下，導緻後面擴容使用低版本元件，這裡需要執行以下上一章節《解決擴容節點使用新版本的node_exporter元件的問題》，可解決未來的擴容問題。
**問題二：**我們是否可以直接部署叢集前，就定制包含高版本，例如v1.3.1版本的node_exporter元件的鏡像源使用？
**解答二：**可以！
實作步驟簡介：
1/直接将鏡像源裡面的node_exporter元件包删除
2/使用publish将高版本的元件包釋出到鏡像源
#作者認為：看過文章前面部分，就會知道這兩步具體怎麼操作，我就不再複述啦！
作者想說：
1/文章篇幅太長，難免出現纰漏，閱讀過程中有任何疑問，歡迎直接在評論區提出來進行讨論
2/在背景故事中，我們最終目的其實是為了解決node_exporter元件的"panic"，目前已經在測試環境進行更新，一段時間後觀察到問題解決了，會在文章評論區答複，歡迎關注本文章