D-SMART高斯專版已經開發了幾個月了，目前主要技術問題都已經解決，也能夠初步看到大概的面貌了。有朋友問我，Gaussdb不已經有了TPOPS了，為什么你們還要開發D-SMART高斯專版呢？實際上TPOPS和D-SMART雖然都可以用于Gaussdb的運維監控，不過其分工還是十分明顯的。TPOPS是華為GaussDB自帶的運維工具，從數據庫部署開始就一直可以使用。TPOPS+DBMind也具有一定的運維分析能力，不過這些功能都是基于傳統的運維管理理念的。D-SMART是一個運維知識自動化系統，其目的是實現更加數字化的運維監控、故障預警、根因分析（RCA）、自動化巡檢等，今后還會依托D-SMART的數據構建線上的SAAS生態。D-SMART是一個十分強大的知識自動化平臺，可以不斷沉淀用戶自己的運維知識，包括各種健康模型、故障模型和診斷工具。這些都是TPOPS不具備的功能，因此D-SMART可以作為TPOPS的有效補充。

另外一方面，D-SMART高斯專版會支持所有的高斯生態產品，包含華為GaussDB集中式/分布式，openGauss、南大通用GBASE 8C、海量Vastbase、神通數據庫、磐維、MogDB等。

圖片

圖片

D-SMART是從運維視角來看待GaussDB的。從入口上，D-SMART與TPOPS的視角就完全不同。    

圖片

圖片

使用過D-SMART的用戶送GaussDB專版沒有任何學習成本，可以很輕松的通過工具去對GaussDB集群進行分析。

圖片

配套的D-SMART V2.6版本提供了一個圖形化的集群拓撲。讓習慣于圖形界面的DBA看起來更加舒適。    

圖片

在集群拓撲上可以點擊CN/DN節點進行下鉆。在D-SMART中，每個有分布式CN/DN節點和集中式DN節點三種子類型，目前我們把它們作為PG兼容子類來看待。因為GaussDB和openGauss都有大量的監控視圖與PG兼容，可以復用部分PG的工具，因此我們沒有給openGauss/GaussDB節點獨立的數據庫類別。雖然如此，GaussDB、openGauss和PostgreSQL三種數據庫子類在可觀測性視圖方面已經有了很多差異。作為可觀測性能力而言，GaussDB>openGauss >PostgreSQL。更強的可觀測性意味著更為強大的自動化/智能化分析能力。

圖片

故障模型告警和診斷工具依然沿用D-SMART傳統的模式，目前工具的開發還在持續進行中，不過基于運維知識圖譜的通用分析工具已經是可用的了。智能指標分析與告警時序分析、等待事件智能分析等工具已經可以使用了。    

圖片

基于GaussDB強大的可觀測能力，目前故障模型的梳理工作也進展順利，和一些其他的國產數據庫不同的是，我們明顯感到能夠梳理出來的故障模型數量太多了，剛剛發布的時候可能就會有上百個故障模型，比我們2018年發布Oracle版本時的故障模式數量還要多出不少。    

故障模型是對數據庫運維經驗的一種總結，能夠構建其豐富的故障模型對于承載大型關鍵應用系統十分關鍵。而故障模型的構建依賴于強大的可觀測能力，以及將數據庫狀態指標化的能力，再輔以專家的經驗才能完成。這種能力可以讓一些原本需要專家才能發現的問題實現自動化發現與自動化預警。

目前我們針對GaussDB的故障模型涉及組件健康狀態、容量、高可用、并發、負載、性能、資源、實例健康、任務等維度。實際上這是針對GaussDB集群的故障模型，針對每個組件，比如CN/DN，以及承載CN/DN的服務器也都會設計故障模型。這樣才能保證整個數據庫運行環境出現問題，都能夠被提前發現。

分布式數據庫的運維工具開發起來比較麻煩，在前面的開發過程中我們也遇到了很多問題，比如DN節點的切換后，系統能否立即無縫跟蹤到這個變化，如果復制組中存在硬件配置上的不同，可能會影響模型的評估，如何能夠在每隔2-3分鐘的評估中避開數據錯誤，這些都在不斷的完善中。這個月底希望有一個評估版本可以完成，屆時也希望生產環境中有GaussDB的朋友能一起合作來驗證工具。有興趣的朋友可以關注“DBAIOPS社區”公眾號給我們留言。