隨著OCEANBASE在金融、證券、運營商、能源等行業的應用越來越廣泛，針對OCEANBASE的運維支撐工具的需求也被越來越多的用戶提出來了。去年我們開始適配OB的動力來自于與一個金融行業用戶的交流，他們對我們的D-SMART支持Oracle的功能表示滿意，不過他們目前面臨了一些新的問題。那就是目前部分業務系統已經從Oracle遷移到了Oceanbase，但是對于OB的運維，他們感到有些頭痛。系統不出問題的時候，或者不出大問題的時候，也不太需要運維人員介入，大部分故障場景會在短時間內自愈。而系統出現一些較為嚴重的性能問題的時候，運維人員往往是束手無策的，甚至不知道故障可能會持續多長時間。

D-SMART支持OCEANBASE的適配工作已經經歷了一年多了，當時適配的版本是3.X，不過到了Oceanbase 4.2.1 GA的23年10月份，這個工作還沒有徹底完成。通過一個運維平臺，不斷的積累運維經驗，構建大量的自動化預警模型和分析工具，可以有效的增強對OB數據庫的運維支撐能力，整個智能化運維的框架是十分成熟的，研發團隊對Oceanbase的研究何跟蹤也有一兩年時間了。因此我們在去年年初開始立項針對OB進行適配的時候，原本以為這項工作會在3-4個月內初步完成，然后去某個用戶處磨合。沒想到適配OCEANBASE遠比我們預料的復雜。分布式數據庫與集中式數據庫在很多地方都與集中式數據庫不同，從而導致運維管理方面的差異是十分巨大的。

首先是指標體系的不同，分布式數據庫的部署環境是一組服務器，數據庫實例也是由一組OBSERVER組成的多個分布式的服務組成。因此指標體系完全不同。對于集中式數據庫來說，我們可以關注某個指標，比如每秒CLOG數量。不過對于OB來說，這里就復雜了，因為每個OBSERVER都會有相關的指標。

在集中式數據庫中的一個指標，在分布式數據庫中可能會有很多值，分布式數據庫集群的節點數量越多，這個指標的值就越多。不僅如此，Oceanbase還支持多租戶，每個租戶都有獨立的指標，因此在一個Oceanbase數據庫中，某一個指標的值可能有幾十個甚至幾百上千個。我們不能僅僅從總值或者平均值去看問題，還要考慮值的均衡性問題和變化趨勢。因此運維監控工具需要具備對一組值的處理能力。這涉及到了對D-SMART底層指標處理體系的改造與優化。

前端界面上顯示的值也是要斟酌的，到底把哪個值放上去呢？最大值，平均值？如果放最大值有可能同一行上面的數據來自于多個不同的OBSERVER，數據時不一致的。

因為D-SMART最早設計指標體系的時候就學習了互聯網企業的經驗，支持列表、表格等模式，因此只要在前端顯示與后端處理的時候適配一下就可以了，更大的問題還在后面。

第二個需要考慮的問題是多租戶的問題，Oceanbase是一個從底層到上層都支持多租戶的數據庫系統。不同的租戶之間有著較強的隔離。因此從運維的角度，我們如何來看待集群和租戶呢？對于一個數據庫來說，從集群下鉆到租戶，再到某個OBSERVER，可能是我們從集中式數據庫沿用下來的思考方式。但是這種模式似乎會讓運維工具變得太復雜，讓運維人員很難掌握。通過思考，我們決定把集群和租戶都看成是一個獨立的運維對象。在現實的生產環境中，有些用戶對于Oceanbase的運維也是這樣的，集群有專門的人員維護，而不同的租戶交給不同的使用單位自己來運維。

因此我們為OceanBase設計了三種數據庫子類型：Oceanbase集群子類、Oceanbase MySQL租戶子類和Oceanbase Oracle租戶子類。如果僅僅以租戶的角度來看待Oceanbase這樣的多租戶數據庫系統還是比較簡單的，這個框架完全可以參考Oracle的PDB，事實上root租戶我們可以把它看成是Oracle的CDB，我們把root租戶看成是Oceanbase的集群，對于集群而言，我們更關注的是節點、資源（總體與可分配資源）、容量、網絡、高可用、故障等問題。而不需要去關注負載、并發等方面的問題。

Oceanbase數據庫的負載、并發、性能等方面的問題可以在租戶層面去關注。不過Oceanbase擁有MySQL和Oracle兩種兼容性租戶，這兩種兼容性租戶的核心代碼是有較大差異的，因此這兩種租戶在指標方面都不是拉齊的。比如等待事件只有Oracle租戶才有，某些MySQL租戶的指標在Oracle租戶中不見得有，因此我們無法對這兩種租戶采用相同的指標和健康模型。

第三個問題是Oceanbase自身的問題引發的，那就是Oceanbase不同大版本的兼容性問題。這是一個十分值得吐槽的問題，每次Oceanbase大版本升級，其系統視圖，指標體系，等待事件都會有較大的變化，運維工具必須做較大的調整。

第三個問題疊加第二個問題，讓Oceanbase的智能模型構建也變得復雜了，考慮到目前Oceanbase的大多數用戶還是在使用3.x版本，因此我們必須對3.x版本進行支持。2.x版本的支持可能要往后放一放了，因為2.x和3.x版本的差異依然巨大。在這種情況下，健康模型要根據三種子類分別根據4.X/3.X版本進行個性化定制，目前通過7個模型來覆蓋這些版本。

3.x和4.x版本之間的差異遠遠比增加一倍的健康模型要復雜的多，指標體系中也存在了大量的不兼容的指標，甚至描述同一個問題的指標會出現2個，一個代表4.X版本，一個代表3.x版本，而二者無法完全兼容，因為含義并不一定完全一致，如果用同一個指標來表示，很容易產生誤解。

第四個問題是集群與服務器節點之間的拓撲關系問題。一套大型的Oceanbase數據庫可能由數十個甚至上百個節點組成，并且上面跑了數十個租戶，這種拓撲關系十分復雜。雖然租戶之間但是他們依然存在關聯關系，因為他們共享集群中的所有服務器。服務器出現故障或者性能問題，可能會導致集群和租戶出現出現問題。因此我們在運維Oceanbase的時候依然必須關注服務器的健康。但是把服務器如何被納入監管呢？

最終我們的方案選擇了服務器在運維管理臺上隱身，通過集群拓撲入口來統一監控集群所依賴的服務器的方案。服務器出現異常時，健康模型與故障模型會發現其問題并主動報警，但是服務器并不出現在數據實例的監控清單里。不過在集群和租戶的集群拓撲里我們可以看到所有服務器的健康狀態，如果需要，可以進行下鉆。采用這種方式后，當服務器沒有故障或者隱患時，我們可以不去關注服務器，只要關注租戶的健康，而當服務器存在隱患時，我們可以獲得告警，并且有入口可以去做診斷分析。

經過這一年多與Oceanbase的深度接觸，我們找到了一種對復雜的多租戶分布式數據庫的運維監控與故障定位的方法，Oceanbase專版的發布后，我們會邀請客戶一起來進行測試，并通過對用戶現場數據的分析，豐富故障模型，完善智能基線，并積累更多的運維知識工具。通過數年的積累，我想Oceanbase的運維知識積累會一步步的豐富起來。