昨天聊了些數(shù)據(jù)庫可觀測性能力與數(shù)字化運維的問題。我們希望利用對數(shù)據(jù)庫的數(shù)字化建模實現(xiàn)高質(zhì)量的遠程服務(wù)。以往給用戶提供服務(wù)的時候，專家需要到用戶現(xiàn)場去采集數(shù)據(jù)，分析數(shù)據(jù)，這種模式工作效率太低了。而Oracle可以通過TFA采集相關(guān)的數(shù)據(jù)，讓用戶上傳到MOS上，通過與用戶的多次交互實現(xiàn)十分高效的遠程支持。

圖片

讓專家不動er而讓數(shù)據(jù)動起來肯定是效率最高的服務(wù)模式，而為了實現(xiàn)類似Oracle Support Service的遠程服務(wù)，必須將各種能夠反映出數(shù)據(jù)庫健康狀態(tài)的數(shù)據(jù)都采集起來，在Oracle數(shù)據(jù)庫中這些數(shù)據(jù)采集是通過TFA/AWR/OSW三個工具組合采集的，Oracle通過TFA的統(tǒng)一接口來打包。在國產(chǎn)數(shù)據(jù)庫中，我們必須把數(shù)據(jù)庫能夠提供的可觀測性能力充分的利用起來，將這些數(shù)據(jù)完整的采集起來，使之可以在線/離線使用，為線上數(shù)據(jù)庫服務(wù)提供支撐。

我們該如何利用數(shù)據(jù)庫的可觀測性能力來向遠程支持服務(wù)提供充足的數(shù)據(jù)呢？最近我們正好在做神通OSCAR的運維知識圖譜，通過這個案例我來分享一下具體實現(xiàn)的過程。

OSCAR雖然是基于PG早期版本魔改的（參考我前些天發(fā)的文章），不過其可觀測性能力與PG已經(jīng)完全不相干了，不過OSCAR在極力模仿Oracle，因此利用我們建設(shè)Oracle運維知識圖譜的經(jīng)驗，還是可以簡化這個過程的。

圖片

首先要完成對運維對象的梳理，將其管理類、配置類、技術(shù)類的相關(guān)數(shù)據(jù)都能夠被采集回來。OSCAR的主要指標(biāo)都幾種在v$sysstat等幾張系統(tǒng)視圖中，利用早期針對Oracle 9i的代碼很快就可以完成這些采集工作。

圖片

參考上圖，我們針對OSCAR采集到了600多個指標(biāo)。可能有朋友已經(jīng)發(fā)現(xiàn)了，OSCAR的指標(biāo)數(shù)據(jù)并沒有那么多，而且我們的指標(biāo)里有很多大家不太認(rèn)識的指標(biāo)。

圖片

這是因為簡單的指標(biāo)是不足以進行自動化分析的，需要對指標(biāo)進行相關(guān)加工。通過加工會生成一系列新的指標(biāo)，我們把這個過程稱為過程指標(biāo)化。因為運維自動化系統(tǒng)對于指標(biāo)的處理是十分豐富的，因此我們在整個過程中需要把大量的分析中間過程和中間結(jié)果都指標(biāo)化。

能指標(biāo)化的東西盡可能指標(biāo)化，甚至包括日志和SQL。OSCAR只提供慢SQL，不能提供Top SQL，不過我們依然需要對SQL進行指標(biāo)化處理。

圖片

傳統(tǒng)的數(shù)據(jù)庫監(jiān)控系統(tǒng)構(gòu)建完指標(biāo)體系后就基本上大功告成了，只需要構(gòu)建一些基線模板，再加一些輔助工具，就可以用于監(jiān)控了。不過基線模板僅僅能夠提供簡單的篩選功能，把存在問題的指標(biāo)篩選出來顯示在看板上供專家去參考。而數(shù)字化運維的核心是自動化分析與預(yù)警，因此大量的數(shù)據(jù)并不是給人看的，而是需要自動化處理的。當(dāng)不需要運維人員干預(yù)的時候，智能化運維系統(tǒng)是在默默地工作的。

圖片

如上圖，雖然系統(tǒng)中出現(xiàn)了數(shù)萬次基線告警（基于智能基線，不是簡單的閾值），但是我們從系統(tǒng)匯總信息中沒有看到需要人去干預(yù)的告警（上上圖的左側(cè)中間）。此時數(shù)據(jù)庫系統(tǒng)雖然負(fù)載很高，性能也較差，但是系統(tǒng)判斷目前還沒有出現(xiàn)必須由運維人員手工處置的告警。

圖片

我們不需要過多地關(guān)注指標(biāo)基線的異常，而更多的需要關(guān)注關(guān)鍵指標(biāo)的波動異常。一般來說，波動異常意味著數(shù)據(jù)庫中存在某些指標(biāo)的異常波動。我們需要將這些異常也都指標(biāo)化了。指標(biāo)化是簡化自動化分析的關(guān)鍵。

圖片

一旦將異常指標(biāo)化后，我們就可以通過傳統(tǒng)的正則表達式來做簡單的預(yù)警了。比如活躍會話數(shù)超過某個閾值可能系統(tǒng)會存在風(fēng)險，而更大的風(fēng)險來自于活躍會話數(shù)的異常波動。利用這種異常波動來預(yù)警，將會有更好的效果。不斷地豐富上面的故障模型是系統(tǒng)上線后需要持續(xù)不斷去做的事情。

智能化運維系統(tǒng)需要在用戶現(xiàn)場不斷的積累新的運維知識，通過新的案例泛化后構(gòu)建新的故障模型，通過故障模型的不斷積累來不斷提升系統(tǒng)的能力。D-SMART系統(tǒng)出廠交付給客戶只是一個起點而不是產(chǎn)品的終點。產(chǎn)品在用戶的環(huán)境中不斷發(fā)現(xiàn)系統(tǒng)沒有正常預(yù)警的案例，然后通過專家介入后對案例進行分析和泛化，構(gòu)建出新的故障模型，這是D-SMART最初設(shè)計的模式。不過從目前的實踐來看，客戶方面缺乏數(shù)據(jù)庫專家，因此在客戶側(cè)的個性化積累效果不佳。因此目前主要還是依靠我們團隊幫助客戶來積累知識。

圖片

當(dāng)遠程的用戶系統(tǒng)出現(xiàn)問題的時候，可以將監(jiān)控數(shù)據(jù)打包發(fā)送給二線三線的專家。利用離線數(shù)據(jù)，遠程專家可以協(xié)助分析故障。我們的工程師可以通過對數(shù)據(jù)的分析和故障現(xiàn)象的描述抽象出新的故障模型。

圖片

構(gòu)建完健康模型、故障模型后，接下來可以構(gòu)建日檢、巡檢、周報、容量審計、SQL審計、對象審計等方面的巡檢工具。也可以構(gòu)建監(jiān)控看板、關(guān)鍵Sql跟蹤等方面的應(yīng)用工具，以支撐關(guān)鍵業(yè)務(wù)的高質(zhì)量運行需求。

圖片

工具是面向場景的，我們通過運維工作的特點將所有工具的功能劃分為監(jiān)控中心、日檢中心、告警中心、性能優(yōu)化中心、報告中心、容量管理中心、安全中心、工程中心這幾個中心。具體要做某些事情的時候，去這些中心里找自己所需的工具就可以了。

通過近一個月的適配，目前我們針對OSCAR數(shù)據(jù)庫的功能已經(jīng)適配完成，下一步就需要在我們的 第一個客戶那里去運行一段時間，豐富一下故障模型，并進一步優(yōu)化健康模型了。想要讓D-SMART在OSCAR上具有與在Oracle上一樣的能力，還需要數(shù)年時間的磨合。Oracle 數(shù)據(jù)庫的智能化運維在D-SMART上已經(jīng)經(jīng)過了5年的打磨了，運維經(jīng)驗是專家30年的積累，而這一切在OSCAR上剛剛起步。如果某位同學(xué)正在使用OSCAR，有興趣參與我們的運維知識梳理，那么可以和我們聯(lián)系，我們可以提供一年免費試用。

下面我們來看看，完成OSCAR的數(shù)字化建模后，我們能夠獲得什么樣的運維能力。

實例狀態(tài)（健康、關(guān)鍵指標(biāo)、容量、告警）

配置信息（基本配置、參數(shù)、表空間、組件、拓?fù)潢P(guān)系）