監控與診斷一直是資料庫運作中的兩個十分重要的環節，在傳統的維運模式中，監控與診斷都是以人為中心的，因此指標與資料的蒐集也都要圍繞著人來展開。
監控資料是需要人來看的，透過人的檢視，可以發現監控資料中所存在的異常或是值得警覺的地方。不同水準的DBA能從數據中看出不同程度的風險。因為是需要人看，所以展示的指標不能太多，否則監控人員就眼花撩亂了。實際上，上圖的關鍵指標的數量對於監控來說已經太多了。
對於依賴人的監控而言，簡單而直覺的指標展示是十分必要的。對於資料庫來說，只專注於三到五個關鍵指標才能更好的實現人工監控。我的一個金融客戶，對於核心系統，他們只專注於活躍會化數指標，有一個監控人員隨時盯住這個指標看，一旦出現異常就點擊相關的指標，進行診斷分析。
這是根據他們的需求修改的指標歷史資料監控頁，一旦活躍會話數指標超標就點擊進去診斷。在這個頁面中我們提供了一個「問題分析」工具。
問題分析工具可以根據時間視窗分析系統中存在的問題（當前問題或歷史問題），而等待事件分析工具則可以從等待事件的角度來幫助DBA分析系統中可能存在的效能問題。
不管怎麼樣，監控的目的是讓DBA工作的更簡單，還是為人服務的，以人為中心的。可能有朋友對此不認可，認為監控也可以自動化，例如基準警報。實際上基線警報也是類似的，例如基線警告可以透過簡訊告訴你活躍會話數異常了。但是如果基線警報模板設定了太多的指標，那麼警告風暴的處理就很麻煩了。不精準的告警會讓警報功能如同虛設。
傳統的診斷也是以人為中心的，當系統出問題的時候才去系統中查找各種信息，進行分析。這種分析十分依賴DBA的個人能力。當用戶發生大問題的時候，總是希望高水準的專家能盡快到現場來處置。
隨著企業數位化的發展，以人為中心的這種監控診斷模式的成本越來越高，專家也不太願意在一線現場坐鎮。因此節約人力成本，節省專家的時間成為了資料庫維運中十分重要的需求。實際上隨著硬體的發展，資料收集，儲存與運算的成本已經十分低廉了。因此在現代的資料庫監控系統中，收集並保存更為完整的監控資料已經不是成本太高的事情。
如果日常採集的資料夠豐富，那麼自動化診斷和遠端診斷就會變成可能。診斷工作所需的數據已經在離線採集的資料庫中了，絕大多數診斷工具都不需要再從資料庫實例中臨時採集數據，那麼當資料庫出現異常的時候，自動診斷工具可以毫無風險的在後台進行自動分析。
這裡說的毫無風險是指自動化診斷工作本身不會對資料庫實例帶來任何風險。如果在自動化診斷中還需要從資料庫臨時採集一些數據，那麼如果這種採集本身帶有風險，那麼在一個本身就存在故障的資料庫實例上，可能就是一種雪上加霜的舉動。我們曾經做過一個共享池碎片自動診斷分析的工具，需要對KGH的資料進行分析，這個工具曾經就搞宕過資料庫。因此在指標自動化採集與自動化診斷上，我們會盡可能避免此類風險的出現。
想要實現這一切，其後面最重要的力量是數據，數據時首先監控與診斷自動化的基礎。實際上在資料庫自動化運維中，指標集與資料收集本身就包含了豐富的維運知識。某種資料庫應該採集哪些指標，該如何更好，無風險的採集資料庫的指標，是十分有價值的運維知識。
今年，我們將把D-SMART中Oracle，Mysql、Postgresql、達夢、金倉等資料庫的指標集開源出來，也希望大家能夠加入到我們這個行列裡，共同豐富與完善這個開源指標集。
以上是從監控到診斷：數據的力量的詳細內容。更多資訊請關注PHP中文網其他相關文章！
