關於作者
肖意
OceanBase高階技術專家
曾多次參加螞蟻雙十一大促支援工作，是TPC-C、TPC-H效能攻堅專案組核心成員，主要負責SQL引擎相關研發，包括鏈路協議、執行計劃管理、執行引擎等方向的設計與開發工作。
在上一篇 4.0 解讀文章中，我們回顧了單機到分散式跨越給資料庫 DDL 帶來的挑戰，並介紹了 OceanBase 的應對策略及設計思路，以便為使用者提供更高效、更透明的運維體驗（*戳連結閱讀《OceanBase 4.0 解讀：兼顧高效與透明，我們對 DDL 的設計與思考》）。
本篇將繼續資料庫運維的話題，展開對故障追蹤與定位能力的討論。首先讓我們看下這樣一個場景:
業務部門：資料庫請求好慢，可以看看哪裡出問題了嗎？
DBA 檢視資料庫節點實時監控
DBA：我在資料庫節點的實時監控並未發現很慢的 SQL。
業務部門：那是怎麼回事？
DBA：可能是客戶端到資料庫節點這一鏈路有問題，我來看一下中間代理伺服器的日誌。
DBA 開始查詢日誌，1 hour later……
DBA：從代理伺服器日誌看耗時也是正常的。可能是客戶端到代理伺服器的網路問題？
……
上文描述的是分散式資料庫下運維遇到慢 SQL 時的場景，如果運維無法及時找出問題原因，就會非常影響使用體驗，甚至導致業務服務不可用。因此，如何提供簡單、高效的診斷能力，一直是我們思考的問題。相比單機資料庫，分散式資料庫系統涉及多個節點、多元件協同工作，叢集規模可能達到幾十、上百臺伺服器，使用者請求鏈路會更加複雜，要實現快速高效地問題診斷與定位也會更有挑戰。
OceanBase 4.0 在診斷能力方面有了顯著提升，其中包括首次實現對 SQL 請求的視覺化全鏈路追蹤，能夠幫助使用者快速追蹤並定位具體問題發生在哪個執行階段、哪臺機器以及哪個模組，並提供具體的相關執行資訊，為使用者提供簡單、高效的運維體驗。本文將分享我們對資料庫高效診斷的思考，介紹 OceanBase 全鏈路追蹤能力及設計思路：
全鏈路追蹤要解決什麼問題；
全鏈路追蹤的關鍵能力有哪些；
我們如何設計全鏈路追蹤；
4.0 全鏈路追蹤效果展示。
全鏈路追蹤要解決什麼問題？
在 OceanBase 中，當使用者發起一個請求後，首先會被髮送給 OBProxy（SQL請求代理），由 OBProxy 路由轉發到 OceanBase 叢集，進入叢集中的某一個 OBServer 節點，隨後會經過 SQL 引擎、儲存引擎、事務引擎等（不同的請求會涉及不同引擎中的諸多處理模組），該請求也有可能透過 rpc 任務訪問多個 OBServer 節點的資料，最終將結果返回給客戶端。
圖1 OceanBase SQL請求執行過程示意圖
當使用者請求出現報錯或者執行慢的問題時, 可能是請求執行過程中的某個元件問題，也可能是不同元件節點間的網路等問題。在 4.0 之前的版本中，OceanBase 已經為使用者提供了較為完善的監控和診斷能力，包括 SysStat、Sql Audit、Trans Stat、Tenant Dump、Slow Trans、Slow Query 等，OceanBase 運維平臺（OCP）根據上述監控輸出的資訊實現了白屏化監控和診斷，包括事務診斷、TopSQL 診斷、SlowSQL 診斷等。但這些診斷能力缺乏請求全鏈路視角的資訊, 導致往往定位問題發生在哪個執行階段、哪個機器以及哪個模組就花費了很多時間；有時甚至需要各元件專家一起參與排查才能定位，影響運維人員對問題快速診斷和恢復的效率。
為進一步提高分散式場景下使用者請求問題診斷效率, OceanBase 實現了全鏈路追蹤機制, 能夠追蹤使用者 SQL 請求在資料庫全鏈路過程中，在不同階段、不同元件執行的相關資訊，並以視覺化方式展現給使用者，從而幫助使用者快速定位問題所在位置。
全鏈路追蹤的關鍵能力有哪些
▋ 事務 + SQL 維度的全鏈路追蹤
OceanBase 提供了面向使用者的事務 + SQL 維度的全鏈路追蹤能力。對於業務部門而言，更關心的往往是一筆業務服務總的耗時情況。例如在 OLTP 系統中，一筆業務服務一般由一個或多個事務組成。因此，我們把事務作為追蹤單位會更貼合使用者的實際業務，一個事務形成一個追蹤的 Trace，並對事務中每條 SQL 請求記錄 OBClient -> OBProxy -> OBServer 內部全鏈路過程中相關執行資訊，使用者可以透過一個 Trace 快速找到該事務執行了哪些語句，以及這些語句從客戶端視角看到的執行情況。
在實際業務中，一旦使用者發現有慢的 SQL 請求，或者存在某個慢的事務，可以從慢 SQL 的整個執行鏈路中快速定位是哪個執行階段慢。又或者在某個事務中，如果發現一個 SQL 結束到另一個 SQL 再發起之間的時間較長，則可請業務同學檢視業務邏輯側可能存在的問題。
圖2 事務中SQL呼叫過程圖
▋ 支援分散式環境下的全鏈路追蹤
OceanBase 支援分散式環境下的全鏈路追蹤能力。首先，OceanBase 作為一個分散式系統，當 OBProxy 接收到一個客戶端請求後，有可能會將其路由到 OBServer 叢集中任意一臺 OBbServer 上。同時，該請求涉及到的資料可能分佈在不同的 OBServer 中。具體到 SQL 執行階段，執行引擎會向不同的 OBServer 傳送執行子任務 task，當 OBServer 數量很多時，這些 SQL 請求和 Task 具體是在哪個 Server上執行？Server 內具體各模組執行的耗時情況是怎樣的？都會困擾運維人員。
全鏈路追蹤機制實現了 SQL 請求在分散式場景下，涉及多 Server 時完整執行鏈路的追蹤。使用者能夠直觀地看到是哪個 OBServer 上接收請求，哪個 OBServer 上執行遠端 task，每個 task 的排程情況，以及執行耗時等資訊。
圖3 分散式請求執行過程圖
▋ 提供便捷的業務系統關聯能力
在實際業務中，不少使用者都會建立自己的監控及診斷系統。當資料庫發生請求呼叫慢或報錯時，使用者可能需要系統快速關聯到資料庫對應的某個 SQL 診斷，進一步縮短從發現問題到解決問題的耗時。全鏈路追蹤機制可以為使用者提供便捷的業務系統關聯能力，使用者透過 JDBC 介面/SQL 介面，能夠在業務資料庫連線上設定呼叫請求對應的 app trace id, 該 app trace id 會記錄到 OceanBase 全鏈路追蹤對應的資訊中。
當使用者發現某個 app trace id 對應的請求或服務資料庫呼叫有報錯時, 可以使用該 app trace id 在全鏈路診斷系統中快速搜尋到對應的 app trace id 關聯的資料庫 Trace，然後直接檢視該請求在資料庫鏈路中各階段耗時情況及報錯點，快速確定觸發問題的元件。
▋ 多種全鏈路資訊展示方式
使用者透過 OceanBase 運維平臺（OCP），可以透過不同維度快速檢索到有問題的請求，比如按耗時檢索, 按指定 Trace id 或者 SQL ID 檢索等，並且直觀地看到請求從客戶端到資料庫內部全鏈路各元件的執行資訊, 方便快速定位出問題的階段。
圖4 OCP平臺展示效果圖
此外，使用者可以在 OceanBase 新版本的互動場景使用全鏈路診斷能力。使用者在命令列中手動執行某一個語句後，如果想分析該語句的執行呼叫鏈路情況，以及鏈路中各階段耗時情況，以便進行效能分析或調優，可以使用 show Trace 功能便捷地找到效能瓶頸點。如下所示，我們可以看到兩個分散式並行執行任務(px_task) 的執行情況，如果想看更多明細，也可以透過 show Trace 其他不同命令展現出來。
OceanBase(admin@test)>select/*+parallel(2)*/ count(*) from t1;
+----------+
| count(*) |
+----------+
| 5 |
+----------+
1 row in set (0.005 sec)
OceanBase(admin@test)>show trace;
+-------------------------------------------+----------------------------+------------+
| Operation | StartTime | ElapseTime |
+-------------------------------------------+----------------------------+------------+
| obclient | 2023-03-01 17:51:30.143537 | 4.667 ms |
| └─ ob_proxy | 2023-03-01 17:51:30.143716 | 4.301 ms |
| └─ com_query_process | 2023-03-01 17:51:30.145119 | 2.527 ms |
| └─ mpquery_single_stmt | 2023-03-01 17:51:30.145123 | 2.513 ms |
| ├─ sql_compile | 2023-03-01 17:51:30.145133 | 0.107 ms |
| │ └─ pc_get_plan | 2023-03-01 17:51:30.145135 | 0.061 ms |
| └─ sql_execute | 2023-03-01 17:51:30.145252 | 2.350 ms |
| ├─ open | 2023-03-01 17:51:30.145252 | 0.073 ms |
| ├─ response_result | 2023-03-01 17:51:30.145339 | 2.186 ms |
| │ ├─ px_schedule | 2023-03-01 17:51:30.145342 | 1.245 ms |
| │ │ ├─ px_task | 2023-03-01 17:51:30.146391 | 1.113 ms |
| │ │ │ ├─ get_das_id | 2023-03-01 17:51:30.146979 | 0.001 ms |
| │ │ │ ├─ do_local_das_task | 2023-03-01 17:51:30.147012 | 0.050 ms |
| │ │ │ └─ close_das_task | 2023-03-01 17:51:30.147237 | 0.014 ms |
| │ │ └─ px_task | 2023-03-01 17:51:30.146399 | 0.868 ms |
| │ │ ├─ get_das_id | 2023-03-01 17:51:30.147002 | 0.001 ms |
| │ │ ├─ do_local_das_task | 2023-03-01 17:51:30.147036 | 0.041 ms |
| │ │ └─ close_das_task | 2023-03-01 17:51:30.147183 | 0.011 ms |
| │ └─ px_schedule | 2023-03-01 17:51:30.147437 | 0.001 ms |
| └─ close | 2023-03-01 17:51:30.147536 | 0.049 ms |
| └─ end_transaction | 2023-03-01 17:51:30.147571 | 0.002 ms |
+-------------------------------------------+----------------------------+------------+全鏈路診斷互動式效果
▋ 建立從定位到診斷的一站式體驗
我們已經知道，使用者可以藉助全鏈路追蹤能力快速定位出故障發生的元件或模組。如果具體討論某個比較小的模組呢？此時使用者就可以關聯各模組對應的其他診斷機制進行問題定位。
舉例來說，我們透過全鏈路追蹤定位到是 SQL 執行引擎慢，則可以透過 SQL 請求的 sql_trace_id 關聯，自動跳轉到 SQL Plan Monitor 診斷機制，檢視執行計劃各執行緒各運算元執行情況。如圖 5 所示，可以看到每個運算元執行 CPU 時間（DBTime 綠色）、等待時間（DBTime 紅色）、運算元返回行數等資訊。
圖5 SQL Plan Monitor展示執行資訊圖
我們如何設計全鏈路追蹤
如下圖所示，可以看到 OceanBase 全鏈路追蹤能力實現涉及的主要板塊。我們記錄 Trace 資訊使用的資料模型是 OpenTracing 的模型，具體到實現則主要分 2 個部分：Trace 資料生成以及 OCP 分析展示整合，下文將展開詳細介紹。
圖6 OceanBase全鏈路追蹤實現示意圖
▋ 資料模型
OceanBase 全鏈路追蹤記錄資料使用 OpenTracing 模型，該資料模型在分散式追蹤系統中被大量使用，下圖中左邊是 OpenTracing 資料模型，右圖是對應 OceanBase 全鏈路追蹤的記錄模型，一個 Trace 對應於一個資料庫的事務，每個 Trace 會對應多個 Span，比如一個 SQL 請求是一個 Span，Span 中會記錄某個過程執行相關資訊，每個 Span 會記錄一條日誌持久化到 Trace 檔案中。
圖7 全鏈路追蹤資料模型
▋ Trace資料生成
生成完整有效的 Trace 資料，是全鏈路追蹤能力的關鍵。請求全鏈路涉及的各個元件，哪些階段需要單獨記錄 Span，以及記錄哪些關鍵有用資訊，我們都會仔細斟酌，確保全鏈路資訊準確有用，另一方面，生成 Trace 資料的效能損耗，我們也需要重點考慮，這塊開銷主要分兩部分， 一部分是 Trace 資料記錄到記憶體開銷，另一部分是將 Trace 資料寫入到 Trace 檔案的開銷，為了儘量不影響效能，同時為使用者提供更多有用的全鏈路診斷資訊, 我們提供了多種控制策略，為不同使用者連結可以設定不同 Trace 級取樣頻率，記錄完整 Trace 資訊，同時也會將使用者更關注的慢 SQL 及報錯的 SQL 對應的 Trace 資訊 100% 列印到 Trace 日誌中。
圖8 各元件trace日誌生成示意圖
Trace 檔案會獨立記錄到 OBProxy 和 OBServer 不同程式所在機器，考慮到資料庫客戶端使用是在業務服務端，OceanBase 資料庫 OBClient 端的全鏈路 Trace 資訊並沒有記錄到業務伺服器上，而是傳輸到 OBProxy 記錄。
▋ OCP平臺分析與展示整合
OCP 平臺中，實現了鏈路 Trace 資訊的頁面搜尋及展示能力，它可以根據使用者設定的條件，搜尋某個請求涉及的 Trace 資訊，讓使用者直觀地檢視整個鏈路的詳細資訊。而這些資料的來源, 主要來自 OBProxy 和 OBServer 不同伺服器上的Trace日誌, OCP 後臺會有專門的採集工具, 對這些 Trace 日誌進行採集, 並解析，最後儲存到ES中。 但這些採集資料是原始的 Span 資料，同一個 Trace 的資料可能分散在不同機器的不同 Span 中，要實現按一個 Trace 中不同的 Span 上的 Tag 作為條件來搜尋會較困難。因此，OCP Server 會定時把 Trace 的關鍵 Span 資料（如不同階段的耗時、重要 Tag）合在一條資料中，構造每條 Trace 的概要。從而實現讓使用者按不同的條件組合高效地查詢 Trace 資訊，用於頁面展示。
4.0全鏈路追蹤效果展示
回到文章開頭的慢 SQL 問題，在 4.0 提供了全鏈路追蹤能力後，運維人員的操作會有什麼變化呢？
現在，使用者如果發現業務請求變慢，可以在 OCP 的全鏈路搜尋頁面中依據耗時對 SQL 進行排序，找到某個時間段內耗時高的請求，檢查是否有執行時間不符合預期的 SQL。如果透過 TopSQL 診斷已經確定是某個 SQL 耗時高，或者獲取到有關聯使用者的 app trace id，也可以作為查詢過濾條件，進一步減少查詢範圍。
圖9 OCP全鏈路追蹤搜尋
當確定耗時高的請求後，接下來我們需要診斷具體是哪裡出了問題。此時，使用者可以在 OCP 中直接點選有問題的 Trace id，展開請求的 Trace 資訊（如圖 10 所示）。可以看到，從客戶端視角看，該請求總共耗時是 4.47ms，OBProxy 視角總耗時 4.366ms，OBServer 中耗時是 3.246ms，主要耗時在 OBServer 端，進一步看，可以看到主要耗時在 SQL compile 階段, 也就是 SQL 生成執行計劃階段。此時，我們便可以得出初步結論：這條 SQL 執行慢耗時高，是它沒有命中執行計劃導致的。
圖10 OCP全鏈路資訊展示
在 OCP 的全鏈路詳情中，可以看到相應 SQL 請求呼叫個模組的路徑，並可以詳細看到各階段的耗時。舉例來說，當使用者要了解客戶端發起請求到 OBProxy 接收請求這個階段的具體耗時，從時間軸上看到 OBClient 和 OBProxy 間的網路耗時並不是主要耗時。如果使用者想進一步瞭解該階段耗時具體資訊，可以分別點選對應 OBClient 傳送請求的 Span 和 OBProxy 接收請求的 Span，如圖 11 所示，可以快速看到兩者開始時間差為 187 us，也就是這個從客戶端傳送請求到 OBProxy 接收請求的耗時，這樣可以幫助我們更加細化地分析問題。
圖11 全鏈路追蹤階段資訊展示
寫在最後
OceanBase 4.0 的全鏈路追蹤能力實現了對每個事務、每條 SQL 請求的可觀測性，提供了高效的問題診斷和定位能力。我們相信這一新能力將幫助使用者更加快速地定位問題並解決問題, 從而帶來更簡單、更高效地資料庫運維體驗。作為改善 OceanBase 易用性的重要一環，我們也將在未來的 4.x 中著力提升運維體驗，新增包括 ASH（Active Session History）、Realtime SQL Plan Monitor、Logical Plan Manager 等在內的更多功能。最後，歡迎大家在評論區留言，一起探討對資料庫問題診斷的看法。
你可訪問OceanBase官網獲取更多資訊：https://www.oceanbase.com/