昨天我發(fā)了一篇數(shù)據(jù)庫可觀測性的文章，談了可觀測性與監(jiān)控的差別。在運維領(lǐng)域，監(jiān)控是一個強需求，無論如何，你的數(shù)據(jù)庫在跑一些有價值的業(yè)務(wù)應(yīng)用，你就必須去監(jiān)控數(shù)據(jù)庫。而可觀測性并不是時時需要的，如果巡檢做完以后，發(fā)現(xiàn)的問題也無法得到解決，那么巡檢就變成了一個樣子貨了。

可觀測性也是如此，平時的時候，一些小問題還不至于讓人興師動眾。不過當系統(tǒng)出現(xiàn)了一個比較大的問題，導(dǎo)致了一些嚴重后果的時候，IT部門才發(fā)現(xiàn)，我們需要對日常發(fā)現(xiàn)的一些小問題做閉環(huán)管理，要防患于未然。實際上防患于未然這句話好說，卻極難落地，因為這背后是巨大的成本。只有做到系統(tǒng)優(yōu)化常態(tài)化的企業(yè)才能真正做到閉環(huán)管理和防患于未然，對于大多數(shù)運維經(jīng)費有限的企業(yè)來說只能嘴上向領(lǐng)導(dǎo)表表態(tài)而無法真正去實施了。

D-SMART是一個基于數(shù)據(jù)庫可觀測性能力構(gòu)建的深度運維工具，在研發(fā)之初，我們就希望充分利用數(shù)據(jù)庫的可觀測性能力，盡可能地將數(shù)據(jù)庫系統(tǒng)數(shù)字化。因此每種數(shù)據(jù)庫我們都采集了數(shù)百個指標與配置項。當我?guī)啄昵昂鸵粋€客戶談到我們的系統(tǒng)采集了數(shù)百個數(shù)據(jù)庫的指標與配置項的時候，他直搖頭，我們不需要那么多指標，有幾個指標夠我們監(jiān)控就行了。太多了，我們也看不過來。實際上，D-SMART采集那么多數(shù)據(jù)并不是讓你看的，運維監(jiān)控人員確實只能聚焦在少量的幾個指標上。D-SMART的指標大多數(shù)是用于分析的，并不是用于監(jiān)控，如果要監(jiān)控，只需要看“健康模型”或者監(jiān)控主界面上的那幾個關(guān)鍵指標就行了。

D-SMART利用數(shù)據(jù)庫運維專家多年來積累的經(jīng)驗采集了數(shù)百個指標，這些指標來自于數(shù)據(jù)庫的系統(tǒng)狀態(tài)、METRIC、等待事件、日志、TOPSQL、跟蹤數(shù)據(jù)等。為了減少D-SMART采集對于數(shù)據(jù)庫的影響，這些采集都采用開銷最小的方法，從系統(tǒng)視圖中一次性獲取，然后在D-SMART上加工的方式。

數(shù)據(jù)采集中已經(jīng)包含了大量的專家經(jīng)驗，比如Oracle數(shù)據(jù)庫的表空間使用率，實際上采集這個數(shù)據(jù)需要對數(shù)據(jù)庫進行全庫掃描，如果系統(tǒng)比較大，IO性能較差，系統(tǒng)比較繁忙的情況下，這個采集對數(shù)據(jù)庫影響還是挺大的。我們以前也遇到過一個客戶的數(shù)據(jù)庫超融合一體機的一個故障，就是因為他們的一體機管理軟件的表空間使用率采集是分鐘級的，而一次采集需要30分鐘才能完成，大量采集任務(wù)積壓導(dǎo)致了一體機IO鏈路故障，導(dǎo)致了宕機。在D-SMART中，表空間使用率采集是4小時一次或者1天一次的，當上一次沒有完成之前，新的采集不會發(fā)起，從而避免在一些極端的情況下因為運維監(jiān)控導(dǎo)致數(shù)據(jù)庫出問題。而在系統(tǒng)的指標體系中，使用了一些“風險”類和“可用天數(shù)”的指標來真正地反映出系統(tǒng)存在的風險，這些指標都是通過分析和計算后獲得的。

從另外一個例子上可以看到D-SMART在監(jiān)控指標設(shè)計上的專家經(jīng)驗特征。

很多監(jiān)控軟件在采集共享池信息時，喜歡把一些X$視圖的數(shù)據(jù)采集回來做展示。實際上X$視圖都是Oracle數(shù)據(jù)庫的內(nèi)存結(jié)構(gòu)，采集時需要對這些數(shù)據(jù)加閂鎖。如果數(shù)據(jù)庫系統(tǒng)的共享池存在問題的時候，這種采集很可能成為駱駝身上添加的最后一根稻草。前陣子我們的一個商用版用戶反饋說他們的共享池性能有點問題，就是用我們的一個共享池分析工具去分析共享池碎片情況，沒想到觸發(fā)了一個BUG，報了ORA-600錯誤。確實是的，當共享池有問題的時候，如果去訪問那些X$視圖去查看共享池的情況，是很容易觸發(fā)一些BUG的，嚴重時候會出現(xiàn)實例宕機的情況。

為了既能夠發(fā)現(xiàn)共享池存在的問題，又避免平時不過多干擾共享池，我們使用了上面的一些指標來綜合評估共享池可能存在的風險。大家可以看出，這些指標都不需要去對共享池加閂鎖。這種設(shè)計后面體現(xiàn)的是一幫老司機的經(jīng)驗。

有了強大的指標體系，才能更加充分地利用數(shù)據(jù)庫的可觀測性能力。基于如此豐富的指標數(shù)據(jù)，我們就可以實現(xiàn)各種深度的運維能力了。

比如我們給系統(tǒng)監(jiān)控者提供的工具包括“健康模型”、“等待事件實時分析工具”，“等待事件歷史分析工具”，“問題分析工具”（用于分析一段時間內(nèi)系統(tǒng)可能存在的各種問題）、“運維經(jīng)驗告警”，“TOP SQL分析工具”、“SQL審計工具”，“關(guān)鍵SQL跟蹤分析工具”，“容量分析工具”，“集群拓撲查看工具”、“日檢、月檢、特檢、審計工具”等一系列的運維工具。運維人員不需要盯著指標看，甚至不需要盯著D-SMART看，把短信告警或者微信告警、郵件告警接好，收到告警信息再去看看系統(tǒng)就可以了。

充分利用數(shù)據(jù)庫的可觀測性可以干很多事情，專家直接看數(shù)據(jù)也行，利用數(shù)據(jù)庫提供的工具（WDR/AWR/ASH等報告）也行，采集回來放著，一旦發(fā)生問題去回溯分析也可以。實際上D-SMART發(fā)布社區(qū)版的想法來自于一個合作伙伴的需求。當時我們的一個合作伙伴提出有幾十個客戶，沒多少錢，希望出問題后我們能派專家去現(xiàn)場分析。我們算了一下，如果專家去現(xiàn)場，每年多出幾次問題就虧了。于是提出能不能遠程分析，不過那些客戶里大多數(shù)是不允許VPN連上去分析的。于是我們提出來使用d-smart輔助。測試了一兩個客戶，發(fā)現(xiàn)效果還不錯，用戶出問題的時候，D-SMART生成幾份報告，遠程分析一下，就基本上解決問題了。不過讓這些用戶都買一套D-SMART，用戶也買不起，那怎么辦，經(jīng)過幾次討論，我們想出了一個發(fā)布D-SMART社區(qū)版的方法。利用社區(qū)版日常采集的數(shù)據(jù)，到需要提供服務(wù)時就可以生成遠程分析所需要的報告了。