昨天一個(gè)朋友在微信群中問(wèn)我數(shù)據(jù)庫(kù)的指標(biāo)告警的故障收斂怎么做才能真正落地。說(shuō)實(shí)在的，雖然現(xiàn)在很多做智能化運(yùn)維的企業(yè)都號(hào)稱能實(shí)現(xiàn)很好的故障告警收斂，不過(guò)都是場(chǎng)景受限的。大多數(shù)情況下是在一套系統(tǒng)中，針對(duì)系統(tǒng)中多個(gè)IT組件的故障根據(jù)時(shí)間、先后順序、以及波動(dòng)曲線以及相關(guān)性要素等，通過(guò)算法進(jìn)行收斂。這種收斂在有些場(chǎng)景下是有效的，不過(guò)也存在一定的誤判和遺漏，不過(guò)總體來(lái)說(shuō)還是可用的，是具有一定的實(shí)戰(zhàn)作用的。

網(wǎng)友的問(wèn)題并不是在一個(gè)系統(tǒng)中如何歸并各個(gè)IT組件對(duì)于同一個(gè)問(wèn)題的告警，而是針對(duì)某一個(gè)具體的運(yùn)維對(duì)象，他特指的是數(shù)據(jù)庫(kù)。如果把這個(gè)問(wèn)題放到一個(gè)具體的運(yùn)維對(duì)象上去看，比如DBA面對(duì)的數(shù)據(jù)庫(kù)系統(tǒng)，那么這個(gè)問(wèn)題就完全不是一碼事了。當(dāng)時(shí)那個(gè)朋友舉例說(shuō)系統(tǒng)中CPU 使用率98%，表空間使用率99%，應(yīng)用響應(yīng)時(shí)間異常，這個(gè)情況如何進(jìn)行告警收斂呢?

在我們的實(shí)際生產(chǎn)環(huán)境中，可能問(wèn)題更為復(fù)雜，因?yàn)榻^大多數(shù)IT系統(tǒng)都是帶病工作的，我們稱之為亞健康狀態(tài)。系統(tǒng)的亞健康狀態(tài)往往在實(shí)際生產(chǎn)環(huán)境中是常態(tài)，只是這些小毛病并不會(huì)掀起大浪，因此我們也不去關(guān)注，甚至無(wú)法感知，也不一定需要立即去做閉環(huán)解決。

不過(guò)就像大量的無(wú)癥狀新冠感染者隱藏在人群中一樣，因?yàn)樽陨頉](méi)有發(fā)病，并沒(méi)有引起社區(qū)或者社會(huì)的關(guān)注，如果我們不去做全員核酸檢測(cè)，那么這些可能釀成重大傳播危險(xiǎn)的潛在威脅我們是感知不到的，只有檢測(cè)或者出現(xiàn)了有癥狀的患者，周邊才能感知到。

不過(guò)系統(tǒng)的監(jiān)控與運(yùn)維是一個(gè)十分復(fù)雜的東西，除了管理規(guī)程，還有成本問(wèn)題。因此我們總是會(huì)把主要的成本放在急需解決的問(wèn)題上，對(duì)于不是特別重要的告警信息，大多數(shù)企業(yè)已經(jīng)沒(méi)有能力去做閉環(huán)管理了。想象一下，如果一個(gè)人管理數(shù)十個(gè)甚至上百個(gè)數(shù)據(jù)庫(kù)系統(tǒng)，你能不能對(duì)每天產(chǎn)生的數(shù)千個(gè)甚至上萬(wàn)個(gè)告警信息去做閉環(huán)管理?

實(shí)際上在實(shí)際生產(chǎn)環(huán)境，即使是已經(jīng)暴露出來(lái)的一些問(wèn)題，比如說(shuō)CPU 使用率98%，就一定說(shuō)明系統(tǒng)有問(wèn)題嗎?表空間使用率99%，也不意味著一定就有問(wèn)題，如果某個(gè)表空間放置的是靜態(tài)數(shù)據(jù)，或者說(shuō)數(shù)據(jù)文件是自動(dòng)擴(kuò)展的，那么表空間使用率100%也不是什么大問(wèn)題。

我們來(lái)看上面的例子，USERS表空間的使用率是97.75,容量是32GB，實(shí)際上如果從Oracle的dba_free_space來(lái)看，這個(gè)表空間已經(jīng)是100%了，只是因?yàn)檫@個(gè)數(shù)據(jù)文件是自動(dòng)擴(kuò)展的，監(jiān)控系統(tǒng)自動(dòng)根據(jù)ASM磁盤組的容量給這個(gè)表空間賦予了32GB的動(dòng)態(tài)容量，同時(shí)自動(dòng)將表空間使用率調(diào)整為97.75。

從這個(gè)動(dòng)態(tài)調(diào)整來(lái)看，首先我們要關(guān)注的是指標(biāo)的準(zhǔn)確性和有效性。因?yàn)锳UTOEXTEND功能的存在，以及ASM磁盤組對(duì)文件EXTEND的限制，如何計(jì)算準(zhǔn)使用率是十分關(guān)鍵的。這個(gè)指標(biāo)不準(zhǔn)確，那么后面的監(jiān)控報(bào)警都成為十分虛幻的事情了。

除了指標(biāo)的準(zhǔn)確性，我們還需要關(guān)注什么呢?實(shí)際上很多指標(biāo)并不能很好的指示風(fēng)險(xiǎn)，比如說(shuō)表空間使用率的問(wèn)題。我們?cè)賮?lái)看看下面的例子。

我們可以看到，我們引入了一個(gè)“表空間容量風(fēng)險(xiǎn)”這個(gè)評(píng)估指標(biāo)，并通過(guò)這個(gè)指標(biāo)來(lái)給表空間使用風(fēng)險(xiǎn)報(bào)警，這個(gè)指標(biāo)比表空間使用率具有更高的準(zhǔn)確性。整個(gè)系統(tǒng)的表空間使用率風(fēng)險(xiǎn)是0，這是最低的等級(jí)，表明沒(méi)有任何風(fēng)險(xiǎn)，剛才我們看到的97.75%使用率的USERS表空間的風(fēng)險(xiǎn)等級(jí)也是如此。

為什么會(huì)這樣呢?USERS表空間中存儲(chǔ)的大多數(shù)是只讀數(shù)據(jù)，增長(zhǎng)率極低，每次增長(zhǎng)的數(shù)量也很小，當(dāng)前不擴(kuò)容還可以用很長(zhǎng)時(shí)間，那么這時(shí)候就沒(méi)必要馬上報(bào)警了。這種評(píng)估可以大幅度減少誤報(bào)，不過(guò)也可能會(huì)帶來(lái)新的問(wèn)題，那就是如果有人想往USERS表空間里導(dǎo)入大量的數(shù)據(jù)，那么馬上就會(huì)報(bào)錯(cuò)。因此這種表空間使用率較高的情況，也不能完全忽略。我們會(huì)在日檢、周報(bào)和月報(bào)里指出這個(gè)問(wèn)題，而不是在日常的告警中不斷的去告警，這樣也能夠起到提醒運(yùn)維人員的作用，而不需要半夜發(fā)個(gè)短信讓人虛驚一場(chǎng)。

從上面的例子可以看出，準(zhǔn)確而有效的指標(biāo)體系是實(shí)現(xiàn)故障報(bào)警收斂的最基礎(chǔ)的工作，實(shí)際上指標(biāo)準(zhǔn)確性也可以大大提高告警準(zhǔn)確性，從而減少運(yùn)維成本。有了這一步之后，后面該怎么走呢?我們?cè)倩氐角懊嬲f(shuō)的例子。應(yīng)用變慢，是正常的慢還是不正常的慢?這三個(gè)指標(biāo)異常之間存在關(guān)聯(lián)嗎?存在什么樣的關(guān)聯(lián)呢?

實(shí)際上，如果要針對(duì)這個(gè)場(chǎng)景去做告警收斂，還是脫離不了專家經(jīng)驗(yàn)和實(shí)際運(yùn)行環(huán)境中的系統(tǒng)運(yùn)行特征。對(duì)于數(shù)據(jù)庫(kù)來(lái)說(shuō)，如果表空間滿了無(wú)法寫(xiě)入數(shù)據(jù)，那么應(yīng)用會(huì)報(bào)錯(cuò)，同時(shí)系統(tǒng)負(fù)載是會(huì)下降的，數(shù)據(jù)庫(kù)的并發(fā)負(fù)載會(huì)下降，甚至CPU使用率可能會(huì)出現(xiàn)斷崖式的下降。某些系統(tǒng)一旦出現(xiàn)無(wú)法寫(xiě)入數(shù)據(jù)，則會(huì)話會(huì)重新啟動(dòng)，那么數(shù)據(jù)庫(kù)的新建連接數(shù)會(huì)增加，因?yàn)閿?shù)據(jù)庫(kù)無(wú)法寫(xiě)入，因此新建連接會(huì)全部失敗，連接失敗率會(huì)出現(xiàn)急劇上升，而只讀應(yīng)用依然會(huì)正常。

如果我們能夠梳理出這種場(chǎng)景，那么我們就肯定能夠把此類場(chǎng)景的十幾個(gè)指標(biāo)異常進(jìn)行很好的歸類，收斂成一個(gè)告警，并直接告知故障根因。如果再加上這些指標(biāo)的異常檢測(cè)，能夠根據(jù)這些指標(biāo)的時(shí)間序列進(jìn)行再分類，那么就能夠更加精準(zhǔn)的收斂故障場(chǎng)景，其告警準(zhǔn)確性又可以上一個(gè)臺(tái)階。這種運(yùn)行特征的梳理可以采用專家根據(jù)以往的故障案例或者經(jīng)驗(yàn)進(jìn)行梳理，也可以通過(guò)算法自動(dòng)對(duì)場(chǎng)景進(jìn)行分類抽象。

再回到CPU使用率高的問(wèn)題上，如果CPU使用率在某個(gè)工作窗口上的某一次或者幾次突然升高，并不一定是數(shù)據(jù)庫(kù)系統(tǒng)或者應(yīng)用出現(xiàn)了必須由運(yùn)維人員干預(yù)的問(wèn)題，不過(guò)如果CPU使用率持續(xù)高于平時(shí)的情況，或者突然CPU使用率遠(yuǎn)遠(yuǎn)低于某個(gè)基準(zhǔn)，這時(shí)候意味著系統(tǒng)出現(xiàn)問(wèn)題的機(jī)會(huì)遠(yuǎn)遠(yuǎn)高于某個(gè)或者某幾個(gè)采樣點(diǎn)出現(xiàn)高值。

因此我們就不應(yīng)該直接使用CPU使用率這個(gè)指標(biāo)來(lái)進(jìn)行告警，而是通過(guò)實(shí)時(shí)計(jì)算，生成一個(gè)CPU使用率過(guò)高風(fēng)險(xiǎn)或者CPU使用率異常風(fēng)險(xiǎn)這樣的指標(biāo)來(lái)進(jìn)行預(yù)警，這樣會(huì)有更好的效果。當(dāng)然，在實(shí)際的實(shí)現(xiàn)中，可以構(gòu)建出一系列的規(guī)則模型或者專家模型，通過(guò)這些模型來(lái)描述一個(gè)場(chǎng)景，比把每個(gè)場(chǎng)景都做成指標(biāo)成本要低得多。

一些通用型的故障場(chǎng)景，往往可以做成獨(dú)立的指標(biāo)，從而降低分析的復(fù)雜性。

而對(duì)于一些非通用的，和系統(tǒng)有關(guān)的，或者用戶私有的故障模型，則可以通過(guò)其他的方式去構(gòu)建。一旦這些故障模型被構(gòu)建起來(lái)之后，我們就可以不去關(guān)注指標(biāo)和基線的預(yù)警了。運(yùn)維人員只需要面對(duì)故障模型的預(yù)警去做閉環(huán)管理，這樣也是實(shí)現(xiàn)故障告警收斂的一種實(shí)現(xiàn)方法。在一個(gè)實(shí)際的案例中，一個(gè)具有100多套系統(tǒng)，數(shù)百個(gè)數(shù)據(jù)庫(kù)、中間件的運(yùn)行環(huán)境中，每天只會(huì)收到數(shù)十個(gè)告警，其中需要立即閉環(huán)處理的事件基本上是個(gè)位數(shù)。

當(dāng)然這種方法也存在缺陷，那就是會(huì)遺漏一些未知的風(fēng)險(xiǎn)。我們采取了健康模型告警的方式來(lái)做彌補(bǔ)。當(dāng)系統(tǒng)的健康度急劇下降的時(shí)候，會(huì)產(chǎn)生一種模糊狀態(tài)報(bào)警。這種報(bào)警需要運(yùn)維人員去做狀態(tài)巡檢，從而定位問(wèn)題。如果定位出了明確的問(wèn)題，那么就可以再次抽象成新的故障模型。通過(guò)這樣不斷的迭代，讓我們的運(yùn)維告警越來(lái)越精準(zhǔn)。