TIDB監控升級解決panic的漫漫探索之路

語言: CN / TW / HK

原文來源:https://tidb.net/blog/7747fec7

故事背景

上週同事收到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元件

image.png

因此後面計劃從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是中控機

image.png

2/當前測試中控機有v5.4.0版本的離線映象源,v1.3.1版本的node_exporter元件包

image.png

解決方案實施步驟

1/確認當前節點node_exporter元件程序正常,以保證後續流程正常

命令:tiup cluster exec tidb-test --command='ps -ef |grep node

#tiup cluster exec 命令可以將要執行的命令,由中控機發送到叢集各個節點執行

image.png

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'

image.png

2.2、刪除個節點node_exporter元件的二進位制檔案

命令:tiup cluster exec tidb-test --command='rm -rf /tidb-deploy/monitor-9100/bin/node_exporter/node_exporter'

image.png

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命令複製傳輸檔案

image.png

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'

image.png

3.2、Kill 各節點node_exporter程序:

命令:tiup cluster exec tidb-test --command='pkill -9 node_exporter '

#這裡我直接將程序名中含node_exporter的所有程序全部kill了,執行前請先確認自己當前環境程序,是否會誤操作

image.png

3.3、短暫時間後(我這裡通常1min內),程序自己恢復,去檢查啟動日誌,驗證啟動的node_exporter版本

#啟動日誌位置

image.png

命令:tiup cluster exec tidb-test --command='tail -n 100 /tidb-deploy/monitor-9100/log/node_exporter.log'

#日誌中的時間為標準時間,比北京時間早8小時,因此日誌中的06:43:33實際上是北京時間14:43:33

image.png

觀察日誌:我在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

image.png

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

最後效果:

image.png

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的指令碼內容,發現是寫死的

image.png

擴容測試

1/編輯擴容檔案(擴容一個220節點),執行擴容命令

命令: vi scale-out-tikv.yaml

擴容命令:tiup cluster scale-out tidb-test scale-out-tikv.yaml

image.png

2/到擴容的220上確認node_exporter程序正常

image.png

3/檢視220上node_exporter元件的啟動日誌,驗證啟動的node_exporter版本

image.png

4/驗證分發到220這個節點的可執行檔案node_exporter元件版本

image.png

測試結論:

經過之前的解決步驟後,後續的擴容完全會使用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 社群