?可觀測性對數(shù)據(jù)庫運(yùn)維來說很重要。我們應(yīng)該向客戶提供什么樣的數(shù)據(jù)庫可觀測性能力呢？記得二十年前第一次看到spotlight for Oracle的時候，驚為天人，在遇到這個工具之前，我用過的最好的Oracle工具是TOAD。

在這個工具上我們看到了太多的Oracle的工作細(xì)節(jié)，SpotLight可以說是我對Oracle數(shù)據(jù)庫內(nèi)部結(jié)構(gòu)學(xué)習(xí)的第一個老師，很多DBA都對著SpotLight猜測Oracle的UNDO/REDO/DB CACHE/SHARED POOL等的工作機(jī)理。在二十年前，SpotLight可以算是Oracle數(shù)據(jù)庫可觀測性的巔峰之作。

隨著對數(shù)據(jù)庫內(nèi)部原理的理解以及對系統(tǒng)優(yōu)化的更為深刻的認(rèn)知，我已經(jīng)有十多年沒有再用過SpotLight了，因為SpotLight的可視化界面離我對Oracle可觀測性的要求相去甚遠(yuǎn)。數(shù)據(jù)庫可觀測性能力不再意味著把數(shù)據(jù)庫內(nèi)部的各個組件用一個十分容易看懂的方式圖形化展示，而是需要了解數(shù)據(jù)庫內(nèi)部運(yùn)作中存在什么特性，存在哪些風(fēng)險，需要采取哪些前置性優(yōu)化措施。

數(shù)據(jù)庫可觀測性能力的需求在不同類型的用戶中也差異甚大。數(shù)據(jù)庫可視性或者說可觀測性并不是指那些花里胡哨的圖形圖表，而是指運(yùn)維人員可以使用工具、腳本、接口獲得的數(shù)據(jù)庫的各種指標(biāo)、日志、狀態(tài)、統(tǒng)計值，并依靠這些基礎(chǔ)數(shù)據(jù)進(jìn)行自動化分析的能力。

昨天我們團(tuán)隊和一個用戶做了一次交流，他和他的幾個人的一個小組使用D-SMART的核心能力為600多套數(shù)據(jù)庫做日常運(yùn)維監(jiān)控。我們問他最常用的功能是什么？是不是每天都看看日檢報告，是否關(guān)注這些數(shù)據(jù)庫的健康、性能、負(fù)載方面的模型。他的回答很簡單：

這個回答有點出乎我們的意外，不過卻讓我感到很受鼓舞。對于這樣的運(yùn)維場景，運(yùn)維人員已經(jīng)沒有時間整天去監(jiān)控了，遇到運(yùn)維經(jīng)驗報警使用自動診斷工具，TOPSQL工具去分析問題，定位問題。并通過十分詳盡的采集指標(biāo)去做一些判斷和確定，驗證自動分析的結(jié)果。這確實是我們在設(shè)計D-SMART的時候，希望此類用戶最佳的使用方式。數(shù)據(jù)庫的可觀測性能力已經(jīng)集成到了工具中了，不需要再通過視覺監(jiān)控去浪費(fèi)人力資源。

D-SMART會在本地構(gòu)建起一個數(shù)據(jù)庫的全面的資料庫，而智能化分析工具會幫你做自動的分析。運(yùn)維人員要做的事情就是相信這個工具，在這個工具發(fā)出告警的時候才去使用這個工具。同時記錄下這個工具出現(xiàn)分析錯誤的情況，反饋給技術(shù)團(tuán)隊，讓我們進(jìn)一步優(yōu)化算法。而日檢功能他們只是在數(shù)據(jù)庫剛剛接入監(jiān)控的時候使用，從日檢中，他們可以發(fā)現(xiàn)一些數(shù)據(jù)庫安裝部署時，或者系統(tǒng)剛剛上線時遇到的問題。經(jīng)過一段時間后，日檢中的一些普通問題他們已經(jīng)不太關(guān)注了，一些重大隱患發(fā)生時，會通過運(yùn)維經(jīng)驗告警通知他們，這一點對他們來說就足夠了。

這種接近極限的極簡模式的運(yùn)維操作似乎不需要太復(fù)雜的界面，不過運(yùn)維的場景是多樣化的。前陣子我們遇到一個金融用戶，我們的同事教他看運(yùn)維經(jīng)驗告警，他說他的主要工作是監(jiān)控銀行核心系統(tǒng)的狀態(tài)，一旦有風(fēng)險立即分析處置，因此他不能等著運(yùn)維經(jīng)驗告警才去做分析，因為他日常的工作就是隨時準(zhǔn)備應(yīng)對核心系統(tǒng)的問題，一旦某些核心指標(biāo)出現(xiàn)異常就馬上要進(jìn)行分析。

因此他們需要通過一個看板來進(jìn)行運(yùn)維。因為關(guān)注的系統(tǒng)有多個，關(guān)注的指標(biāo)也很多，因此也不適合用SpotLight這種模式，需要一種十分直觀的，能看到更多細(xì)節(jié)的看板來滿足他的需求，因此一個表格狀的看板是最合適的模式。這個看板上有他們所關(guān)心的所有指標(biāo)，并且某個指標(biāo)出現(xiàn)異常的時候，能夠自動變紅，同時點擊這個指標(biāo)，可以進(jìn)入相應(yīng)的分析模塊。

從數(shù)據(jù)庫運(yùn)維工作的實踐來看，我們不僅僅需要數(shù)據(jù)庫系統(tǒng)能夠提供很多可觀測的數(shù)據(jù)，還需要有合適的工具來輔助這些數(shù)據(jù)的分析與解讀。數(shù)據(jù)庫內(nèi)在的復(fù)雜的特性可以被一系列便捷使用的工具所封裝，同時我們還需要能夠十分方便的訪問最原始的數(shù)據(jù)，以便于專家分析使用。因此從運(yùn)維的角度來看數(shù)據(jù)庫可觀測性，實際上除了數(shù)據(jù)庫產(chǎn)品提供的可觀測能力之外，還需要我們擁有可以充分發(fā)揮數(shù)據(jù)庫可觀測能力的工具。

從這兩個典型的需求，我們可以看到，在運(yùn)維工作中，DBA所需要的數(shù)據(jù)庫可觀測性能力實際上實際上是很復(fù)雜的，在不同的場景中，我們可能需要不同的能力。雖然如此，我們也可以對這些場景構(gòu)建一個超集，從而滿足各種需求。實際上，Oracle的OEM是一個這方面的不錯的樣板?？赡芎苌儆蠴RACLE DBA常年使用OEM來監(jiān)控系統(tǒng)（實際上OEM除了能夠用于Oracle的運(yùn)維外，還支持大量的第三方數(shù)據(jù)庫，中間件等產(chǎn)品）。OEM將所有的運(yùn)維對象的可觀測性數(shù)據(jù)都離線采集到自己的資料庫里，然后利用這些數(shù)據(jù)來進(jìn)行展示和分析。

可能有些朋友會覺得采集運(yùn)維對象的數(shù)據(jù)并不復(fù)雜，直接使用標(biāo)準(zhǔn)的SNMP MIB庫不就行了嗎？如果你沒有深入的去研究數(shù)據(jù)庫、中間件等運(yùn)維對象，可能會覺得SNMP MIB庫是很強(qiáng)大的，不過如果你真的認(rèn)真去研究MIB庫，你會發(fā)現(xiàn)大多數(shù)MIB庫能夠提供的能力都是基于網(wǎng)管時代的運(yùn)維監(jiān)控思想的，用于監(jiān)控都十分勉強(qiáng)，要用于分析診斷，那是萬萬不能的了。受到MIB庫影響的一些開源監(jiān)控平臺也存在類似的問題，如果你不去做深度的定制，直接使用的話，在運(yùn)維可觀測性能力建設(shè)方面依然是不夠的。

全面的可觀測性能力建設(shè)是需要投入的，因此在建設(shè)這方面能力的時候，需要根據(jù)自己的實際需要進(jìn)行，逐步積累能力，而不要總想著一蹴而就?？捎^測性能力建設(shè)沒有那么高不可及，那么高大上，只要你能夠通過這個能力來完成你的運(yùn)維目標(biāo)就可以了。哪怕是當(dāng)年的一條統(tǒng)計當(dāng)前數(shù)據(jù)庫等待事件排序的SQL，不也是很好的可觀測性能力嗎？只要這類的能力積累多了，你的運(yùn)維能力不就越強(qiáng)了嗎？如果從簡單了說，運(yùn)維角度的數(shù)據(jù)庫可觀測性就那么簡單。?