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

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

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

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

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

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

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

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

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

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

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

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

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

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