從監控到診斷:資料的力量

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

監控資料是需要人來看的，透過人的檢視，可以發現監控資料中存在的異常或者值得警惕的地方。不同水平的DBA能從資料中看出不同級別的風險。因為是需要人看，所以展示的指標不能太多，否則監控人員就眼花繚亂了。實際上，上圖的關鍵指標的數量對於監控來說已經太多了。

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

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

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

不管怎麼樣，監控的目的是讓DBA工作的更簡單，還是為人服務的，以人為中心的。可能有朋友對此不認可，認為監控也可以自動化，比如基線告警。實際上基線告警也是類似的，比如基線告警可以透過簡訊告訴你活躍會話數異常了。但是如果基線告警模板設定了太多的指標，那麼告警風暴的處理就很麻煩了。不精準的告警會讓告警功能如同虛設。

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

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

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

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

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

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