監控與診斷一直是數據庫運維中的兩個十分重要的環節，在傳統的運維模式中，監控與診斷都是以人為中心的，因此指標與數據的采集也都要圍繞人來展開。         

監控數據是需要人來看的，通過人的查看，可以發現監控數據中存在的異?；蛘咧档镁璧牡胤?。不同水平的DBA能從數據中看出不同級別的風險。因為是需要人看，所以展示的指標不能太多，否則監控人員就眼花繚亂了。實際上，上圖的關鍵指標的數量對于監控來說已經太多了。

對于依靠人的監控而言，簡要而直觀的指標展示是十分必要的。對于數據庫來說，只關注三五個關鍵指標才能更好的實現人工監控。我的一個金融客戶，對于核心系統，他們只關注活躍會化數指標，有一個監控人員隨時盯住這個指標看，一旦出現異常就點擊相關的指標，進行診斷分析。

這是根據他們的需求修改的指標歷史數據監控頁，一旦活躍會話數指標超標就點擊進去診斷。在這個頁面中我們提供了一個“問題分析”工具。

問題分析工具可以根據時間窗口分析系統中存在的問題（當前問題或者歷史問題），而等待事件分析工具則可以從等待事件的角度來幫助DBA分析系統中可能存在的性能問題。

不管怎么樣，監控的目的是讓DBA工作的更簡單，還是為人服務的，以人為中心的?？赡苡信笥褜Υ瞬徽J可，認為監控也可以自動化，比如基線告警。實際上基線告警也是類似的，比如基線告警可以通過短信告訴你活躍會話數異常了。但是如果基線告警模板設置了太多的指標，那么告警風暴的處理就很麻煩了。不精準的告警會讓告警功能如同虛設。

傳統的診斷也是以人為中心的，當系統出問題的時候才去系統中查找各種信息，進行分析。這種分析十分依賴于DBA的個人能力。當用戶發生大問題的時候，總是希望高水平的專家能盡快到現場來處置。

隨著企業數字化的發展，以人為中心的這種監控診斷模式的成本越來越高，專家也不太愿意在一線現場坐鎮。因此節約人力成本，節約專家的時間成為了數據庫運維中十分重要的需求。實際上隨著硬件的發展，數據采集，存儲與計算的成本已經十分低廉了。因此在現代的數據庫監控系統中，采集并保存更為完整的監控數據已經不是成本太高的事情。

如果日常采集的數據足夠豐富，那么自動化診斷和遠程診斷就會變成可能。診斷工作所需的數據已經在離線采集的數據庫中了，絕大多數診斷工具都不需要再從數據庫實例中臨時采集數據，那么當數據庫出現異常的時候，自動診斷工具可以毫無風險的在后臺進行自動分析。

這里說的毫無風險是指自動化診斷工作本身不會給數據庫實例帶來任何風險。如果在自動化診斷中還需要從數據庫臨時采集一些數據，那么如果這種采集本身帶有風險，那么在一個本身就存在故障的數據庫實例上，可能就是一種雪上加霜的舉動。我們曾經做過一個共享池碎片自動診斷分析的工具，需要對KGH的數據進行分析，這個工具曾經就搞宕過數據庫。因此在指標自動化采集與自動化診斷上，我們會盡可能規避此類風險的出現。

想要實現這一切，其后面最重要的力量是數據，數據時首先監控與診斷自動化的基礎。實際上在數據庫自動化運維中，指標集與數據采集本身就包含了豐富的運維知識。某種數據庫應該采集哪些指標，該如何更好，無風險的采集數據庫的指標，是十分有價值的運維知識。

今年，我們將會把D-SMART中Oracle，Mysql、Postgresql、達夢、金倉等數據庫的指標集開源出來，也希望大家能夠加入到我們這個行列里，共同豐富與完善這個開源指標集。