GaussDB(DWS)數(shù)據(jù)庫智能監(jiān)控系統(tǒng)應(yīng)用場景分析

與互聯(lián)網(wǎng)產(chǎn)品的立項(xiàng)模式類似，當(dāng)我們定義設(shè)計(jì)一款新產(chǎn)品時(shí)，首先需要對用戶做需求分析，歸納整理綜合分析用戶的需求，定義我們的產(chǎn)品定位，功能，業(yè)務(wù)邏輯，使用界面等等。因此，為了設(shè)計(jì)好數(shù)據(jù)庫智能監(jiān)控系統(tǒng)，我們需要對數(shù)據(jù)庫監(jiān)控系統(tǒng)的目標(biāo)用戶做需求分析，收集用戶訴求，挖掘用戶潛在需求，繪制典型用戶畫像。最后，設(shè)計(jì)數(shù)據(jù)庫監(jiān)控系統(tǒng)的實(shí)現(xiàn)架構(gòu)，將典型用戶的各種需求納入到產(chǎn)品的設(shè)計(jì)架構(gòu)管道中。

數(shù)據(jù)庫智能監(jiān)控系統(tǒng)的用戶

實(shí)際應(yīng)用場景中，數(shù)據(jù)庫監(jiān)控系統(tǒng)的用戶可能會有很多種不同的角色。不同公司因?yàn)榻M織架構(gòu)不同，可能存在更細(xì)分或者更聚合的用戶角色。但是總的來說可以歸納整理為如下三種用戶類型：

應(yīng)用開發(fā)（APP DEV）

運(yùn)維工程師（SRE）

數(shù)據(jù)庫管理員（DBA）

應(yīng)用開發(fā)工程師角色：主要負(fù)責(zé)開發(fā)云應(yīng)用中的業(yè)務(wù)SQL，對云服務(wù)的功能和性能負(fù)責(zé)。同時(shí)需要保證寫出的SQL高效優(yōu)質(zhì)，不會對集群造成額外的資源消耗和時(shí)間消耗。因此，應(yīng)用開發(fā)工程師，需要能夠?qū)π麻_發(fā)的SQL進(jìn)行監(jiān)控，了解該新增查詢語句的執(zhí)行效率以及資源消耗情況。

運(yùn)維工程師角色：主要負(fù)責(zé)保證數(shù)據(jù)庫集群的長期穩(wěn)定運(yùn)行。需要分別從資源消耗和系統(tǒng)負(fù)載兩個(gè)角度對數(shù)據(jù)庫系統(tǒng)進(jìn)行評估。需要能夠配置數(shù)據(jù)庫的告警場景，并且可以看到實(shí)時(shí)或預(yù)測的數(shù)據(jù)庫告警信息，將發(fā)現(xiàn)的問題報(bào)告給數(shù)據(jù)庫管理員角色做進(jìn)一步處理。總的來說，運(yùn)維工程師角色會監(jiān)控大量的數(shù)據(jù)庫集群，他不會對每一個(gè)集群做非常深入的分析，而是更多的會以問題發(fā)現(xiàn)者的角色出現(xiàn)。

數(shù)據(jù)庫管理員角色：主要負(fù)責(zé)定位數(shù)據(jù)庫問題的根因并且提供相應(yīng)的解決方案。數(shù)據(jù)庫管理員需要是數(shù)據(jù)庫領(lǐng)域的專家，熟悉數(shù)據(jù)庫的方方面面，他可以從多個(gè)維度分析數(shù)據(jù)庫監(jiān)控?cái)?shù)據(jù)，定位數(shù)據(jù)庫故障，并提供解決方案。

需要說明的是，以上三種角色并不是指實(shí)際生產(chǎn)環(huán)境中的崗位，而是為了方便分析用戶需求而歸納總結(jié)出來的典型角色符號。實(shí)際生產(chǎn)環(huán)境中，可能出現(xiàn)三種角色為同一個(gè)人的場景，或者SRE崗位會身兼SRE與DBA角色的場景。我們這里將用戶區(qū)分為三種角色，主要是為了方便我們做需求分析并且構(gòu)建對應(yīng)的人物畫像，從而進(jìn)一步鎖定對應(yīng)角色人物所需要的工具。最終，呈現(xiàn)給大家一個(gè)思路清晰的數(shù)據(jù)庫監(jiān)控系統(tǒng)開發(fā)概念脈絡(luò)。

數(shù)據(jù)庫智能監(jiān)控系統(tǒng)工具及應(yīng)用場景

通過上面的抽象和梳理，我們發(fā)現(xiàn)在數(shù)據(jù)庫監(jiān)控運(yùn)維過程中三種角色分別對應(yīng)著不同的需求，而不同的需求必將導(dǎo)致不同工具或者同一個(gè)工具的不同側(cè)重點(diǎn)。下面我們圍繞三種角色，分別展開詳細(xì)介紹其將要用到的工具：

應(yīng)用開發(fā)角色，他們只關(guān)心自己寫的SQL是否高效，是否有利用到集群的各種優(yōu)化特性，是否占用了集群的過多資源？因此，他需要一個(gè)能夠讓他評估其所寫SQL執(zhí)行效率的工具，也就是WebSQL工具，允許用戶簡單的連接到數(shù)據(jù)庫，并且執(zhí)行SQL語句。WebSQL可以返回SQL語句的執(zhí)行結(jié)果，也可以返回其執(zhí)行計(jì)劃，幫助應(yīng)用開發(fā)角色，了解其SQL語句的執(zhí)行效率。同時(shí)，用戶的SQL語句并不是簡單的單條語句執(zhí)行的，而是需要將其放在整個(gè)作業(yè)流中去執(zhí)行的。那么衡量其在作業(yè)流中的執(zhí)行時(shí)間和資源消耗的基線就變得非常重要。因此，我們就需要查詢監(jiān)控可以針對特性的SQL記錄其執(zhí)行時(shí)間和資源的消耗，并且計(jì)算最大值，最小值和平均值，作為比對基線，來進(jìn)一步幫助用戶評估其SQL的執(zhí)行效率。在用戶現(xiàn)場，因?yàn)橘Y源隔離需求，用戶的作業(yè)是需要綁定到某個(gè)工作負(fù)載隊(duì)列執(zhí)行的，那么工作敷在隊(duì)里的資源配置，以及工作負(fù)載隊(duì)列的負(fù)載水平等數(shù)據(jù)又變得非常重要，新加的SQL語句是否會造成工作負(fù)載隊(duì)列的超載？當(dāng)前工作敷在隊(duì)列的資源是否合理，這個(gè)都需要應(yīng)用開發(fā)角色在新開發(fā)的應(yīng)用上線前有個(gè)直觀的了解。

系統(tǒng)運(yùn)維角色角色（SRE），他們關(guān)心云上數(shù)量龐大的數(shù)據(jù)庫系統(tǒng)的長穩(wěn)運(yùn)行，基于這個(gè)需求，我們打算提供三個(gè)方面的工具來解決問題。

健康指數(shù)指標(biāo)，該指標(biāo)是一個(gè)復(fù)合指標(biāo)，該指標(biāo)主要由兩方面的指標(biāo)支撐，資源消耗指數(shù)和數(shù)據(jù)庫系統(tǒng)負(fù)載指數(shù)。而這兩種指標(biāo)又有其更下一層的原子指標(biāo)和延伸指標(biāo)支撐。集群健康指數(shù)的計(jì)算需要設(shè)計(jì)一套相應(yīng)的數(shù)學(xué)模型，以該模型為基礎(chǔ)我們就可量化系統(tǒng)的健康指數(shù)，從而可以使系統(tǒng)管理員非常簡單的從云上數(shù)以百計(jì)的數(shù)據(jù)庫中快速發(fā)現(xiàn)有問題的數(shù)據(jù)庫。

除了健康指數(shù)這樣需要系統(tǒng)管理員親自去查看的被動指標(biāo)以外，DMS還會進(jìn)一步提供覆蓋全面的告警能力。DMS將從三個(gè)層次上提供數(shù)據(jù)庫的告警能力，（1）在dms-agent端，通過日志分析的手段，實(shí)時(shí)分析dms-agent所處節(jié)點(diǎn)上，操作系統(tǒng)以及數(shù)據(jù)庫的日志，當(dāng)發(fā)現(xiàn)威脅關(guān)鍵詞后，立刻觸發(fā)告警，通過相應(yīng)渠道上報(bào)到告警平臺；（2）在DMS服務(wù)端，因?yàn)镈MS擁有數(shù)據(jù)庫集群的全部監(jiān)控?cái)?shù)據(jù)，通過數(shù)據(jù)分析手段和數(shù)據(jù)庫專業(yè)知識，我們將能設(shè)計(jì)相應(yīng)的告警規(guī)則，周期性的對數(shù)據(jù)庫集群做檢查，發(fā)現(xiàn)問題后直接觸發(fā)告警；（3）對于DMS采集的數(shù)據(jù)庫集群指標(biāo)數(shù)據(jù)，能夠作為閾值告警的指標(biāo)，全部對接CES，通過CES服務(wù)做閾值告警。以上三種告警的配置和展示都需要在DMS的前端頁面上呈現(xiàn)。

人工智能與云計(jì)算有的天然的聯(lián)系，當(dāng)數(shù)據(jù)庫上云后，人工智能與數(shù)據(jù)庫運(yùn)維的交叉節(jié)點(diǎn)AIOps就順理成章的出現(xiàn)了。因?yàn)镈MS擁有數(shù)據(jù)集群的全部監(jiān)控?cái)?shù)據(jù)，因此使用歷史監(jiān)控?cái)?shù)據(jù)對集群的工作模式做判別，推薦最優(yōu)化的配置參數(shù)；對數(shù)據(jù)庫磁盤的空間增長趨勢做預(yù)測，提前通知用戶擴(kuò)容或運(yùn)維需求等等。在人工智能的加持下這一切都變成為可能。

數(shù)據(jù)庫管理員角色（DBA），數(shù)據(jù)庫管理員一直都是數(shù)據(jù)庫的大管家，在傳統(tǒng)的數(shù)據(jù)中心里，他們負(fù)責(zé)數(shù)據(jù)庫的性能優(yōu)化，也負(fù)責(zé)數(shù)據(jù)庫的長穩(wěn)運(yùn)行，有時(shí)候甚至也要幫助應(yīng)用開發(fā)工程師優(yōu)化SQL。但是在云時(shí)代，數(shù)據(jù)庫管理員的工作分工會變得更精細(xì)，應(yīng)用開發(fā)和系統(tǒng)管理員分擔(dān)了數(shù)據(jù)庫管理的一部分工作，從而使得數(shù)據(jù)庫管理員角色職責(zé)變的更純粹。數(shù)據(jù)庫管理員作為一個(gè)數(shù)據(jù)庫領(lǐng)域的專家，他將負(fù)責(zé)定位數(shù)據(jù)庫問題的根因，以及提供解決問題的方法。系統(tǒng)管理員+數(shù)據(jù)庫管理員兩個(gè)角色最終就形成了發(fā)現(xiàn)問題，分析問題，解決問題的任務(wù)閉環(huán)。因此，在云上，SRE崗位往往會包含SRE+DBA兩個(gè)角色的職責(zé)。

DBA是一個(gè)數(shù)據(jù)庫專家，也是一個(gè)使用數(shù)據(jù)庫工具定位各種數(shù)據(jù)庫問題的大師。針對問題根因定位，他將需要故障分析工具和故障自愈工具兩類工具。其中，故障分析工具，將會提供各種監(jiān)控?cái)?shù)據(jù)和數(shù)據(jù)的不同可視化形式，為數(shù)據(jù)庫管理員快速定位問題根因提供幫助。故障自愈類工具，則是將數(shù)據(jù)庫管理員過去定位問題，解決問題經(jīng)驗(yàn)的固化。未來隨著我們對DBA工作方法的進(jìn)一步了解，將會有越來越多的自愈類工具。

數(shù)據(jù)庫管理員另一類重要的職責(zé)就是提供故障的解決方案，這一塊是運(yùn)維系統(tǒng)非常重要的一環(huán)。再好的故障定位工具，定位到的問題，如果最后沒有解決方案，那么最終還是不能真正幫助到用戶。因此，我們需要建立一套問題根因-解決方案的專業(yè)搜索引擎，幫助用戶也是幫助我們加速解決問題的流程，緩解一線客戶支持工作人員的工作強(qiáng)度。

本文是介紹云上的數(shù)據(jù)庫監(jiān)控運(yùn)維體系設(shè)計(jì)的核心概念的三篇文章之二，嘗試從概念和邏輯上推導(dǎo)了基于用戶角色的數(shù)據(jù)庫智能監(jiān)控系統(tǒng)的可能應(yīng)用場景。有了這個(gè)基本框架，則我們后續(xù)所需要做的工作和工具都變得清晰可見。愿我們的期待早日成為顯示，讓云端的數(shù)據(jù)庫運(yùn)維工作變得更輕松與智能。

想了解GuassDB(DWS)更多信息，歡迎微信搜索“GaussDB DWS”關(guān)注微信公眾號，和您分享最新最全的PB級數(shù)倉黑科技，后臺還可獲取眾多學(xué)習(xí)資料哦~

EI企業(yè)智能 Gauss AP 云監(jiān)控服務(wù) 數(shù)據(jù)倉庫服務(wù) GaussDB(DWS) 數(shù)據(jù)庫

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實(shí)的內(nèi)容，請聯(lián)系我們jiasou666@gmail.com 處理，核實(shí)后本網(wǎng)站將在24小時(shí)內(nèi)刪除侵權(quán)內(nèi)容。

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實(shí)的內(nèi)容，請聯(lián)系我們jiasou666@gmail.com 處理，核實(shí)后本網(wǎng)站將在24小時(shí)內(nèi)刪除侵權(quán)內(nèi)容。