国产日韩欧美一区二区三区三州_亚洲少妇熟女av_久久久久亚洲av国产精品_波多野结衣网站一区二区_亚洲欧美色片在线91_国产亚洲精品精品国产优播av_日本一区二区三区波多野结衣 _久久国产av不卡

?

基于人工智能方法的數(shù)據(jù)庫智能診斷?

2021-05-23 13:17:24金連源李國良
軟件學報 2021年3期
關(guān)鍵詞:根因監(jiān)控數(shù)據(jù)庫

金連源,李國良

(清華大學 計算機科學與技術(shù)系,北京 100084)

IT 運維,指的是和IT 服務管理相關(guān)的人員及管理過程,IT 運維可以讓公司提供的服務保持良好的質(zhì)量,并且使服務達到用戶付款后的預期.運維在人類未來的生產(chǎn)生活中的作用會越來越重要.2017 年,清華大學裴丹提出“預計到2020 年,全球?qū)⒂?00 億到1 000 億的IT 設備,這些設備會承載無數(shù)的服務,覆蓋互聯(lián)網(wǎng)、金融、物聯(lián)網(wǎng)、智能制造、電信、電力網(wǎng)絡、政府等等的生產(chǎn)生活的方方面面”(https://yq.aliyun.com/articles/272155).在運維發(fā)展的過程中,最先出現(xiàn)的是依靠手工的運維;后來,人們把重復的手工操作代碼化,基于大量腳本的自動化運維就開始流行了起來;其后又出現(xiàn)了DevOps 和智能運維[1].智能運維,指的是使用大數(shù)據(jù)、機器學習技術(shù)來支持IT 運維.機器學習可以處理海量的監(jiān)控數(shù)據(jù)并且提供強大的推斷能力.目前已經(jīng)有許多公司和研究機構(gòu)使用智能運維技術(shù)在許多方向取得了非常顯著的進展,包括云數(shù)據(jù)庫服務質(zhì)量分析[2]、磁盤故障的預測[3]、微服務故障的定位[4]等等.

數(shù)據(jù)庫是各種企業(yè)常用的系統(tǒng)軟件,根據(jù)所執(zhí)行任務的不同,可以將數(shù)據(jù)庫分為執(zhí)行大量簡單事務的OLTP 型數(shù)據(jù)庫、執(zhí)行復雜分析任務OLAP 型數(shù)據(jù)庫和兼顧執(zhí)行上述兩種任務的TATP 型數(shù)據(jù)庫.作為一種傳統(tǒng)的系統(tǒng)軟件,近年來出現(xiàn)了許多利用人工智能技術(shù)優(yōu)化數(shù)據(jù)庫部件的工作[5],可以發(fā)現(xiàn),人工智能技術(shù)賦能的數(shù)據(jù)庫具有更加強大的綜合能力,智能運維技術(shù)在數(shù)據(jù)庫領(lǐng)域也有著廣泛的應用場景.

本研究聚焦于智能運維中的OLTP 環(huán)境數(shù)據(jù)庫性能異常監(jiān)測診斷,在數(shù)據(jù)庫性能下降時發(fā)現(xiàn)問題并診斷問題發(fā)生的根因.該問題有如下幾個難點.

? 監(jiān)控指標和數(shù)據(jù)庫性能異常之間的對應關(guān)系比較復雜,一種根因所引發(fā)的異常往往會導致多個監(jiān)控指標出現(xiàn)問題,而單個監(jiān)控指標的異??赡苡刹煌母蛩鶎е碌?此外,系統(tǒng)中會存在數(shù)百個指標,因此,采用簡單的規(guī)則來進行數(shù)據(jù)庫異常診斷精確度不高;

? OLTP 環(huán)境下的數(shù)據(jù)庫執(zhí)行的是大量簡單的事務,如果監(jiān)控指標數(shù)據(jù)成本較大,可能會使執(zhí)行時間較短的事務變慢,帶來數(shù)據(jù)庫性能下降的問題;

? 由于OLTP 任務請求的不穩(wěn)定性以及操作系統(tǒng)、數(shù)據(jù)庫系統(tǒng)的復雜性,監(jiān)控指標中會有許多噪音,在這類監(jiān)控指標中提取有用信息難度較大.

下面是關(guān)于第一個難點的一個具體案例:當我們執(zhí)行數(shù)據(jù)庫備份操作的時候,我們觀察到了很多指標均產(chǎn)生了異常,其中包括了CPU、I/O、中斷計數(shù),數(shù)據(jù)庫等待進程等等,如圖1 所示.

Fig.1 Anomaly metrics triggered by database backup圖1 數(shù)據(jù)庫備份引發(fā)的監(jiān)控指標異常

同一個指標的異??赡苁怯刹煌母蛩斐傻?我們以CPU 統(tǒng)計指標舉例,可以看到:在外部進程搶占CPU、數(shù)據(jù)庫備份和數(shù)據(jù)庫外部文件導入這3 個根因下,CPU 的指標均產(chǎn)生了異常.

圖2 展示了在3 種異常觸發(fā)的時候,CPU 指標變化的示意圖.這是因為以上3 個行為均需要計算機提供較高的計算資源.通過可視化我們發(fā)現(xiàn),其他很多的指標均存在著相似的性質(zhì).因此,我們很難從單個異常的指標去推定數(shù)據(jù)庫性能異常問題的根因.

Fig.2 CPU metrics under different anomaly cases圖2 不同異常下,CPU 監(jiān)控指標

已有的數(shù)據(jù)庫異常診斷方法并不完全適用于我們的問題,這些方法中有的過于依賴專家知識,需要依靠有經(jīng)驗DBA 設計模型[6],并且這些模型只適用于一種數(shù)據(jù)庫,不具備遷移性;還有的需要通過修改數(shù)據(jù)庫系統(tǒng)源代碼的方式獲取細粒度監(jiān)控信息[7],雖然提高了診斷的精度,但是這樣既增加了開銷,也帶來更大的系統(tǒng)維護成本.

針對以上的問題,本文作者提出了一種自動、輕量級的監(jiān)控診斷框架AutoMonitor.通過模擬數(shù)據(jù)庫故障分析挖掘數(shù)據(jù)庫性能故障下的一系列監(jiān)控指標所表現(xiàn)出來的特征,使用基于深度循環(huán)神經(jīng)網(wǎng)絡的模型完成對數(shù)據(jù)庫性能異常的監(jiān)控.在這里,循環(huán)神經(jīng)網(wǎng)絡能以較低的成本和較快的速度完成對時序數(shù)據(jù)進行建模,并捕捉不同監(jiān)控指標之間的相關(guān)性,進而實現(xiàn)高質(zhì)量的異常監(jiān)測.針對監(jiān)控指標的數(shù)據(jù)特點,提出了基于Kolmogorov-Smirnov 檢驗的異常指標提取算法.該方法利用異常時序數(shù)據(jù)統(tǒng)計分布的差異來判斷是否為異常監(jiān)控指標,模擬人眼判斷異常的過程,并且有一定的魯棒性.最后,我們使用優(yōu)化的K近鄰算法挖掘了異常監(jiān)控指標和異常根因之間的對應關(guān)系,實現(xiàn)了數(shù)據(jù)庫異常根因診斷.相比于其他方法,我們這種基于特征距離比較的方法不僅利用了所有監(jiān)控指標信息,而且還考慮到了不同監(jiān)控指標的重要性,因而具有更高的診斷精度.

本文第1 節(jié)是相關(guān)工作的介紹.第2 節(jié)是論文總體研究方案的介紹.第3 節(jié)是論文所使用到的算法的具體描述.第4 節(jié)是關(guān)于實驗結(jié)果展示和分析.第5 節(jié)是對于本文的總結(jié).

1 相關(guān)工作

國內(nèi)外有許多關(guān)于系統(tǒng)性能診斷的研究工作,針對系統(tǒng)面向不同的任務,我們將這些工作分成面向OLTP環(huán)境和面向OLAP 環(huán)境這兩個大類上面.OLTP 環(huán)境下,單條SQL 比較簡單,執(zhí)行的時間也比較短.因此,面向OLTP 環(huán)境的自診斷方法考慮整體工作負載的性能問題.OLAP 環(huán)境下,SQL 語句比較復雜,因此診斷時主要考慮單條SQL 語句的執(zhí)行效率問題.

根據(jù)自診斷方法的不同,我們可以將自診斷方法分成基于專家結(jié)構(gòu)模型的和基于機器學習的方法:前者利用專家知識構(gòu)建的結(jié)構(gòu)模型、決策樹模型或者知識庫進行診斷,后者則是利用歷史運行數(shù)據(jù)結(jié)合已經(jīng)標注的數(shù)據(jù)進行診斷.在有些文獻中,這兩種方法都會使用.

1.1 面向OLTP環(huán)境

Yoon 等人[8]提出了數(shù)據(jù)庫性能輔助診斷框架DBSherlock,該框架可以監(jiān)控數(shù)據(jù)庫運行期間的若干運行指標,當出現(xiàn)性能問題的時候,用戶就可以劃出性能異常的區(qū)域,讓DBSherlock 找出可能出現(xiàn)異常的指標.這些異常的指標具有較強的劃分能力,即給定一個關(guān)于指標的斷言(形如Attr>k),使用這個斷言可以把落在正常區(qū)域內(nèi)的點和落在異常區(qū)域內(nèi)的點分開.根據(jù)這些異常的指標,用戶就可以找出問題發(fā)生的原因.DBSherlock 可以將用戶的反饋整合成因果模型,因果模型的原因是數(shù)據(jù)庫性能問題的根因,結(jié)果是一些關(guān)于異常指標的斷言,這些模型會用到未來的推斷里去.DBSherlock 還在語義層面對因果模型進行合并,實驗表明,這種方法大大提高了模型的診斷能力.

Benoit 等人[6]提出了數(shù)據(jù)庫性能自動診斷框架,和之前工作不同的是,該框架不僅可以對數(shù)據(jù)庫性能問題進行診斷,還將診斷和調(diào)優(yōu)這兩個部分利用決策樹的模型統(tǒng)一在一起,決策樹的非葉節(jié)點是條件判斷,而決策樹的葉節(jié)點是需要調(diào)優(yōu)的資源.對于一次關(guān)于數(shù)據(jù)庫的診斷,系統(tǒng)會根據(jù)數(shù)據(jù)庫當前的狀態(tài)從根節(jié)點出發(fā),根據(jù)非葉節(jié)點的條件選擇子節(jié)點進行訪問.系統(tǒng)重復以上的步驟,直至到達葉節(jié)點,葉節(jié)點的資源即是我們需要調(diào)優(yōu)的資源.此外,框架對于數(shù)據(jù)庫的負載和資源分別進行了建模,利用數(shù)據(jù)庫的結(jié)構(gòu)信息提升了準確性,作者還會使用不同資源配置下數(shù)據(jù)庫運行的性能結(jié)果調(diào)優(yōu)決策樹.不過,該決策樹模型的模型需要依賴特定的數(shù)據(jù)庫文檔以及數(shù)據(jù)庫專家的領(lǐng)域知識,因此通用性不是很強.

Belknap 等人在文獻[7]中介紹了Oracle 中SQL 診斷工具Automatic Database Diagnostic Monitor(ADDM),在這項工作中,作者引入了數(shù)據(jù)庫性能的衡量通貨“數(shù)據(jù)庫時間(database time)”,即數(shù)據(jù)庫各個資源模塊、數(shù)據(jù)庫語句執(zhí)行的各個階段的運行時間,并且在這個基礎(chǔ)上建立了圖模型DBTime graph,通過對圖的搜索,我們就可以定位問題.針對統(tǒng)計信息收集成本開銷過大的問題,文獻里提出一種基于采樣的方法(active session history),即每隔一段時間觀察用戶的行為,Database Time 大的模塊更加容易被采樣到,診斷系統(tǒng)也會相應地重點分析.

Ma 等人[9]針對OLTP 數(shù)據(jù)庫中間歇性的慢查詢,提出了診斷框架iSQUAD,包含了異常抽取、相關(guān)性清楚、基于類型的模式集成聚類以及貝葉斯樣例模型這4 個部分.作者將該方法應用于阿里云數(shù)據(jù)庫的實際數(shù)據(jù)中,取得了較好的實驗效果.

1.2 面向OLAP環(huán)境

Borisov 等人[10]提出了診斷工具DIADS,它適用在以SAN 為底層存儲結(jié)構(gòu)的DBMS 上面,注釋計劃圖(annotated plan graph)是文獻[10]中主要用到的模型,該圖分為Query Layer,Database Layer 和SAN Layer:Query Layer 的內(nèi)容是數(shù)據(jù)庫的查詢計劃(因為是OLAP 場景,計劃較為復雜),Database Layer 則是數(shù)據(jù)庫相關(guān)性能運行指標,SAN Layer 則是存儲的物理體系結(jié)構(gòu).通過將查詢計劃里的操作符和相關(guān)的物理、邏輯硬件資源通過圖的方式聯(lián)系在一起,就能在查詢出現(xiàn)性能問題時,使用該模型結(jié)合歷史數(shù)據(jù)進行診斷.當查詢執(zhí)行時間和預期不符的時候,系統(tǒng)會根據(jù)查詢計劃提取每一個操作符所消耗的時間,將異常的操作符使用機器學習算法提取出來,再根據(jù)注釋計劃圖模型找出異常的硬件資源完成診斷.

Kalmegh 等人[11]提出了框架iQCAR,該框架適用于大數(shù)據(jù)分析處理系統(tǒng)Apache Spark 上,主要的功能是分析一個查詢在運行的時候受到系統(tǒng)中并發(fā)執(zhí)行的查詢的影響.該研究的主要貢獻在于定性地分析查詢間資源搶占的影響,并且提供了多粒度的分析.該研究首先聚焦于不同的任務關(guān)于單個資源的搶占問題,作者在這里提出了阻塞時間(blocked time)這一個概念,即單個工作獲取一個特定的資源時的等待時間;此外,作者還提出了資源獲取時間懲罰(resource acquire time penalty)來衡量一個任務獲取特定的資源的效率.在建立相關(guān)概念以后,作者定量地分析了一個查詢在獲取資源時,其他并發(fā)的查詢對其阻塞造成的貢獻.接著,作者構(gòu)建了iQC-graph,這是一個層級結(jié)構(gòu)的圖模型,每一層代表著查詢執(zhí)行過程不同的粒度,根據(jù)該圖分析查詢不同執(zhí)行過程的性能情況.

2 總體研究方案概覽

為了實現(xiàn)對數(shù)據(jù)庫運行狀況進行監(jiān)控和診斷,AutoMonitor 需要實時地收集數(shù)據(jù)庫執(zhí)行任務時相關(guān)的統(tǒng)計信息,并分析這些數(shù)據(jù)的變化情況.我們設計的異常診斷系統(tǒng)總體框架如圖3 所示,設計的框架分為兩個主要階段:第1 階段是離線的數(shù)據(jù)分析,第2 階段是在線實時的異常監(jiān)測和根因診斷.

(1)關(guān)于離線的部分.

系統(tǒng)的主要任務是訓練在線階段所使用的模型,共有兩部分訓練數(shù)據(jù).

? 一部分是異常時間序列數(shù)據(jù),這部分數(shù)據(jù)通過模擬數(shù)據(jù)庫異常收集而來,它是高維的時序數(shù)據(jù),每一維對應一種監(jiān)控指標的結(jié)果,它們被用來確定每一種根因觸發(fā)的異常下監(jiān)控指標的特征,系統(tǒng)使用Kolmogorov-Smirnov 檢驗給出每一維指標的異常程度,挖掘有異常的監(jiān)控指標,然后將這些異常指標和正常指標拼接在一起,生成維數(shù)固定的異常特征向量,該向量將用于優(yōu)化的K近鄰算法中.此外,對于每一種異常的診斷,我們需要確定對應的重要監(jiān)控指標,每個監(jiān)控指標的重要性由數(shù)值αi決定,越重要的指標,對應的αi越大.相比于普通K近鄰算法直接使用歐幾里得距離進行相似度的計算,優(yōu)化的K近鄰算法在相似度計算時會涉及αi,使得系統(tǒng)對于根因不同但是表現(xiàn)相似的異常具有更強的判別能力,αi的具體計算方法將在第3.3 節(jié)描述;

? 另一部分是數(shù)據(jù)庫正常運行狀態(tài)下的數(shù)據(jù),該部分數(shù)據(jù)的結(jié)構(gòu)和異常數(shù)據(jù)相似,區(qū)別在于我們沒有手動注入異常,它們被用以LSTM 循環(huán)神經(jīng)網(wǎng)絡的訓練,訓練以后的模型對于正常監(jiān)控時序數(shù)據(jù)具有較強的重構(gòu)能力,即:將一段時序數(shù)據(jù)依次輸入到模型,經(jīng)過處理保存中間結(jié)果在一個隱狀態(tài)里,模型再從該狀態(tài)開始逐步重建還原輸入的時序數(shù)據(jù).系統(tǒng)的最終目標是讓輸入和輸出的時序數(shù)據(jù)盡可能地相似.當異常時序數(shù)據(jù)進入模型時,由于正常和異常時序數(shù)據(jù)在結(jié)構(gòu)上的差異,重構(gòu)的結(jié)果會帶來較大的誤差,如此,系統(tǒng)便獲得異常監(jiān)測的能力.

(2)關(guān)于在線的部分.

當用戶執(zhí)行工作負載的時候,系統(tǒng)將實時地監(jiān)控信息輸入到數(shù)據(jù)庫中.模型實時從數(shù)據(jù)庫讀取這部分時間序列數(shù)據(jù)并進行異常監(jiān)測,當監(jiān)測異常值高于警報閾值(該閾值在離線階段由歷史異常數(shù)據(jù)和正常數(shù)據(jù)共同確定,目標是最大化診斷準確度)的時候,便認為此時出現(xiàn)了異常,然后啟動根因分析模塊進行診斷分析.系統(tǒng)先提取未知異常的異常特征向量,然后使用優(yōu)化的K近鄰算法將未知根因的異常特征向量和已知根因的異常特征向量進行相似度比較,從而讓用戶可以獲取異常監(jiān)控指標和該問題可能的根因.系統(tǒng)會將診斷的結(jié)果匯總成報告反饋給用戶.

Fig.3 Anomaly diagnosis system architecture圖3 異常診斷系統(tǒng)結(jié)構(gòu)示意圖

AutoMonitor 系統(tǒng)收集的統(tǒng)計信息主要包含了兩個部分,分別來自于操作系統(tǒng)和數(shù)據(jù)庫系統(tǒng),我們使用了不同的方法收集這兩部分數(shù)據(jù).

? 出于統(tǒng)計信息的可獲得性和數(shù)據(jù)庫部署的實際性考慮,我們選定Linux 作為研究的操作系統(tǒng).Linux 系統(tǒng)會自動維護系統(tǒng)運行的相關(guān)統(tǒng)計數(shù)據(jù)并存放在特定的目錄下,系統(tǒng)使用開源工具dstat 收集整合這個一部分的信息,其中的監(jiān)控指標涉及到CPU、I/O、網(wǎng)絡、中斷等部件;

? PostgreSQL 內(nèi)置了多個統(tǒng)計信息視圖,記錄了數(shù)據(jù)庫、數(shù)據(jù)表、索引和連接用戶等模塊的統(tǒng)計信息.通過對視圖構(gòu)造查詢,就可以定時地獲取DBMS 相關(guān)的監(jiān)控數(shù)據(jù).我們將構(gòu)造的監(jiān)控數(shù)據(jù)查詢寫成插件集成到dstat 的工具里,在dstat 運行的時候,它會定時讀取這一部分的數(shù)據(jù)并和操作系統(tǒng)的數(shù)據(jù)相對齊.考慮到PostgreSQL 內(nèi)置統(tǒng)計信息的更新頻率以及查詢開銷,在默認情況下,系統(tǒng)選擇1 秒作為信息收集的間隔.

需要注意的是:以上兩部分數(shù)據(jù)是操作系統(tǒng)和數(shù)據(jù)庫自動維護生成的,使用該系統(tǒng)并不需要修改操作系統(tǒng)和數(shù)據(jù)庫,這也保證在添加監(jiān)控以后數(shù)據(jù)庫的性能不會受太大的影響.

當用戶需要使用AutoMonitor 時,系統(tǒng)首先會啟動dstat,開始監(jiān)控指標數(shù)據(jù)的收集.dstat 從系統(tǒng)目錄以及PostgreSQL 視圖中讀取這部分數(shù)據(jù),并將收集到的數(shù)據(jù)定時寫入數(shù)據(jù)庫中,然后自動監(jiān)測程序定時從數(shù)據(jù)庫讀取最新的時序數(shù)據(jù),并將這一段時間的數(shù)據(jù)輸入到LSTM 模型進行異常監(jiān)測.如果AutoMonitor 認為此時出現(xiàn)了異常,就調(diào)用根因診斷程序,并將這段時序數(shù)據(jù)傳入進行根因診斷.最終的結(jié)果會以報告的形式反饋給網(wǎng)頁端的用戶.

3 算法描述

3.1 異常監(jiān)測

我們使用基于LSTM 的編碼器-解碼器模型來進行針對高維時間序列異常監(jiān)測[12].給定一段時間監(jiān)控指標數(shù)據(jù)的時間序列,系統(tǒng)可以判斷它是正常還是異常的.該算法的主要思想是:構(gòu)造一個編碼器-解碼器,如圖4 所示,它的輸入是一段時間的高維監(jiān)控指標數(shù)據(jù),輸出是同樣長度、同樣維度的時序數(shù)據(jù).即:該模型對于一段時間序列按逆序進行重建,根據(jù)重建結(jié)果的好壞來判斷時間序列的異常性.在訓練的階段,我們只使用正常的數(shù)據(jù)來訓練LSTM 神經(jīng)網(wǎng)絡,網(wǎng)絡的損失函數(shù)是序列重構(gòu)結(jié)果的誤差.如此訓練下,LSTM 網(wǎng)絡就獲得了對于正常序列較好的建模能力,當異常時間序列輸入的時候,模型就會產(chǎn)生較大的重構(gòu)誤差.在網(wǎng)絡結(jié)構(gòu)部分采用了深層的長短期記憶網(wǎng)絡和Attention 機制[13],以提高模型擬合數(shù)據(jù)的能力.

Fig.4 Encoder-decoder structure diagram圖4 編碼器-解碼器結(jié)構(gòu)示意圖

下面是具體算法的描述.

算法1.異常時序數(shù)據(jù)監(jiān)測算法.

輸入:正常的時間序列sN,vN1,總訓練輪數(shù)Epoch;

輸出:誤差協(xié)方差矩陣Σ,誤差向量μ.

由于在實際應用的過程中,異常數(shù)據(jù)的收集較為困難,因此在設定算法的異常閾值中,我們使用了一種基于極值理論(extreme value theory)[14]的方法,該方法大致原理如下:假定異常數(shù)據(jù)在一個數(shù)據(jù)集中出現(xiàn)的概率很小,我們設定一個較小的異常概率;然后,結(jié)合數(shù)據(jù)集求解對應的異常閾值.首先,在數(shù)據(jù)中選取一個分位數(shù)(例如0.95);然后選取大于分位數(shù)的小部分數(shù)據(jù),根據(jù)極值理論,這一部分數(shù)據(jù)經(jīng)過線性變換以后滿足帕累托分布.首先使用極大似然估計的方法求解該帕累托分布的參數(shù),然后根據(jù)概率求解異常閾值.具體的公式如下:

在這里,zq是最后求解的閾值,t是分位數(shù)的值,?σ和?γ是帕累托分布的參數(shù)估計結(jié)果,q是預先設定異常閾值的概率,n是總的數(shù)據(jù)集樣本數(shù),Nt是分位數(shù)下的樣本數(shù).由于異常監(jiān)測涉及到流式的數(shù)據(jù),因此在實際應用的過程中,系統(tǒng)會實時的更新帕累托分布的相關(guān)參數(shù)和異常閾值,進而保證異常監(jiān)測的實時精確性.

選用該算法有如下的優(yōu)勢.

? LSTM是一種用于有效時間序列分析的神經(jīng)網(wǎng)絡,監(jiān)控數(shù)據(jù)可能存在相互關(guān)聯(lián)的情況,而LSTM網(wǎng)絡可以較好地捕捉高維數(shù)據(jù)的關(guān)聯(lián)性;

? 相比于一些針對時間序列異常點的算法,在數(shù)據(jù)庫監(jiān)控的時候,更加關(guān)注區(qū)域的異常而不是單點的異常.這種考慮一段時間數(shù)據(jù)異常性的策略,讓監(jiān)控魯棒性更強;

? 在設定異常閾值的時候,不需要事先獲得異常數(shù)據(jù)的樣本,而是通過設定一個異常發(fā)生的概率來進行異常閾值的求解.在實際應用的過程中,用戶可以根據(jù)業(yè)務的實際需求來調(diào)整這個概率.另外,這種異常監(jiān)測的方法可以在流數(shù)據(jù)的環(huán)境下動態(tài)地調(diào)整閾值,可以適應實際場景下數(shù)據(jù)的動態(tài)偏移.

3.2 監(jiān)控指標提取

在找到異常區(qū)域以后,AutoMonitor 需要找出該異常下具有較強特征的指標,即:系統(tǒng)需要模仿DBA 自動收集在異常區(qū)域下形狀特異的監(jiān)控指標,并且能定量地描述這種異常的程度.

我們設計了基于滑動窗口的Kolmogorov-Smirnov 檢驗方法來解決此問題.Kolmogorov-Smirnov 檢驗是一種統(tǒng)計檢驗方法,可以用來比較兩組數(shù)據(jù)分布的相似程度.它的一個優(yōu)點就是:它是一種非參數(shù)的檢驗方法,相比于T 檢驗,不需要提前假設數(shù)據(jù)的分布,即使少量的點出現(xiàn)偏差,也不會對整體結(jié)果產(chǎn)生大的影響.因此,在小樣本、噪音較大的數(shù)據(jù)場景下具有更高的穩(wěn)定性.

該方法的有效性基于以下兩個假設.

? 在發(fā)生異常以后,一些特征明顯的指標的數(shù)據(jù)分布會發(fā)生較大的改變;

? 在數(shù)據(jù)庫正常運行的狀態(tài)下,指標點的分布在一段時間里是穩(wěn)定的,即滿足一個未知的分布.

我們在實踐中發(fā)現(xiàn),大多數(shù)監(jiān)控指標都滿足以上的假設.對于那些呈線性單調(diào)遞增的指標,我們使用差分的策略來進行預處理.考慮到根因發(fā)生具體觸發(fā)的時間難以定位,一些指標的記錄也會有滯后性,只能在一個時間窗口內(nèi)處理數(shù)據(jù).設想時間窗口內(nèi)的數(shù)據(jù)被分成了3 段:前兩段是正常的數(shù)據(jù),第三段是異常的數(shù)據(jù).系統(tǒng)會對前兩段數(shù)據(jù)進行Kolmogorov-Smirnov 檢驗,然后對后兩段數(shù)據(jù)進行Kolmogorov-Smirnov 檢驗.檢驗后,統(tǒng)計量結(jié)果的差值即作為該指標異常的評價依據(jù).因為具體的異常發(fā)生點是未知的,系統(tǒng)會在一個時間窗口內(nèi)進行多次計算整合結(jié)果.在監(jiān)控指標提取以后,每一個的數(shù)據(jù)庫異常實例被轉(zhuǎn)化成了一個異常向量V,向量中的每一維對應了一種指標的異常程度,取值范圍是[0,1],如果該值接近為0,則代表該監(jiān)控指標沒有出現(xiàn)異常.

3.3 根因診斷算法

AutoMonitor 使用最近鄰算法作為根因診斷算法,雖然K近鄰算法比較簡單,但是在這個問題下有較好的性能.因為同一種問題發(fā)生的時候,異常指標的集合也是比較接近的.為了進一步提高性能,我們設計了基于全局信息異常指標權(quán)重調(diào)整的策略.

該策略的思路來源于文檔搜索,對于文檔搜索問題,簡單的布爾檢索的策略不能取得很好的效果,因為布爾檢索將文檔里的詞語看作一樣的.作為布爾檢索改進,基于tf-idf 文檔向量模型[15]有著更高的搜索準確度,因為每個詞的重要性不一樣,一些出現(xiàn)頻率較高的詞被忽略了.

普通的K近鄰算法對于每一維的指標不做特殊的處理,作為這個方法的改進,優(yōu)化后的K近鄰算法會重新計算每一種標簽的異常向量每一維的指標權(quán)重.

假設原來使用歐幾里得距離L=計算向量之間的差異,新方法對其中的每一項賦予了特定的權(quán)重,在這里,距離的計算變成了:

這里,α的計算是通過分析已知樣本所得的.我們希望以下兩類指標的權(quán)重盡可能大,因為它們在診斷的場景下具有比較重要的價值.

? 該指標在其他根因中出現(xiàn)的較少,但是在本類根因下出現(xiàn)的比較頻繁;

? 該指標在其他根因的異常中出現(xiàn)的比較頻繁,但是在本類根因下出現(xiàn)的較少.

以上兩點是基于數(shù)據(jù)庫運維人員對根因診斷的經(jīng)驗所得出來的,第1 點的思路是和文檔搜索tf-idf 的思路相似,找出根因中最顯著的指標;第2 點的思路類似于醫(yī)生對病例的診斷,比方說一個病人的驗血結(jié)果白細胞正常,我們就不應該認為該病人出現(xiàn)了炎癥.

為了使系統(tǒng)根因推斷算法可以辨別異常向量相近的不同根因,我們設計了如下的權(quán)重調(diào)整算法:首先,將每一種的異常根因?qū)囊幌盗挟惓O蛄烤酆铣梢粋€向量,代表這種異常根因的特征;然后使用歐幾里得距離計算向量兩兩之間的差異,得到距離矩陣矩陣Dist.如果兩個向量之間的距離較小,將它們之間差異較大的指標提取出來并且放大相應的權(quán)重;否則就認為它們之間的距離不會對診斷結(jié)果造成影響,進而縮小它們之間差異較大指標的權(quán)重.下面是算法的具體偽代碼描述.

算法2.每類異常指標權(quán)值計算策略.

輸入:每種異常根因?qū)奶卣飨蛄縑1,V2,…,Vn,特征向量的維度k;

輸出:每種異常根因?qū)臋?quán)重向量A1,A2,…,An.

值得注意的是:AutoMonitor 使用的是基于最近鄰的方法,因此當我們引入新的異常類型以后,我們只需要將這些新類型的異常向量添加進訓練集中,然后重新的計算指標權(quán)重.由于總的數(shù)據(jù)集不大,重新計算只需要很短的時間,模型的推斷速度也比較快.由此我們認為:在添加新的數(shù)據(jù)或者新類型的異常,AutoMonitor 仍然可以有效地工作.

4 實驗結(jié)果分析

在實驗部分,我們需要驗證以下3 個問題.

? AutoMonitor 是否會對數(shù)據(jù)庫實際運行造成較大的影響?

? AutoMonitor 的異常監(jiān)測模塊是否能快速部署并達到較高的監(jiān)測精度?

? AutoMonitor 的根因分析模塊相較于同類方法是否能有較高的診斷準確率?

4.1 環(huán)境配置

我們使用兩臺配置相同的阿里云服務器作為實驗的環(huán)境,服務器具體性能參數(shù)如下.

? 操作系統(tǒng):Ubuntu 16.04 64 位;

? CPU:單核Intel(R)Xeno(R)Platinum 8163 CPU@2.5GHz;

? 內(nèi)存:2G.

服務器安裝的PostgreSQL 是12.0 版本,使用了python2.7/python3.6 兩種解釋器.實驗使用TPC-C[16]作為實驗的Benchmark.表1 是在和華為高斯數(shù)據(jù)庫DBA 交流討論后,經(jīng)過歸納整理的幾種常見的數(shù)據(jù)庫故障的問題根因,其中的設計參考了文獻[8].這里的問題根因涉及到了數(shù)據(jù)庫性能異常的各個方面,既包括了數(shù)據(jù)庫外部進程對CPU、網(wǎng)絡等資源的搶占,也涵蓋了數(shù)據(jù)庫日常運維的一系列事件,還有一部分訪問數(shù)據(jù)庫的錯誤行為.

Table 1 PostgreSQL common anomaly root causes表1 PostgreSQL 數(shù)據(jù)庫常見的問題根因

實驗中使用OLTP-Bench[16]工具實現(xiàn)了TPC-C 基準,該工具可以生成不同請求頻率和不同持續(xù)時間的TPC-C 負載,還能生成導入不同規(guī)模的表數(shù)據(jù).由于真實環(huán)境下數(shù)據(jù)庫的運行數(shù)據(jù)難以獲得,以上這些異常案例數(shù)據(jù)我們通過手動模擬觸發(fā)異常的方法來產(chǎn)生,即兩臺服務器,一臺作為數(shù)據(jù)庫服務器,另一臺作為用戶.每一次實驗里,用戶先啟動OLTP-Bench 執(zhí)行數(shù)據(jù)庫負載,在實驗中途啟動服務器中的異常程序觸發(fā)數(shù)據(jù)庫性能異常,等到異常程序結(jié)束再讓數(shù)據(jù)庫正常運行一段時間,然后結(jié)束單次實驗.下面介紹實驗的具體細節(jié):對于CPU、I/O 瓶頸,實驗使用Linux 環(huán)境下開源工具stress-ng 來搶占CPU 以及I/O 的資源;對于數(shù)據(jù)表備份以及數(shù)據(jù)表還原,實驗直接使用PostgreSQL 中關(guān)于數(shù)據(jù)導入/導出的命令(pg_dump,psql);對于錯誤的物理設計、開銷巨大的查詢、負載超常和統(tǒng)計信息更新這4 類異常,實驗直接使用描述中的方法來產(chǎn)生;對于網(wǎng)絡故障,我們使用Linux系統(tǒng)內(nèi)置命令tc 來進行流量控制,手動讓網(wǎng)絡通信速度變慢;對于鎖競爭,我們使用OLTP-Bench 對TPC-C 數(shù)據(jù)表中的一小部分數(shù)據(jù)進行短時間大量的訪問;考慮到數(shù)據(jù)庫訪問請求的多樣性,對于每一組生成的數(shù)據(jù),我們設定了不一樣的訪問頻率(每秒事務請求的數(shù)目從30~150).

4.2 監(jiān)控工具性能開銷測試

本實驗旨在探究數(shù)據(jù)庫根因診斷系統(tǒng)監(jiān)控工具對OLTP 數(shù)據(jù)庫性能的影響.

我們選取了不同的請求頻率,并且考慮到單次實驗的不穩(wěn)定性,在每一種請求頻率下重復進行了20 次實驗.考慮到實驗中平均數(shù)的不穩(wěn)定性,本實驗使用分位數(shù)作為分析性能差異的評價指標,圖5 是該實驗的結(jié)果.

Fig.5 Database performance comparsion with/without monitor tool圖5 有無監(jiān)控工具下數(shù)據(jù)庫性能比較結(jié)果

通過觀察可以發(fā)現(xiàn):開啟了監(jiān)控工具性能的損失相對而言是非常小的,分位數(shù)的平均延遲增加一般不會超過5%.原因主要有以下兩點.

(1)當前監(jiān)控數(shù)據(jù)請求的頻率為1 秒1 次,這個用戶對數(shù)據(jù)庫的訪問頻率而言是比較短的.在實踐中,1 秒1 次的數(shù)據(jù)請求頻率也足以保證推斷的精確程度,如果根據(jù)實際需要減少訪問頻率,性能的損失可以進一步降低;

(2)我們收集的數(shù)據(jù)包含了數(shù)據(jù)庫和操作系統(tǒng),以上兩部分的數(shù)據(jù)均會被操作系統(tǒng)和數(shù)據(jù)庫相關(guān)的進程定期生成.換句話說,系統(tǒng)并沒有增加數(shù)據(jù)收集上的開銷,增加的開銷僅僅來源于訪問獲取數(shù)據(jù),CPU和I/O 增加的額外開銷都比較小.

綜上所述,我們可以確信:當前的數(shù)據(jù)庫監(jiān)控診斷框架是輕量的,具有較強的實用價值.

4.3 異常檢測模塊測試

本實驗旨在驗證數(shù)據(jù)庫根因診斷系統(tǒng)異常監(jiān)測模塊的有效性,總共選取了8 000 條長度為32 的正常時間序列作為模型的訓練數(shù)據(jù).關(guān)于神經(jīng)網(wǎng)絡的一些超參數(shù)見表2.

Table 2 RNN model hyper parameters表2 循環(huán)神經(jīng)網(wǎng)絡模型超參數(shù)

自編碼器模型于GPU 服務器訓練,圖6 是神經(jīng)網(wǎng)絡訓練結(jié)果.可以觀察到:該神經(jīng)網(wǎng)絡訓練的開銷是比較小的,網(wǎng)絡也較快地達到收斂的狀態(tài).在實際部署的時候,系統(tǒng)會實時調(diào)用最近的歷史數(shù)據(jù)來更新神經(jīng)網(wǎng)絡的模型參數(shù),較小的訓練開銷保證了模型的可用性.

Fig.6 Neural network training result圖6 神經(jīng)網(wǎng)絡訓練結(jié)果

實驗選取了基于VAE[17]和基于GAN[18]的時序數(shù)據(jù)異常監(jiān)測方法和AutoMonitor 方法進行了對比.在測試階段,我們選取了200 組異常序列數(shù)據(jù)和500 組正常序列數(shù)據(jù),圖7 和表3 是異常監(jiān)測模塊靈敏度的實驗結(jié)果.

Fig.7 Anomaly detection module experimental results圖7 異常監(jiān)測模塊實驗結(jié)果

Table 3 Anomaly detection performance comparison表3 各算法性能的對比結(jié)果

可以看到:我們的監(jiān)測模型同時達到較高的精度和召回率.對比結(jié)果表明,AutoMonitor 方法是最優(yōu)的.我們認為,原因有如下幾點.

(1)已有的基于生成模型的方法雖然可以在一些時序數(shù)據(jù)異常檢測的任務中取得比較好的效果,但是因為時序數(shù)據(jù)的模式各異,數(shù)據(jù)庫的監(jiān)控數(shù)據(jù)又和負載相關(guān),因此,生成模型很難去學習到隱變量參數(shù);

(2)復雜的深度生成模型往往有較多的參數(shù),如果未經(jīng)充分的調(diào)優(yōu)會難以學習,從而造成性能的下降;

(3)對于一個偏向于工程的任務,我們認為:在選擇模型算法的時候不應該只追求精度,同樣要考慮到模型的穩(wěn)定性和訓練速度.

4.4 根因分析模塊測試

本實驗旨在驗證AutoMonitor 中根因分析模塊的有效性.對于每一種異常設置,在不同的用戶請求頻率下,各生成25 組數(shù)據(jù)(總共為250 組數(shù)據(jù)).這250 組實驗數(shù)據(jù)被隨機劃分成了訓練集(80 組)和測試集(170 組),我們的方法將會和DBSherlock[8]、普通的K近鄰算法和決策樹算法進行對比.

圖8 是實驗總體的精度對比,可以看到:AutoMonitor 的表現(xiàn)比其他3 種算法要出色;權(quán)重調(diào)整的K近鄰算法要比普通K近鄰算法精度提升10 個百分點,比決策樹算法精度高近5 個百分點.可以看到:DBSherlock 在實驗數(shù)據(jù)集上的表現(xiàn)并不出色,只有不到60%的診斷精度.這說明在比較復雜的環(huán)境下(每組數(shù)據(jù)用戶的請求頻率不同),DBSherlock 并不能起到很好的效果.

Fig.8 Comparison on diagnosis precision of different diagnosis methods圖8 根因分析各方法精度對比

圖9 是關(guān)于3 種分類器對于每一種異常的識別能力比較,我們使用F-Score 作為評價標準.從實驗結(jié)果圖中可以看到:AutoMonitor 在各類異常的根因診斷上均有較為出色的表現(xiàn),并不存在對于某種異常根因診斷能力較弱的情況.而DBSherlock 方法對于某幾類異常的診斷精度較高,但是對于另外幾類異常的診斷精度確不盡如人意.主要的問題在于:DBSherlock 生成的斷言對于數(shù)據(jù)的敏感度較高,并且合并因果模型的策略也存在著較大的不確定性.表4 是對于每一種根因診斷的具體指標結(jié)果,包含了精確度(第1 行)和召回率(第2 行).

Fig.9 Comparisionon F-score of different diagnosis methods圖9 不同算法F-score 比較結(jié)果

Table 4 Precision/Recall comparison result表4 各算法精確度/召回率的對比結(jié)果

5 總結(jié)與未來工作

本文研究了OLTP 數(shù)據(jù)庫在實際運行時可能遇到的異常,分析了這些異常和一系列監(jiān)控指標之間的影響關(guān)系,以及對這些異常的監(jiān)測和根因推斷方法.

針對上面的問題,本文設計了一個部署在PostgreSQL 數(shù)據(jù)庫管理系統(tǒng)上的自動監(jiān)控診斷框架,該框架造成的額外開銷較小,能為經(jīng)驗較少的數(shù)據(jù)庫使用者提供自動異常監(jiān)測診斷的服務.在根因推斷上面,本文使用了一種權(quán)重調(diào)整的K近鄰算法.和普通的K近鄰算法相比,這種K近鄰算法可以更好地捕捉到不同根因之間的差異關(guān)系,并且可以提取關(guān)于某種根因相對重要的監(jiān)控指標.

本文的實驗部分探究了自動異常監(jiān)測模塊和根因推斷模塊的準確性,結(jié)果表明:上述的兩個模塊準確性都較高,經(jīng)過權(quán)重調(diào)整的K近鄰算法對于表現(xiàn)比較接近的問題根因具有更加好的辨別區(qū)分能力.總體來說,我們的系統(tǒng)具有實際的應用價值.

該系統(tǒng)目前的不足之處在于只適用于普通的單機PostgreSQL 數(shù)據(jù)庫,擴展性較差,并且診斷系統(tǒng)在離線的過程中需要比較多的訓練數(shù)據(jù).下一步計劃將框架移植到MySQL 等主流開源數(shù)據(jù)庫上,并且考慮將框架擴展到分布式數(shù)據(jù)庫、云數(shù)據(jù)庫上.此外,目前的異常數(shù)據(jù)主要是人工合成模擬的,我們計劃通過和數(shù)據(jù)庫主流廠商合作的形式,研究更加實際的場景.

猜你喜歡
根因監(jiān)控數(shù)據(jù)庫
根因分析法提高藥品不良反應報告合格率
The Great Barrier Reef shows coral comeback
你被監(jiān)控了嗎?
Zabbix在ATS系統(tǒng)集中監(jiān)控中的應用
基于矩陣編碼的自動路測根因定位方法
看監(jiān)控攝像機的4K之道
根因分析法在提高科室備用藥品質(zhì)量管理中的應用
數(shù)據(jù)庫
財經(jīng)(2017年2期)2017-03-10 14:35:35
數(shù)據(jù)庫
財經(jīng)(2016年15期)2016-06-03 07:38:02
數(shù)據(jù)庫
財經(jīng)(2016年3期)2016-03-07 07:44:46
红安县| 台南县| 台前县| 弥勒县| 平度市| 柘荣县| 临夏县| 宁明县| 鞍山市| 普安县| 台州市| 锦屏县| 中西区| 五莲县| 昆明市| 福贡县| 太谷县| 光山县| 洪江市| 乡城县| 长垣县| 黄石市| 建湖县| 宝应县| 丰台区| 石嘴山市| 乐亭县| 南溪县| 连云港市| 景泰县| 龙山县| 班玛县| 仙游县| 兰州市| 全椒县| 噶尔县| 左权县| 进贤县| 新野县| 临沭县| 城固县|