摘要:本文主要介紹GaussDB(DWS)數據庫智能監控運維服務體系的設計規劃和現狀。
本文分享自華爲雲社區《眼觀六路耳聽八方還不知疲倦?數倉智能運維服務體系是怎麼作到的?》,原文做者:魯大師。web
早期,數據庫系統僅僅提供SQL命令來查詢其內部的運行狀態,致使數據庫運維操做門檻高,易用性差,DBA一度成爲高度專業化的關鍵崗位,享受高薪和你們羨慕的目光的同時,也爲企業的數據安全帶來了不肯定性風險。而且,命令行運維不直觀,嚴重依賴運維人員經驗,不能作到快速的發現、定位、解決問題,致使數據庫運維問題,發現難,定位難,解決難。算法
爲了應對這個窘境,數據庫運行狀態可視化(數據庫監控系統)應運而生,經過可視化的手段以人類便於理解的圖表形式,將重點數據以圖形化的手段展現給運維人員,從而顯著的下降了數據庫運維的門檻,提升了數據庫運維的效率。這個階段有一些表明性的產品好比:OEM(Oracle), ViewPoint(Teradata),等等。可是,這個時期用戶的數據的規模不是很大,數據庫也依然部署在用戶本身的數據中心,依然是幾個DBA運維幾套數據庫的階段。數據庫
隨着雲時代的到來,雲數據庫逐漸託管了客戶的數據存儲服務,雲化將一切繁重的IT運維工做都集中在雲後臺管理了起來,從而把客戶從專業,複雜,繁重的數據中心運維活動中解放了出來,使客戶可以更加專一於其核心業務。同時,雲服務提供商做爲數據存儲服務的提供者,則須要在IT運維與數據庫運維上深耕細做,發揮其團隊穩定,專業化程度高,掌握海量數據庫運行數據的優點;充分利用目前機器學習、人工智能領域的科研成果,使用技術手段逐步提升每名運維人員所能管理的數據庫數量,從而實現數據庫運維工做的「減員增效」。另外一方面,數據庫服務上雲後,雲服務提供商所須要運維的數據庫數量與以前相比天差地別,之前的工具可能已經不適應雲時代的需求。如何作好雲上海量數據庫的運維工做將成爲雲服務提供商的一個巨大挑戰。segmentfault
傳統意義上的數據庫監控服務僅僅是指(1)採集數據庫運行狀態;(2)上報/存儲數據庫運行數據;(3)圖形化展現數據庫運行狀態數據。可是,這僅僅是數據庫智能監控運維體系的一部分。安全
若是把整個數據庫智能監控運維體系比做一我的的話,傳統意義上的數據庫監控服務僅僅表明了,眼睛的角色。該服務只能作到發現問題,識別定位問題和解決問題都須要DBA的介入。所以DBA纔是傳統數據庫監控運維體系中的核心要素,這也是DBA人才爲什麼如此關鍵的緣由之一。微信
而云時代的到來和大數據分析、人工智能等技術的成熟,給了數據庫監控運維更多的想象空間。我能夠在傳統數據庫監控(眼睛)的基礎上,增長預測分析和根因判斷模塊,創建現象-根因-解決方案的映射關係(大腦),最後經過數據庫管理模塊執行解決方案(雙手),從而實現從發現問題,定位問題,到解決問題的運維閉環。而且機器不一樣於人類,只要算力容許,它能夠作到眼觀六路,耳聽八方,不知疲倦,也不會以爲無聊,7x24的盯着成百上千數據庫系統的各類運行數據,不會放過任何一個微小的潛在問題。所以,數據庫運維工做的智能化中,使用規則或算法固化DBA判斷和決策經驗將是很是重要的一環。運維
參考友商數據庫監控運維體系的建設經驗,結合GaussBD(DWS)數倉的自身特色,咱們準備從眼,腦,手三個方面發力創建閉環的數據庫智能監控運維體系。機器學習
GaussDB(DWS)使用DMS來承載數據庫的智能運維體系。DMS將會串起數據庫運維過程當中的監控,分析,處理三個步驟,分別對應上文提到的數據庫智能運維體系中的眼,腦,手三部分,從概念設計上造成運維體系的閉環。數據庫設計
監控部分:主要負責數據庫運行狀態數據的採集、存儲和可視化展現,這一部分基本等同於傳統的數據庫的監控業務。這一部分功能和指標的選取,咱們參考了友商以及運維團隊的建議,將監控指標分爲底層IT系統運維指標和數據庫系統運維指標兩類,正在分別逐步補齊和完善中。監控模塊是DMS數據庫運智能監控運維體系首先發力,並要在短期內造成競爭力的模塊。工具
分析部分:做爲整個DMS數據庫智能運維體系的大腦,該部分是承擔運維數據分析與決策的關鍵模塊。該部分由於其複雜性,目前還處於設計構想階段。初步規劃有三個子模塊,時間序列的趨勢分析子模塊,該模塊主要用來作趨勢預測分析,用來預判潛在的問題;邏輯推斷子模塊,用戶分析問題現象與實際根因之間的關係,能夠實現從問題現象到觸發緣由的推斷,初步考慮使用搜索引擎技術實現;知識圖譜子模塊,主要用於現象、根因與解決方案之間的映射關係表示,方便從定位的根因中找到最合適的解決方案。
處理部分:主要由DWS提供的數據庫管理功能承擔,目前能夠提供數據庫參數配置(可配置參數少,須要進一步豐富),工做負載隊列配置,集羣安裝/卸載,集羣重啓,集羣擴容,集羣數據重分佈以及節點溫備等運維能力。
爲了進一步理清數據庫智能運維產品的設計思路,咱們計劃從用戶的角度分析其需求,而後從需求導出功能(工具)頁面設計,從功能(工具)頁面總結出所需監控數據庫指標。經過分析數據庫監控系統的各類使用場景,咱們對數據庫監控系統的用戶作了用戶角色畫像,定義了數據庫運維過程當中的三種角色,並認爲不一樣角色僅僅關注數據庫運維的一個側面。在實際的數據庫運維場景中,可能同一個用戶會身兼多種角色,可是這裏咱們爲了方便分析僅僅從邏輯上定義這三種角色。
應用開發:主要指客戶側的應用開發角色,他們負責設計具體的業務SQL。他們關心業務SQL執行的正確性和執行效率。應用開發工程師須要用到web SQL來調試其SQL語句的查詢效率;須要用到查詢監控頁面來查看業務SQL在實際執行場景中的表現和資源消耗;須要用到工做負載隊列監控來確認新開發的業務SQL是否在合適的工做負載隊列中,以及所配置的熔斷規則是否合理,等等。
SRE:指的是華爲雲側的數據庫運維角色,他們一般一我的須要負責成百上千個集羣的穩定運行,他們須要可以迅速識別出集羣運行狀態的異常,集羣資源瓶頸以及集羣潛在的擴容需求,而且他們還須要積極響應客戶的求助,幫助客戶定位,確認和解決問題。SRE須要節點資源監控來識別集羣中的資源傾斜;須要識別集羣資源消耗基線變化趨勢,從而識別到擴容需並提醒用戶;須要關注存儲變化以推算下一次常規保養的時間點並自動規劃;同時還須要響應用戶需求,使用DMS提供的問題定位工具,輔助用戶定位現網問題。
DBA:指的是GaussDB(DWS)數據庫集羣專家,他們熟悉數據庫設計方法論,數據庫的調優,數據庫問題定位。他們須要分析定位數據庫的故障,從資源和業務角度運用多種工具綜合分析定位系統故障,系統穩定性和潛在瓶頸;也須要幫助用戶從業務、數據庫設計的角度去推薦數據庫的索引,分佈列配置,根據用戶業務水平推薦用戶購買合適的集羣規模等等;同時還須要輔助應用開發工程師調優引發性能劣化的SQL語句;在找到確切的故障根因後,推薦合適的解決方案修復故障。
在通常來講在公有云場景中,用戶角色通常只有應用開發和SRE兩種,公有云場景中的SRE角色每每涵蓋了DBA的角色。咱們在這裏將運維角色細分的目的,實際上是要展現一個完整的運維場景沙盤,將客戶的運維訴求分門別類的羅列出來,爲後續進一步的功能(工具)頁面設計和運維場景設計提供基礎。
數據庫監控指標數量多,形式和邏輯複雜,根據指標類型能夠分爲邏輯關係與物理關係兩種。其中邏輯關係指數庫內部邏輯關係,好比,最頂層是數據庫,數據庫中有多個schema,schema中有多個表,數據庫中有多個用戶,一個用戶能夠有多個schema和表。而物理關係是指,gaussDB(DWS)集羣的拓撲關係,好比,一個數據庫集羣是由多個計算節點構成,每一個計算節點上會部署多個計算實例。這兩種指標關係都會影響到數據庫指標的採集維度和聚合展現維度。
由於上面已經分析了指標的維度關係,因此咱們下面將只討論具體的數據庫指標類型,而不會對指標的維度進行展開。數據庫是一個軟件服務,而它必須運行在一個宿主機和操做系統之上,所以監控指標大體能夠分爲兩類:
系統資源類指標:這一類指標主要描述系統上的各類資源消耗
數據庫相關指標:這一類指標主要描述數據性能相關的業務負載水平
上圖總結了DMS採集的數據庫主要指標,具體指標項按照指標大類,原子指標和派生指標三個層次排列。不過,目前該指標地圖並不固定,將來隨着GaussDB(DWS)智能運維繫統的逐步成熟,該指標地圖會逐步完善並固定下來。
由於MPP數據庫的特殊構型,數據庫實例是做爲進程試運行在節點上的。所以,咱們的指標設計其實自己會自帶維度屬性,好比磁盤使用率指標,最小的維度應該是某個DN實例,上一級是節點級,再上一級就是整個集羣。因此,咱們實際提供的監控指標應該是指標維度關係與集羣指標地圖的一個笛卡爾積。爲了描述這種情形,咱們引入原子指標,派生指標和組合指標的概念。以上面的磁盤使用率爲例,咱們將DN實例的磁盤使用率做爲原子指標,而其餘維度的磁盤使用率做爲派生指標。
目前DMS的指標建設更多停留在原子指標和派生指標階段,由於咱們認爲應該首先補齊數據庫的基礎指標造成基本的監控運維能力以後,才能結合用戶使用習慣,深度挖掘指標在各個維度下的運維含義以及多種指標組合後所表明的運維意義。
最後,總結一下,本文主要介紹了GaussDB(DWS)數據庫智能監控運維服務體系的設計規劃和現狀。本文做爲DMS系列文章的第一篇,主要起到一個概要介紹的做用,讓你們對GaussDB(DWS)數據庫智能監控運維服務體系有個概略的認識,更多幹貨細節歡迎期待後續的文章。
想了解GuassDB(DWS)更多信息,歡迎微信搜索「GaussDB DWS」關注微信公衆號,和您分享最新最全的PB級數倉黑科技,後臺還可獲取衆多學習資料哦~