昨天一個朋友在微信群中問我數據庫的指標告警的故障收斂怎么做才能真正落地。說實在的，雖然現在很多做智能化運維的企業都號稱能實現很好的故障告警收斂，不過都是場景受限的。大多數情況下是在一套系統中，針對系統中多個IT組件的故障根據時間、先后順序、以及波動曲線以及相關性要素等，通過算法進行收斂。這種收斂在有些場景下是有效的，不過也存在一定的誤判和遺漏，不過總體來說還是可用的，是具有一定的實戰作用的。

網友的問題并不是在一個系統中如何歸并各個IT組件對于同一個問題的告警，而是針對某一個具體的運維對象，他特指的是數據庫。如果把這個問題放到一個具體的運維對象上去看，比如DBA面對的數據庫系統，那么這個問題就完全不是一碼事了。當時那個朋友舉例說系統中CPU 使用率98%，表空間使用率99%，應用響應時間異常，這個情況如何進行告警收斂呢?

在我們的實際生產環境中，可能問題更為復雜，因為絕大多數IT系統都是帶病工作的，我們稱之為亞健康狀態。系統的亞健康狀態往往在實際生產環境中是常態，只是這些小毛病并不會掀起大浪，因此我們也不去關注，甚至無法感知，也不一定需要立即去做閉環解決。

不過就像大量的無癥狀新冠感染者隱藏在人群中一樣，因為自身沒有發病，并沒有引起社區或者社會的關注，如果我們不去做全員核酸檢測，那么這些可能釀成重大傳播危險的潛在威脅我們是感知不到的，只有檢測或者出現了有癥狀的患者，周邊才能感知到。

不過系統的監控與運維是一個十分復雜的東西，除了管理規程，還有成本問題。因此我們總是會把主要的成本放在急需解決的問題上，對于不是特別重要的告警信息，大多數企業已經沒有能力去做閉環管理了。想象一下，如果一個人管理數十個甚至上百個數據庫系統，你能不能對每天產生的數千個甚至上萬個告警信息去做閉環管理?

實際上在實際生產環境，即使是已經暴露出來的一些問題，比如說CPU 使用率98%，就一定說明系統有問題嗎?表空間使用率99%，也不意味著一定就有問題，如果某個表空間放置的是靜態數據，或者說數據文件是自動擴展的，那么表空間使用率100%也不是什么大問題。

我們來看上面的例子，USERS表空間的使用率是97.75,容量是32GB，實際上如果從Oracle的dba_free_space來看，這個表空間已經是100%了，只是因為這個數據文件是自動擴展的，監控系統自動根據ASM磁盤組的容量給這個表空間賦予了32GB的動態容量，同時自動將表空間使用率調整為97.75。

從這個動態調整來看，首先我們要關注的是指標的準確性和有效性。因為AUTOEXTEND功能的存在，以及ASM磁盤組對文件EXTEND的限制，如何計算準使用率是十分關鍵的。這個指標不準確，那么后面的監控報警都成為十分虛幻的事情了。

除了指標的準確性，我們還需要關注什么呢?實際上很多指標并不能很好的指示風險，比如說表空間使用率的問題。我們再來看看下面的例子。

我們可以看到，我們引入了一個“表空間容量風險”這個評估指標，并通過這個指標來給表空間使用風險報警，這個指標比表空間使用率具有更高的準確性。整個系統的表空間使用率風險是0，這是最低的等級，表明沒有任何風險，剛才我們看到的97.75%使用率的USERS表空間的風險等級也是如此。

為什么會這樣呢?USERS表空間中存儲的大多數是只讀數據，增長率極低，每次增長的數量也很小，當前不擴容還可以用很長時間，那么這時候就沒必要馬上報警了。這種評估可以大幅度減少誤報，不過也可能會帶來新的問題，那就是如果有人想往USERS表空間里導入大量的數據，那么馬上就會報錯。因此這種表空間使用率較高的情況，也不能完全忽略。我們會在日檢、周報和月報里指出這個問題，而不是在日常的告警中不斷的去告警，這樣也能夠起到提醒運維人員的作用，而不需要半夜發個短信讓人虛驚一場。

從上面的例子可以看出，準確而有效的指標體系是實現故障報警收斂的最基礎的工作，實際上指標準確性也可以大大提高告警準確性，從而減少運維成本。有了這一步之后，后面該怎么走呢?我們再回到前面說的例子。應用變慢，是正常的慢還是不正常的慢?這三個指標異常之間存在關聯嗎?存在什么樣的關聯呢?

實際上，如果要針對這個場景去做告警收斂，還是脫離不了專家經驗和實際運行環境中的系統運行特征。對于數據庫來說，如果表空間滿了無法寫入數據，那么應用會報錯，同時系統負載是會下降的，數據庫的并發負載會下降，甚至CPU使用率可能會出現斷崖式的下降。某些系統一旦出現無法寫入數據，則會話會重新啟動，那么數據庫的新建連接數會增加，因為數據庫無法寫入，因此新建連接會全部失敗，連接失敗率會出現急劇上升，而只讀應用依然會正常。

如果我們能夠梳理出這種場景，那么我們就肯定能夠把此類場景的十幾個指標異常進行很好的歸類，收斂成一個告警，并直接告知故障根因。如果再加上這些指標的異常檢測，能夠根據這些指標的時間序列進行再分類，那么就能夠更加精準的收斂故障場景，其告警準確性又可以上一個臺階。這種運行特征的梳理可以采用專家根據以往的故障案例或者經驗進行梳理，也可以通過算法自動對場景進行分類抽象。

再回到CPU使用率高的問題上，如果CPU使用率在某個工作窗口上的某一次或者幾次突然升高，并不一定是數據庫系統或者應用出現了必須由運維人員干預的問題，不過如果CPU使用率持續高于平時的情況，或者突然CPU使用率遠遠低于某個基準，這時候意味著系統出現問題的機會遠遠高于某個或者某幾個采樣點出現高值。

因此我們就不應該直接使用CPU使用率這個指標來進行告警，而是通過實時計算，生成一個CPU使用率過高風險或者CPU使用率異常風險這樣的指標來進行預警，這樣會有更好的效果。當然，在實際的實現中，可以構建出一系列的規則模型或者專家模型，通過這些模型來描述一個場景，比把每個場景都做成指標成本要低得多。

一些通用型的故障場景，往往可以做成獨立的指標，從而降低分析的復雜性。

而對于一些非通用的，和系統有關的，或者用戶私有的故障模型，則可以通過其他的方式去構建。一旦這些故障模型被構建起來之后，我們就可以不去關注指標和基線的預警了。運維人員只需要面對故障模型的預警去做閉環管理，這樣也是實現故障告警收斂的一種實現方法。在一個實際的案例中，一個具有100多套系統，數百個數據庫、中間件的運行環境中，每天只會收到數十個告警，其中需要立即閉環處理的事件基本上是個位數。

當然這種方法也存在缺陷，那就是會遺漏一些未知的風險。我們采取了健康模型告警的方式來做彌補。當系統的健康度急劇下降的時候，會產生一種模糊狀態報警。這種報警需要運維人員去做狀態巡檢，從而定位問題。如果定位出了明確的問題，那么就可以再次抽象成新的故障模型。通過這樣不斷的迭代，讓我們的運維告警越來越精準。