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

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

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

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

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

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

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

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

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

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

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

對于數(shù)據(jù)庫系統(tǒng)來說，我們其可觀測性能力可以通過四個方面的數(shù)據(jù)來獲得。

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

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

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

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

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

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

利用這些可觀測性接口我們可以構(gòu)建起數(shù)據(jù)庫的健康模型，通過健康模型展示數(shù)據(jù)庫的健康狀態(tài)。

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

也可以通過可觀測性接口，對系統(tǒng)進行快速分析，發(fā)現(xiàn)系統(tǒng)中需要優(yōu)化的點，并推薦優(yōu)化工具給DBA。

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