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

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

圖片

圖片

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

圖片

圖片

使用過D-SMART的用戶送GaussDB專版沒有任何學(xué)習(xí)成本，可以很輕松的通過工具去對(duì)GaussDB集群進(jìn)行分析。

圖片

配套的D-SMART V2.6版本提供了一個(gè)圖形化的集群拓?fù)洹Ｗ屃?xí)慣于圖形界面的DBA看起來更加舒適。    

圖片

在集群拓?fù)渖峡梢渣c(diǎn)擊CN/DN節(jié)點(diǎn)進(jìn)行下鉆。在D-SMART中，每個(gè)有分布式CN/DN節(jié)點(diǎn)和集中式DN節(jié)點(diǎn)三種子類型，目前我們把它們作為PG兼容子類來看待。因?yàn)镚aussDB和openGauss都有大量的監(jiān)控視圖與PG兼容，可以復(fù)用部分PG的工具，因此我們沒有給openGauss/GaussDB節(jié)點(diǎn)獨(dú)立的數(shù)據(jù)庫類別。雖然如此，GaussDB、openGauss和PostgreSQL三種數(shù)據(jù)庫子類在可觀測性視圖方面已經(jīng)有了很多差異。作為可觀測性能力而言，GaussDB>openGauss >PostgreSQL。更強(qiáng)的可觀測性意味著更為強(qiáng)大的自動(dòng)化/智能化分析能力。

圖片

故障模型告警和診斷工具依然沿用D-SMART傳統(tǒng)的模式，目前工具的開發(fā)還在持續(xù)進(jìn)行中，不過基于運(yùn)維知識(shí)圖譜的通用分析工具已經(jīng)是可用的了。智能指標(biāo)分析與告警時(shí)序分析、等待事件智能分析等工具已經(jīng)可以使用了。    

圖片

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

故障模型是對(duì)數(shù)據(jù)庫運(yùn)維經(jīng)驗(yàn)的一種總結(jié)，能夠構(gòu)建其豐富的故障模型對(duì)于承載大型關(guān)鍵應(yīng)用系統(tǒng)十分關(guān)鍵。而故障模型的構(gòu)建依賴于強(qiáng)大的可觀測能力，以及將數(shù)據(jù)庫狀態(tài)指標(biāo)化的能力，再輔以專家的經(jīng)驗(yàn)才能完成。這種能力可以讓一些原本需要專家才能發(fā)現(xiàn)的問題實(shí)現(xiàn)自動(dòng)化發(fā)現(xiàn)與自動(dòng)化預(yù)警。

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

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