看不懂監控怎麼辦？TiDB 新推出了耗時關係圖

TiDB 使用 Prometheus 和 Grafana 提供了很是詳細的監控指標。在遇到各類性能或穩定性問題時，這些監控通常是問題的關鍵線索。但詳盡的細節監控指標使用門檻較高，剛入門的 TiDB DBA 可能難以上手，例如：

• 如何快速瞭解當前集羣最耗時的是哪類操做？
• 發現寫入耗時很長，如何進一步定位緣由，應該查看哪些監控項？
• 監控項這麼多，它們之間的關係是什麼？

TiDB 4.0.7 起提供了一個新功能，能夠將數據庫各個內部流程的耗時監控按父子關係繪製爲關係圖，幫助用戶快速以另外一種維度瞭解集羣狀態。

簡介

監控關係圖是在指定的時間範圍內，將各個監控項按父子關係繪製的關係圖。圖中每一個方框節點表明一個監控項，包含了如下信息：

• 監控項的名稱
• 監控項的總耗時
• 監控項總耗時和查詢總耗時的比例

父節點監控的總耗時 = 本身的耗時 + 孩子節點的耗時，因此有些節點還會顯示本身的耗時和總耗時的比例。

例以下面監控節點表示：tidb_execute 監控項的總耗時爲 19306.46 秒，佔總查詢耗時的 89.4%，其中自己的耗時是 9070.18 秒，佔總查詢耗時的 42%。將鼠標懸停在該方框上，能夠看到監控項的註釋說明，總次數，平均耗時，平均 P99 耗時等更多該監控的信息。

每一個節點的大小和顏色深淺，與監控項本身的耗時佔總查詢耗時的比例成正比。通常在這個圖中能夠重點關注耗時較多的監控節點，而後順着父子關係向下梳理。詳細介紹請參考官方文檔。話很少說，來看兩個簡單的示例吧。

示例 1

最近新上線一個業務後，原來的集羣響應忽然變慢了不少，小明看服務器 CPU 都挺空閒的呀，而後抓了一個監控關係圖以下：

能夠很快發現，上圖中：

1. tidb_query.Update 表示 update 語句的執行耗時佔總查詢耗時的 99.59%。
2. tidb_execute 表示 TiDB 的執行引擎自己耗時佔 68.69%
3. tidb_txn_cmd.commit 表示事務提交的耗時佔總耗時的 30.66%
4. tidb_kv_backoff.txnLock 表示事務遇到鎖衝突的 backoff 總耗時佔 15%，這要比發送 prewrite 和 commit 的 tidb_kv_request 的耗時高不少。

到此，能夠肯定 update 語句存在嚴重的寫衝突，能夠按照 樂觀事務模型下寫寫衝突問題排查 進一步排查衝突的表和 SQL 語句，而後和業務方溝通從業務上避免寫衝突。

示例 2

最近須要導入一批數據到 TiDB 集羣，導入速度有點慢，小明想看看系統如今慢在哪兒，而後看能不能優化下，他抓了一個導入數據時的監控耗時關係圖以下：

上圖中，最下面能夠看到 tikv 的 raftstore 在處理 propose 前的等待耗時很長，說明 raftstore 存在瓶頸了，而後能夠進一步查看 raftstore cpu，append/apply log 的延遲，若是 raftstore 的 thread cpu 使用率不高，則大機率是磁盤是磁盤的問題。具體能夠按照 Performance TiKV Map 中 raftstore 相關模塊和 TiDB 磁盤 I/O 太高的處理辦法 進行排查，

除此以外，能夠排查是否存在熱點，能夠按照 TiDB 熱點問題處理 進一步排查是否有熱點。

使用介紹

注：生成監控關係圖時，會從 prometheus 中讀取各項監控的數據。因此 TiDB 集羣須要部署 prometheus ，推薦使用 tiup 部署集羣。

登陸 Dashboard 後點擊左側導航的集羣診斷能夠進入此功能頁面：

設置區間起始時間和區間長度參數後，點擊生成監控關係圖按鈕後，會進入監控關係圖頁面。

最後

本文介紹的監控關係圖旨在幫助用戶快速瞭解 TiDB 集羣的負載狀況和衆多監控項之間的關係，後續計劃集成 TiDB Performance Map，把和該項監控項相關的其餘監控以及配置也關聯上，進一步完善 TiDB 集羣中各個組件監控項之間的關係。

若有任何疑問或者建議，歡迎在 AskTUG 下給咱們留言~