做者介紹:李坤,PingCAP 互聯網架構師,TUG Ambassador,前美團、去哪兒數據庫專家。
使用 TiDB Ansible 部署 TiDB 集羣,會同時部署一套 Grafana + Prometheus 的監控平臺,這套監控用來收集和展現 TiDB 集羣各個組件和機器的 metric 信息,這些 metric 信息很是豐富,能夠幫助使用者分析 TiDB 集羣的狀態以及 Trouble shooting。隨着使用經驗的增多,咱們積累了一些監控使用上的技巧,在這裏分享給你們。python
Prometheus 是一個擁有多維度數據模型的、靈活的查詢語句的時序數據庫。Grafana 是一個開源的 metric 分析及可視化系統。sql
<center>圖 1 TiDB 監控總體架構</center>數據庫
從 TiDB 2.1.3 版本開始,監控採用 pull 的方式,而以前採用的是 push 的方式,這是一個很是好的調整,它解決了幾個問題:json
PushGateWay
這個單點組件。TiDB 的 3 個核心組件(TiDB,TiKV,PD)能夠經過 http 接口來獲取 metric 數據,這些指標都是從程序代碼中統計上傳的,端口以下:api
組件 | 端口 |
---|---|
tidb-server | 10080 |
tikv-server | 20181 |
pd-server | 2379 |
用 tidb-server 舉例,咱們經過 http 接口,看一個 statement QPS 的 metric:架構
# 能夠看到實時 qps 的數據,區分不一樣的 type,value 是 counter 類型的累計值(科學計數法) curl http://__tidb_ip__:10080/metrics |grep tidb_executor_statement_total tidb_executor_statement_total{type="Delete"} 520197 tidb_executor_statement_total{type="Explain"} 1 tidb_executor_statement_total{type="Insert"} 7.20799402e+08 tidb_executor_statement_total{type="Select"} 2.64983586e+08 tidb_executor_statement_total{type="Set"} 2.399075e+06 tidb_executor_statement_total{type="Show"} 500531 tidb_executor_statement_total{type="Use"} 466016
這個數據會在 Prometheus 存儲下來,而後在 Grafana 展現,咱們在面板上點擊右鍵會出現 Edit
按鈕(或直接按 e),以下圖所示:運維
<center>圖 2 metric 面板的編輯入口</center>ssh
咱們能夠在 Metric
面板上,看到利用該 metric 的 query 表達式。curl
面板上一些細節的含義:函數
rate[1m]
:表示 1 分鐘的增加速率,只能用於 counter 類型的數據。sum
:表示 value 求和。by type
:表示將求和後的數據按 metric 的原始值中的 type 進行分組。Legend format
:表示指標名稱的格式。Resolution
:默認打點步長是 15s,Resolution
表示是否分解。
<center>圖 3 metric 面板中的表達式</center>
Prometheus 支持不少表達式與函數,更多表達式請參考 官網頁面。
如上一小節的例子,是按照 type 進行分組,是否還能用其餘維度分組?如何能快速得知還有哪些維度呢?這裏推薦的技巧是,在 query 的表達式上只用指標名稱,不作任何計算,format 也留空,這樣就能顯示出原始的 metric 數據,好比下圖能看到有 3 個維度(instance
、job
、type
)。
<center>圖 4 編輯表達式並查看全部維度</center>
獲得 instance
這個維度後,咱們調整表達式,在原有的 type 後面加上 instance
這個維度,調整 legend format
格式增長 {{instance}}
,就能夠看到每一個 tidb-server 上執行的不一樣類型 SQL 的 QPS 了。以下圖:
<center>圖 5 給表達式增長一個 instance 維度</center>
以 query duration
指標爲例,默認的比例尺採用 2 的對數計算,顯示上會將差距縮小。爲了觀察明顯的變化,能夠將比例尺改成線性,經過下面兩張圖,能夠看到顯示上的區別,明顯的發現那個時刻有個 SQL 運行較慢。
固然也不是全部場景都適合用線性,好比觀察 1 個月的性能趨勢,用線性可能就會有不少噪點,很差觀察。
<center>圖 6 標尺默認的比例尺爲 2 的對數</center>
<center>圖 7 調整標尺的比例尺爲線性</center>
提示:咱們能夠結合技巧 1,發現這裏還有一個
sql_type
的維度,能夠馬上分析出是 select 慢仍是 update 慢,而且能夠分析出是在哪一個 instance 上慢。
有一種狀況:已經用了線性顯示,仍是看不出變化趨勢。好比下圖中,咱們在擴容後想觀察 Store size
的實時變化效果,因爲基數較大,微弱的變化觀察不到。 這時咱們能夠將 Y 軸最小值從 0
改成 auto
,將上部放大,觀察下面兩張圖的區別,能夠觀察到數據已開始遷移了。
<center>圖 8 基線默認爲 0</center>
<center>圖 9 調整基線爲 auto</center>
在 Setting 面板中,有 Graph Tooltip
的設置,默認使用 Default
。
<center>圖 10 圖形展現工具</center>
咱們調整爲 Shared crosshair
和 Shared Tooltip
分別試一下效果: 能夠看到標尺能夠聯動展現了,方便排查問題時,確認 2 個指標的關聯性。
<center>圖 11 調整圖形展現工具爲 Shared crosshair</center>
<center>圖 12 調整圖形展現工具爲 Shared Tooltip</center>
PD 的 Dashboard,只展現當前 leader 的 metric 信息,有時候會想看一下歷史上 pd-leader 當時的情況,可是 instance 下拉列表中不存在這個成員了,咱們也能夠手動輸入 ip:2379
來看到當時的數據。
<center>圖 13 手動輸入並查看 metric</center>
Avg
函數一般默認圖例中只有 Max
和 Current
,但有時指標波動較大時,咱們能夠增長 Avg
等其餘彙總函數的圖例,能夠看一段時間的總體趨勢。
<center>圖 14 增長 Avg 等彙總函數</center>
<center>圖 15 增長 Avg 函數</center>
Grafana 經過 Prometheus 的接口獲取數據,咱們也能夠用該接口獲取數據,這個用法能夠擴散出不少功能:
<center>圖 16 Prometheus 的 API 接口</center>
curl -u user:pass 'http://__grafana_ip__:3000/api/datasources/proxy/1/api/v1/query_range?query=sum(tikv_engine_size_bytes%7Binstancexxxxxxxxx20181%22%7D)%20by%20(instance)&start=1565879269&end=1565882869&step=30' |python -m json.tool { "data": { "result": [ { "metric": { "instance": "xxxxxxxxxx:20181" }, "values": [ [ 1565879269, "1006046235280" ], [ 1565879299, "1006057877794" ], [ 1565879329, "1006021550039" ], [ 1565879359, "1006021550039" ], [ 1565882869, "1006132630123" ] ] } ], "resultType": "matrix" }, "status": "success" }
Grafana + Prometheus 是一套很是強大的組合,用好他們能夠爲咱們的分析節省不少時間,提升效率,更重要的是能增長髮現問題的可能性。在運維 TiDB 集羣時,尤爲數據量大的時候,這套工具能派上大用場。這裏拋磚引玉,也但願你們也能提供一些技巧,一塊兒共同窗習。
閱讀原文:https://pingcap.com/blog-cn/use-grafana-to-monitor-and-analyze-tidb-metrics/