談到可觀測性，我們可以用數(shù)據(jù)庫的可觀測性能力來做些什么呢？大家肯定可以立即想到可視化展現(xiàn)。確實是的，用漂亮的儀表盤把這些信息展現(xiàn)出來是絕大多數(shù)數(shù)據(jù)庫運維工具的選擇。不過我們正處于DBA無法跟蹤與分析所有系統(tǒng)風險的時代，普通DBA需要在更短的時間內(nèi)處理更多數(shù)據(jù)，完成更多工作,因此那些漂亮的儀表盤是展現(xiàn)給誰看的這個問題更像是一個靈魂的拷問。我們必須有能力更為快捷和有效的處理與分析這些數(shù)據(jù)，而不是把它們展現(xiàn)出來給專家來看，專家根本沒時間看這些花花綠綠的儀表盤。

數(shù)據(jù)庫可觀察性與傳統(tǒng)監(jiān)控的真正區(qū)別在于開放了DBA實時了解系統(tǒng)內(nèi)部情況的能力，或者你可以讓AIOPS工具為你做這件事。 我們認為儀表化的展現(xiàn)數(shù)據(jù)庫的可觀測性并不是我們追逐數(shù)據(jù)庫可觀測性能力的最終目標，而僅僅是一個方法，而且在信息系統(tǒng)規(guī)模日益龐大的今天，這不是一個很好的方法。比較理想的方法是，系統(tǒng)能夠自動處理這些數(shù)據(jù)，并且通過數(shù)據(jù)庫提供的可觀測性數(shù)據(jù)，自動發(fā)現(xiàn)數(shù)據(jù)庫可能存在的風險。

似乎理想很豐滿，現(xiàn)實能做到嗎？我們先來看看可觀測性分析常用的理解方式，谷歌的SRE文檔中對此有十分詳細的描述，因此我在這里就不做過多的闡述了。

可觀測性最初指的是一種管理策略。它的目的是將最相關、最重要和最核心的問題提供給運維人員，并將關鍵信息與常規(guī)信息分離，使運維人員易于識別。可觀察性是控制理論中的一個要素，針對IT系統(tǒng)而言，它認為 IT 系統(tǒng)的內(nèi)部狀態(tài)可以從它們的輸入和輸出之間的關系中推斷出來，因此，它也經(jīng)常被描述為自上而下的評估。可觀察性的挑戰(zhàn)不在于從觀察中得出內(nèi)部狀態(tài)，而在于收集正確的觀察。

對于數(shù)據(jù)庫系統(tǒng)來說，我們可以從多個角度對數(shù)據(jù)庫產(chǎn)生的數(shù)據(jù)進行觀察，不過對我們幫助最大的不外乎四個方面：延時、負載、錯誤、資源使用率。

延時包含各種各樣的延時，應用訪問的延時，慢SQL，鎖的平均等待時間，物理讀的平均延時，網(wǎng)絡PING延時等，在一個正常的系統(tǒng)中，這些延時應該在一個比較平穩(wěn)和相對固定的區(qū)間內(nèi)波動，這也是以前網(wǎng)管系統(tǒng)做基線預警得基礎。

只不過不同硬件配置，不同業(yè)務負載模式，不同負載規(guī)模的系統(tǒng)這些延時差異很大，制定合理的基線預警模板工作量較大，所以近些年這些利用基線預警模板已經(jīng)無法滿足當前運維的需求了。雖然我們無法通過基線來直接進行觀察，但是多個相關指標之間的延時波動還是有很強的參考性，配合以一些擬合與波動預測算法，從延時上我們還是能夠獲得很好的觀測效果。

負載是一部分故障的根因，比如它可能導致延時增加，錯誤增加，資源使用率增加。同時負載也可能是一些其他因素的果，比如應用出現(xiàn)BUG，比如說SPINLOCK異常導致負載的不合理升高，亦或是某個磁盤故障引發(fā)某條SQL執(zhí)行變慢，最終導致并發(fā)執(zhí)行的SQL數(shù)量增加，引起負載增高。從這方面來看，這四個可觀測的方面之間也存在十分復雜的關系。

錯誤是由于某些外在或者內(nèi)在因素引起的，外在的錯誤是應用系統(tǒng)，中間件，存儲等上下游要素之間存在的問題。內(nèi)在的錯誤是由BUG或者某些系統(tǒng)的內(nèi)在缺陷導致的。

實際上由于數(shù)據(jù)庫管理系統(tǒng)是十分復雜的軟件系統(tǒng)，因此某些缺陷是無法規(guī)避和無法以較低成本的方式解決的。這些錯誤大部分不會引發(fā)數(shù)據(jù)庫宕機，僅僅會影響一部分業(yè)務或者某個功能的正確實現(xiàn)。如果數(shù)據(jù)庫系統(tǒng)能夠把內(nèi)部錯誤的計數(shù)器作為一個指標輸出出來，對于我們進行正確的觀測也是十分有價值的。我們在針對某個國產(chǎn)數(shù)據(jù)庫進行分析的時候，發(fā)現(xiàn)隨著某些種類的并發(fā)負載增加，其runtime error也會增加，不過應用的整體功能并未異常，只是部分SQL的執(zhí)行延時變得不穩(wěn)定了。

數(shù)據(jù)庫中存在某些錯誤并不可怕，如果我們知道了這些錯誤的根因與處置方案后，這些錯誤就可以比較好的在日常運維中應對了。這兩天我們在做某國產(chǎn)分布式數(shù)據(jù)庫的接口。這個產(chǎn)品是一個超級大樂高，是由相當多的開源組件糅合而形成的，文檔寫的也相當不好。不過有一份文檔寫的確實很好，那就是《應急處置手冊》，里面羅列了五六十個常見應急處置場景，對每個場景的表現(xiàn)，驗證方式，處置方式都做了詳細的介紹。從文檔的內(nèi)容上看，這些內(nèi)容應該是從大量的實踐案例中總結出來的真實場景，對運維人員運維這套數(shù)據(jù)庫系統(tǒng)來說，十分有價值。這份文檔十分類似于我們的“故障模型”，我們利用這份文檔也可以十分快捷的構建“運維經(jīng)驗”。

資源使用率是我們能夠最方便觀測到的系統(tǒng)狀態(tài)，系統(tǒng)資源使用率的觀察主要用途有幾個方面，一方面是發(fā)現(xiàn)異常，一個數(shù)據(jù)庫系統(tǒng)的資源使用率變化會有一定的規(guī)律，發(fā)生背離的情況往往預示著系統(tǒng)可能存在某些異常。白天業(yè)務高峰時CPU使用率從平均50%突變?yōu)槠骄^90%，如果持續(xù)時間較長，那么一定是系統(tǒng)出現(xiàn)了什么異常，而如果今天突然變得低于20%了，是不是也是一種異常呢？

我想大概率是的。系統(tǒng)資源使用率觀察的第二個用途就是容量管理。我們需要為系統(tǒng)的擴容與建設發(fā)展制定策略，因此我們會關注使用率的變化，以及使用率與業(yè)務增量之間的額關系，從而推斷出硬件擴容的最佳時機。過早擴容意味著更高的成本，過晚擴容可能會導致SLA無法保證，因此選取最合適的擴容時機對于企業(yè)IT運營中獲得較好的成本效益十分關鍵。

除此之外，觀測可以采用直接觀測，也可以采用間接觀測。昨天一個客戶問我，我們的D-SMART能不能對SQL的執(zhí)行計劃變化做實時跟蹤，當某個SQL的執(zhí)行計劃走歪的時候能夠立即發(fā)現(xiàn)。我回答說，一些大型系統(tǒng)，每秒執(zhí)行的SQL數(shù)量是幾萬甚至幾十萬，要對每條SQL的執(zhí)行計劃進行實時追蹤，成本太大。我們可以采用一些變通的方法來發(fā)現(xiàn)執(zhí)行計劃走歪的問題，而不必要去TRACE每條SQL的執(zhí)行計劃。如果一條SQL存在多種執(zhí)行計劃，而且走了一種比較差的執(zhí)行計劃，那么系統(tǒng)的邏輯讀、物理讀、活躍會化數(shù)、并發(fā)執(zhí)行的SQL總數(shù)等都會發(fā)生變化，我們只要能夠發(fā)現(xiàn)這些異常就可以通過根因定位找到某條SQL的執(zhí)行計劃變壞了。