TIDB監控升級解決panic的漫漫探索之路
故事背景
上週同事收到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元件包下載網址:http://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元件解決方案
序言
在前面經過一些嘗試與討論工作之後,個人認為其實官方途徑暫時無法解決這個問題,後面我自己採取了一個”掛羊頭賣狗肉“的方式去解決了這個問題。由於之前在社群並沒有找到相關問題的解決方案,所以記錄一下解決過程分享給大家
測試環境簡介
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",目前已經在測試環境進行升級,一段時間後觀察到問題解決了,會在文章評論區答覆,歡迎關注本文章
3/其實作者希望這篇文章能幫助解決元件相關的一類的問題,不僅僅是node_exporter元件,希望以後碰到類似問題也可以用本文章相關內容,進行類比嘗試
4/關於元件的其他改造使用可以參考另一篇:專欄 - 記一次tidb離線環境下安裝非本地映象源元件的過程 | TiDB 社群
- TiFlash 儲存層概覽
- TiFlash 計算層概覽
- TiCDC 架構和資料同步鏈路解析
- TiKV & TiFlash 加速複雜業務查詢
- 讓秒殺狂歡更從容:大促背後的資料庫(下篇)
- TiCDC 6.0原理之Sorter演進
- TiDB 之 TiCDC6.0 初體驗
- 帶你全面瞭解compaction 的13個問題
- TiDB 6.1 新特性解讀 | TiDB 6.1 MPP 實現視窗函式框架
- TiFlash 面向編譯器的自動向量化加速
- 你踩過這些坑嗎?謹慎在時間型別列上建立索引
- TiDB和C#的簡單CRUD應用程式
- TiDB VS MySQL
- TIDB監控升級解決panic的漫漫探索之路
- 記憶體悲觀鎖原理淺析與實踐
- TiDB 效能分析&效能調優&優化實踐大全
- TiDB 效能分析和優化
- tiflash 6.0 on k8s擴容與新特性實踐
- 論分散式資料庫TiDB架構的“存”與“算”
- MySQL正常執行的SQL在TiDB中變慢了