建站
咨詢
售后
建站咨詢
新聞中心
談到可觀測性，我們可以用數(shù)據(jù)庫的可觀測性能力來做些什么呢？大家肯定可以立即想到可視化展現(xiàn)。確實(shí)是的，用漂亮的儀表盤把這些信息展現(xiàn)出來是絕大多數(shù)數(shù)據(jù)庫運(yùn)維工具的選擇。不過我們正處于DBA無法跟蹤與分析所有系統(tǒng)風(fēng)險(xiǎn)的時(shí)代，普通DBA需要在更短的時(shí)間內(nèi)處理更多數(shù)據(jù)，完成更多工作,因此那些漂亮的儀表盤是展現(xiàn)給誰看的這個(gè)問題更像是一個(gè)靈魂的拷問。我們必須有能力更為快捷和有效的處理與分析這些數(shù)據(jù)，而不是把它們展現(xiàn)出來給專家來看，專家根本沒時(shí)間看這些花花綠綠的儀表盤。
成都創(chuàng)新互聯(lián)是一家專業(yè)的成都網(wǎng)站建設(shè)公司，我們專注成都網(wǎng)站設(shè)計(jì)、成都網(wǎng)站建設(shè)、外貿(mào)網(wǎng)站建設(shè)、網(wǎng)絡(luò)營銷、企業(yè)網(wǎng)站建設(shè)，賣友情鏈接，廣告投放平臺(tái)為企業(yè)客戶提供一站式建站解決方案，能帶給客戶新的互聯(lián)網(wǎng)理念。從網(wǎng)站結(jié)構(gòu)的規(guī)劃UI設(shè)計(jì)到用戶體驗(yàn)提高，創(chuàng)新互聯(lián)力求做到盡善盡美。
數(shù)據(jù)庫可觀察性與傳統(tǒng)監(jiān)控的真正區(qū)別在于開放了DBA實(shí)時(shí)了解系統(tǒng)內(nèi)部情況的能力，或者你可以讓AIOPS工具為你做這件事。 我們認(rèn)為儀表化的展現(xiàn)數(shù)據(jù)庫的可觀測性并不是我們追逐數(shù)據(jù)庫可觀測性能力的最終目標(biāo)，而僅僅是一個(gè)方法，而且在信息系統(tǒng)規(guī)模日益龐大的今天，這不是一個(gè)很好的方法。比較理想的方法是，系統(tǒng)能夠自動(dòng)處理這些數(shù)據(jù)，并且通過數(shù)據(jù)庫提供的可觀測性數(shù)據(jù)，自動(dòng)發(fā)現(xiàn)數(shù)據(jù)庫可能存在的風(fēng)險(xiǎn)。
似乎理想很豐滿，現(xiàn)實(shí)能做到嗎？我們先來看看可觀測性分析常用的理解方式，谷歌的SRE文檔中對(duì)此有十分詳細(xì)的描述，因此我在這里就不做過多的闡述了。
可觀測性最初指的是一種管理策略。它的目的是將最相關(guān)、最重要和最核心的問題提供給運(yùn)維人員，并將關(guān)鍵信息與常規(guī)信息分離，使運(yùn)維人員易于識(shí)別?？捎^察性是控制理論中的一個(gè)要素，針對(duì)IT系統(tǒng)而言，它認(rèn)為 IT 系統(tǒng)的內(nèi)部狀態(tài)可以從它們的輸入和輸出之間的關(guān)系中推斷出來，因此，它也經(jīng)常被描述為自上而下的評(píng)估?？捎^察性的挑戰(zhàn)不在于從觀察中得出內(nèi)部狀態(tài)，而在于收集正確的觀察。
對(duì)于數(shù)據(jù)庫系統(tǒng)來說，我們可以從多個(gè)角度對(duì)數(shù)據(jù)庫產(chǎn)生的數(shù)據(jù)進(jìn)行觀察，不過對(duì)我們幫助最大的不外乎四個(gè)方面：延時(shí)、負(fù)載、錯(cuò)誤、資源使用率。
延時(shí)包含各種各樣的延時(shí)，應(yīng)用訪問的延時(shí)，慢SQL，鎖的平均等待時(shí)間，物理讀的平均延時(shí)，網(wǎng)絡(luò)PING延時(shí)等，在一個(gè)正常的系統(tǒng)中，這些延時(shí)應(yīng)該在一個(gè)比較平穩(wěn)和相對(duì)固定的區(qū)間內(nèi)波動(dòng)，這也是以前網(wǎng)管系統(tǒng)做基線預(yù)警得基礎(chǔ)。
只不過不同硬件配置，不同業(yè)務(wù)負(fù)載模式，不同負(fù)載規(guī)模的系統(tǒng)這些延時(shí)差異很大，制定合理的基線預(yù)警模板工作量較大，所以近些年這些利用基線預(yù)警模板已經(jīng)無法滿足當(dāng)前運(yùn)維的需求了。雖然我們無法通過基線來直接進(jìn)行觀察，但是多個(gè)相關(guān)指標(biāo)之間的延時(shí)波動(dòng)還是有很強(qiáng)的參考性，配合以一些擬合與波動(dòng)預(yù)測算法，從延時(shí)上我們還是能夠獲得很好的觀測效果。
負(fù)載是一部分故障的根因，比如它可能導(dǎo)致延時(shí)增加，錯(cuò)誤增加，資源使用率增加。同時(shí)負(fù)載也可能是一些其他因素的果，比如應(yīng)用出現(xiàn)BUG，比如說SPINLOCK異常導(dǎo)致負(fù)載的不合理升高，亦或是某個(gè)磁盤故障引發(fā)某條SQL執(zhí)行變慢，最終導(dǎo)致并發(fā)執(zhí)行的SQL數(shù)量增加，引起負(fù)載增高。從這方面來看，這四個(gè)可觀測的方面之間也存在十分復(fù)雜的關(guān)系。
錯(cuò)誤是由于某些外在或者內(nèi)在因素引起的，外在的錯(cuò)誤是應(yīng)用系統(tǒng)，中間件，存儲(chǔ)等上下游要素之間存在的問題。內(nèi)在的錯(cuò)誤是由BUG或者某些系統(tǒng)的內(nèi)在缺陷導(dǎo)致的。
實(shí)際上由于數(shù)據(jù)庫管理系統(tǒng)是十分復(fù)雜的軟件系統(tǒng)，因此某些缺陷是無法規(guī)避和無法以較低成本的方式解決的。這些錯(cuò)誤大部分不會(huì)引發(fā)數(shù)據(jù)庫宕機(jī)，僅僅會(huì)影響一部分業(yè)務(wù)或者某個(gè)功能的正確實(shí)現(xiàn)。如果數(shù)據(jù)庫系統(tǒng)能夠把內(nèi)部錯(cuò)誤的計(jì)數(shù)器作為一個(gè)指標(biāo)輸出出來，對(duì)于我們進(jìn)行正確的觀測也是十分有價(jià)值的。我們?cè)卺槍?duì)某個(gè)國產(chǎn)數(shù)據(jù)庫進(jìn)行分析的時(shí)候，發(fā)現(xiàn)隨著某些種類的并發(fā)負(fù)載增加，其runtime error也會(huì)增加，不過應(yīng)用的整體功能并未異常，只是部分SQL的執(zhí)行延時(shí)變得不穩(wěn)定了。
數(shù)據(jù)庫中存在某些錯(cuò)誤并不可怕，如果我們知道了這些錯(cuò)誤的根因與處置方案后，這些錯(cuò)誤就可以比較好的在日常運(yùn)維中應(yīng)對(duì)了。這兩天我們?cè)谧瞿硣a(chǎn)分布式數(shù)據(jù)庫的接口。這個(gè)產(chǎn)品是一個(gè)超級(jí)大樂高，是由相當(dāng)多的開源組件糅合而形成的，文檔寫的也相當(dāng)不好。不過有一份文檔寫的確實(shí)很好，那就是《應(yīng)急處置手冊(cè)》，里面羅列了五六十個(gè)常見應(yīng)急處置場景，對(duì)每個(gè)場景的表現(xiàn)，驗(yàn)證方式，處置方式都做了詳細(xì)的介紹。從文檔的內(nèi)容上看，這些內(nèi)容應(yīng)該是從大量的實(shí)踐案例中總結(jié)出來的真實(shí)場景，對(duì)運(yùn)維人員運(yùn)維這套數(shù)據(jù)庫系統(tǒng)來說，十分有價(jià)值。這份文檔十分類似于我們的“故障模型”，我們利用這份文檔也可以十分快捷的構(gòu)建“運(yùn)維經(jīng)驗(yàn)”。
資源使用率是我們能夠最方便觀測到的系統(tǒng)狀態(tài)，系統(tǒng)資源使用率的觀察主要用途有幾個(gè)方面，一方面是發(fā)現(xiàn)異常，一個(gè)數(shù)據(jù)庫系統(tǒng)的資源使用率變化會(huì)有一定的規(guī)律，發(fā)生背離的情況往往預(yù)示著系統(tǒng)可能存在某些異常。白天業(yè)務(wù)高峰時(shí)CPU使用率從平均50%突變?yōu)槠骄^90%，如果持續(xù)時(shí)間較長，那么一定是系統(tǒng)出現(xiàn)了什么異常，而如果今天突然變得低于20%了，是不是也是一種異常呢？
我想大概率是的。系統(tǒng)資源使用率觀察的第二個(gè)用途就是容量管理。我們需要為系統(tǒng)的擴(kuò)容與建設(shè)發(fā)展制定策略，因此我們會(huì)關(guān)注使用率的變化，以及使用率與業(yè)務(wù)增量之間的額關(guān)系，從而推斷出硬件擴(kuò)容的最佳時(shí)機(jī)。過早擴(kuò)容意味著更高的成本，過晚擴(kuò)容可能會(huì)導(dǎo)致SLA無法保證，因此選取最合適的擴(kuò)容時(shí)機(jī)對(duì)于企業(yè)IT運(yùn)營中獲得較好的成本效益十分關(guān)鍵。
除此之外，觀測可以采用直接觀測，也可以采用間接觀測。昨天一個(gè)客戶問我，我們的D-SMART能不能對(duì)SQL的執(zhí)行計(jì)劃變化做實(shí)時(shí)跟蹤，當(dāng)某個(gè)SQL的執(zhí)行計(jì)劃走歪的時(shí)候能夠立即發(fā)現(xiàn)。我回答說，一些大型系統(tǒng)，每秒執(zhí)行的SQL數(shù)量是幾萬甚至幾十萬，要對(duì)每條SQL的執(zhí)行計(jì)劃進(jìn)行實(shí)時(shí)追蹤，成本太大。我們可以采用一些變通的方法來發(fā)現(xiàn)執(zhí)行計(jì)劃走歪的問題，而不必要去TRACE每條SQL的執(zhí)行計(jì)劃。如果一條SQL存在多種執(zhí)行計(jì)劃，而且走了一種比較差的執(zhí)行計(jì)劃，那么系統(tǒng)的邏輯讀、物理讀、活躍會(huì)化數(shù)、并發(fā)執(zhí)行的SQL總數(shù)等都會(huì)發(fā)生變化，我們只要能夠發(fā)現(xiàn)這些異常就可以通過根因定位找到某條SQL的執(zhí)行計(jì)劃變壞了。
網(wǎng)站標(biāo)題：如何利用數(shù)據(jù)庫的可觀測性能力
鏈接地址：http://m.fisionsoft.com.cn/article/dpjspsc.html
