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

在這個工具上我們看到了太多的Oracle的工作細節，SpotLight可以說是我對Oracle數據庫內部結構學習的第一個老師，很多DBA都對著SpotLight猜測Oracle的UNDO/REDO/DB CACHE/SHARED POOL等的工作機理。在二十年前，SpotLight可以算是Oracle數據庫可觀測性的巔峰之作。

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

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

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

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

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

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

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

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

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

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

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