本周五我會在信通院組織的一個線上沙龍里分享數據庫可觀測性的話題，這兩天在準備PPT，今天我們就順便聊聊這個話題吧。

實際上可觀測性這個概念最初并不是數據庫領域發明的，APM廠家最早提出了可觀測性的概念。他們認為IT基礎設施可以通過監控來解決問題，但是云原生應用系統太復雜了，僅僅通過監控是搞不定的，因此需要通過可觀測性能力的建設來解決這方面的問題。

實際上可觀測性最初指的是一種IT運維管理策略，目的是將最相關、最重要和最核心的問題提供給運維人員，并將關鍵信息與常規信息分離，從而達到更好的運維效果。

可觀察性是控制理論中的一個要素，它認為 IT 系統的內部狀態可以從它們的輸入和輸出之間的關系中推斷出來。因此，它也經常被描述為自上而下的評估。可觀察性的挑戰不在于從觀察中得出內部狀態，而在于收集正確的觀察。如何進行觀察是可觀測性發揮作用的關鍵，而正確的觀察往往來自于對于內在原理的理解與存在于現實中的客觀規律。

云原生應用來是更為復雜和無序的，而對于數據庫來說，相對來說要簡單一些。因為數據庫系統是按照某種客觀規律組織起來的，其內在規律可以被數字化。因此也有一些運維專家認為數據庫不需要搞什么可觀測性，做監控就好了。其實討論到這里就已經出現了一個比較頭疼的問題了。可觀測性和監控到底是個什么關系呢？

一般來說，監控是對一個預知的場景進行數據采集，基線分析與預警，比較依賴于已知的知識，在已知的前提假設下發揮作用。這種方式比較容易發現一些已知的唯一性問題，但是無法進行根因溯源。比如監控很容易發現某個數據庫宕掉了，但是比較難以發現數據庫中存在的性能問題和一些局部的問題。因此基于監控的網管系統可以幫助運維人員發現系統出現的一些異常，但是不能幫我們精準定位。而告警風暴的出現又會淹沒運維工作，給運維工作帶來巨大的壓力。因此現在很多企業也都希望通過一些AI算法來收斂告警，讓監控告警更加精準。

而可觀測性則提供了綜合的，全面的數據，通過算法的支撐，可以用于復雜問題的分析。可觀測性既可以提供帶有前提假設性的問題分析，也可以用于未知的問題的分析，還可以通過算法收斂告警，將多類告警信息歸類于某個問題，也可以利用豐富的數據做多維度的對比分析，從而確定問題的根源，因此可觀測性可以用于十分復雜環境下的問題分析。

如果簡單的比較可觀測性與監控的含義，我們作為識貨的人，肯定是會選擇后者的。誰不希望自己的運維自動化系統有更強的能力呢。只不過建設可觀測性能力也面臨極大的挑戰。實際上，如果我們拋開“可觀測性”這個看上去十分高大上的詞匯，來看看我們日常運維中所遇到的問題。

第一個問題是關鍵數據缺失的問題，這是我們經常會遇到的問題，分析某個已經發生的故障的根因的時候，由于某些數據沒有采集，導致本次分析只能以推測作為終點，或者需要等故障再次發生時才能繼續分析。因此要構建強大的可觀測性能力，必須實現對關鍵數據采集的全覆蓋，全覆蓋這個事情好說不好做。

第二個問題是關鍵數據出現意外不可見情況，我們認為某個指標異常的時候，系統是異常的，但是系統異常的時候，這個關鍵數據往往是不可獲得的，或者說獲得這個數據是存在更大的風險的。這種情況在可觀測性方面最常遇到的事情，系統不出問題的時候，可觀測性分析都是正常的，但是系統一出問題，可觀測性分析工具也出問題了。遇到這種情況，往往是因為可觀測性分析工具的建設者經驗不足，或者考慮不周。通過更為細致的指標設計，是完全可以規避這個問題的。

第三個問題是多種數據格式與數據來源的復雜性，這導致在一些復雜的場景下，很難正確的采集并正確的解析相關的數據。需要通過專業的模型建立起數據質量的標準，以及數據解讀的標準。在D-SMART中，我們就是以運維知識圖譜的方式進行知識梳理，并以此來解析這些數據。

對于數據庫系統來說，我們其可觀測性能力可以通過四個方面的數據來獲得。

從日志告警、指標體系、全面跟蹤、用戶體驗這四個方面，我們可以構建數據庫系統的可觀測性體系。前兩個可能大家都比較熟悉，第三個跟蹤在數據庫里包含各種TRACE的能力，比如Oracle的oradebug，event事件跟蹤、各種DUMP等。而用戶體驗有時候無法在數據庫內部獲得，需要從數據庫之外的應用中去獲取。

看上去很簡單，不過在數據庫中要獲得這些能力也并不容易。現在的數據庫系統都提供大量的指標，不過指標難以標記和排序，并且難以用于故障排除；而對日志進行排序和匯總，從而得出有意義的結論或與某個故障現象的關系可能具有挑戰性；跟蹤會產生大量不必要的數據，甚至會引發一些數據庫的BUG，導致服務不可用；用戶體驗的獲得也可能不夠準確。這些問題都將導致可觀測性能力大打折扣。

基于上述原因，我們的國產數據庫在建設可觀測性能力方面還比較滯后，一般是先搞定了數據庫的基本功能，然后才考慮添加可觀測性的接口。不幸的是，可觀測性能力的基礎是和數據庫內核關系十分緊密的基礎數據采集，通過外掛方式或者通過一些鉤子向外輸出數據庫核心指標會引發一系列的性能與穩定性的問題。因此可觀測性能力的構建必須從數據庫核心做起才能夠更為準確與有效。

目前我們的國產數據庫也提供了一些可觀測性的能力，只不過與Oracle比起來還有些不足。如果我們能夠充分利用這些能力，還是可以獲得不錯的效果的。我們以openGauss為例，分析一下國產數據庫提供的可觀測性能力，以及我們利用這些能力能做些什么。

在openGauss數據庫中我們可以看到的可觀測性接口十分豐富。總結起來有以下幾個方面：

• 基礎運行狀態：PG_STAT_*/DBE_PERF等
• 等待事件：pg_stat_activity/pg_thread_wait_status/dbe_perf.wait_events
• TOP_SQL:發現TOP SQL，慢SQL，進行SQL優化分析
• ASP:GS_ASP/DBE_PERF.LOCAL_ACTIVE_SESSION：分析當前和歷史會話的情況，定位微觀問題，類似Oracle的ASH
• WDR：一定時間內系統運行情況，用于分析性能問題，宏觀方面的故障定位等，類似Oracle的AWR

利用這些可觀測性接口我們可以構建起數據庫的健康模型，通過健康模型展示數據庫的健康狀態。

從而幫助我們隨時了解數據庫的運行情況與問題所在。利用等待事件接口，我們利用知識圖譜與智能診斷算法，可以大體定位系統存在的主要問題。

也可以通過可觀測性接口，對系統進行快速分析，發現系統中需要優化的點，并推薦優化工具給DBA。

自動化巡檢，安全審計，SQL優化等也就更不在話下了。說數據庫只需要監控，不需要可觀測性的說法已經過時了，隨著業務系統復雜性的增加，數據庫的復雜度也越來越大，因此數據庫具有強大的可觀測性能力十分重要。當然你也可以選擇另外一條路，把復雜性交給應用，而讓數據庫變得十分簡單。那么你可以使用APM去解決更為復雜而無序的應用，而不用考慮數據庫的可觀測性了。