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

圖片

讓專家不動er而讓數(shù)據(jù)動起來肯定是效率最高的服務模式，而為了實現(xiàn)類似Oracle Support Service的遠程服務，必須將各種能夠反映出數(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ù)庫服務提供支撐。

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

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

圖片

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

圖片

參考上圖，我們針對OSCAR采集到了600多個指標?？赡苡信笥岩呀?jīng)發(fā)現(xiàn)了，OSCAR的指標數(shù)據(jù)并沒有那么多，而且我們的指標里有很多大家不太認識的指標。

圖片

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

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

圖片

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

圖片

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

圖片

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

圖片

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

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

圖片

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

圖片

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

圖片

工具是面向場景的，我們通過運維工作的特點將所有工具的功能劃分為監(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上剛剛起步。如果某位同學正在使用OSCAR，有興趣參與我們的運維知識梳理，那么可以和我們聯(lián)系，我們可以提供一年免費試用。

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

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

配置信息（基本配置、參數(shù)、表空間、組件、拓撲關系）