如何利用資料庫的可觀測效能力

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

資料庫可觀察性與傳統監控的真正區別在於開放了DBA實時瞭解系統內部情況的能力，或者你可以讓AIOPS工具為你做這件事。 我們認為儀表化的展現資料庫的可觀測性並不是我們追逐資料庫可觀測效能力的最終目標，而僅僅是一個方法，而且在資訊系統規模日益龐大的今天，這不是一個很好的方法。比較理想的方法是，系統能夠自動處理這些資料，並且透過資料庫提供的可觀測性資料，自動發現資料庫可能存在的風險。

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

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

對於資料庫系統來說，我們可以從多個角度對資料庫產生的資料進行觀察，不過對我們幫助最大的不外乎四個方面：延時、負載、錯誤、資源使用率。

延時包含各種各樣的延時，應用訪問的延時，慢SQL，鎖的平均等待時間，物理讀的平均延時，網路PING延時等，在一個正常的系統中，這些延時應該在一個比較平穩和相對固定的區間內波動，這也是以前網管系統做基線預警得基礎。只不過不同硬體配置，不同業務負載模式，不同負載規模的系統這些延時差異很大，制定合理的基線預警模板工作量較大，所以近些年這些利用基線預警模板已經無法滿足當前運維的需求了。雖然我們無法透過基線來直接進行觀察，但是多個相關指標之間的延時波動還是有很強的參考性，配合以一些擬合與波動預測演算法，從延時上我們還是能夠獲得很好的觀測效果。

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

錯誤是由於某些外在或者內在因素引起的，外在的錯誤是應用系統，中介軟體，儲存等上下游要素之間存在的問題。內在的錯誤是由BUG或者某些系統的內在缺陷導致的。實際上由於資料庫管理系統是十分複雜的軟體系統，因此某些缺陷是無法規避和無法以較低成本的方式解決的。這些錯誤大部分不會引發資料庫當機，僅僅會影響一部分業務或者某個功能的正確實現。如果資料庫系統能夠把內部錯誤的計數器作為一個指標輸出出來，對於我們進行正確的觀測也是十分有價值的。我們在針對某個國產資料庫進行分析的時候，發現隨著某些種類的併發負載增加，其runtime error也會增加，不過應用的整體功能並未異常，只是部分SQL的執行延時變得不穩定了。

資料庫中存在某些錯誤並不可怕，如果我們知道了這些錯誤的根因與處置方案後，這些錯誤就可以比較好的在日常運維中應對了。這兩天我們在做某國產分散式資料庫的介面。這個產品是一個超級大樂高，是由相當多的開源元件糅合而形成的，文件寫的也相當不好。不過有一份文件寫的確實很好，那就是《應急處置手冊》，裡面羅列了五六十個常見應急處置場景，對每個場景的表現，驗證方式，處置方式都做了詳細的介紹。從文件的內容上看，這些內容應該是從大量的實踐案例中總結出來的真實場景，對運維人員運維這套資料庫系統來說，十分有價值。這份文件十分類似於我們的“故障模型”，我們利用這份文件也可以十分快捷的構建“運維經驗”。

資源使用率是我們能夠最方便觀測到的系統狀態，系統資源使用率的觀察主要用途有幾個方面，一方面是發現異常，一個資料庫系統的資源使用率變化會有一定的規律，發生背離的情況往往預示著系統可能存在某些異常。白天業務高峰時CPU使用率從平均50%突變為平均超過90%，如果持續時間較長，那麼一定是系統出現了什麼異常，而如果今天突然變得低於20%了，是不是也是一種異常呢?我想大機率是的。系統資源使用率觀察的第二個用途就是容量管理。我們需要為系統的擴容與建設發展制定策略，因此我們會關注使用率的變化，以及使用率與業務增量之間的額關係，從而推斷出硬體擴容的最佳時機。過早擴容意味著更高的成本，過晚擴容可能會導致SLA無法保證，因此選取最合適的擴容時機對於企業IT運營中獲得較好的成本效益十分關鍵。

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

從上面的這個案例中，我們可以看出，有時候我們無法採用直接觀測的方法得到我們所需要的結果的時候，我們也可以採用間接觀測的方法。只不過我們需要在觀測中發現問題時，能夠透過某些診斷路徑定位到這個故障根因就行了。前幾天我說過的利用和共享池相關的等待事件數量的變化以及共享池使用率，SGA RESIZE等側面觀測，就不需要去鎖定共享池閂鎖，掃描共享池的HEAP來獲得共享池執行狀態的風險狀態，是一樣的道理。