運維思考 | 你知道CMDB與監控是什麼關係嗎？

• 2019 年 12 月 4 日
• 筆記

企業隨著業務的發展以及新IT技術的不斷引入，應用系統的IT資源規模是越來越大，IT架構的複雜性也與日俱增。這種情況下，需要通過多種監控系統，不同的途徑來感知業務系統活沒活，活的好不好，用戶體驗怎樣。常見的監控系統類型就包括：基礎環境監控、網路監控、系統監控、資料庫監控、應用監控、用戶體驗監控等等。

在這種場景下，我們在之前的文章《如何改善監控問題，試試打造企業統一監控平台體系！》一文中探討過，就需要一個統一的監控中台來對下管理多個告警源，中間進行告警數據的處理，對上提供可消費的監控數據。整體架構圖如下所示：

這裡就會存在一個問題，監控和企業的CMDB之間是怎樣的關係呢？

CMDB與監控

我們的理解有如下兩層關係：

• CMDB需要為監控系統提供必要的支撐數據，來收斂、立體化、標準化告警資訊。
• CMDB也需要打通到監控系統的通道，在新的對象加入CMDB的時候能夠自動將該對象加入監控系統；同時在配置數據發生變化的時候，能夠通過監控系統發出必要的告警資訊。

我們先展開聊下第一層關係。監控系統，比如zabbix，在某個對象的某個監控指標達到閾值時候，會出發告警：XX對象的XX指標告警和詳情資訊等。並且可以在zabbix中配置監控項之間的依賴關係，實現告警的收斂和關聯。

但是這裡有一個問題，我們設想一個場景：你是一家大型2C公司的DBA，冬夜凌晨3點鐘，外面西北風凜冽，突然手機鈴聲大作，有告警資訊提示應用系統A資料庫節點01出現連接異常告警。告警資訊提示內容有限，此時的你是否要起來打開電腦做進一步的處理呢？

很糾結，對吧。其實作為管理員，收到這條告警資訊的時候，除了需要知道這個資料庫有問題，其實還想知道更多的資訊，比如：這個資料庫屬於什麼應用系統、位於什麼環境、是否是高可用的集群、應用負責人是誰、哪些應用系統需要依賴這個應用系統、這個資料庫最新是否有配置變更發生等等，以便做出進一步的判斷和安排下一步的操作：比如在大冬天的凌晨，要不要起來打開電腦。那麼這個時候，我們就需要一個系統能夠提供：應用層次拓撲、集群資訊、模組資訊、資源實例、關聯關係等資訊，這個系統就是CMDB。

兩者的集成與融合

有了CMDB之後，在告警發生的時候呢，我們就可以讓告警系統前往CMDB中查詢跟這一告警對象有關的綜合配置資訊，以便提供最為準確、豐富和標準的告警資訊。舉例來說，上個場景中，如果我們知道資料庫實例01是屬於應用系統A的測試環境的，並且有高可用集群，當前理論上是沒有用戶訪問這個資料庫的，管理員又何苦受凍起床開電腦呢？

反過來講，如果發現這個資料庫是系統A的生產環境的資料庫，並且由於最近在升級，當前是單點模式，同時還有系統B和C需要依賴系統A，那就趕緊麻溜的起來處理故障，並通知B和C啟動相應的預案機制以儘可能降低影響。

這裡，就需要CMDB具備提供數據給監控系統的能力，需要具備相應的數據查詢、讀取的介面資訊，並且能夠方便的集成。

另外一方面，CMDB也需要主動同步自己的數據到監控系統中。舉個例子，我們上線了某個系統的一批新的虛擬機節點，提完工單，錄完CMDB配置資訊，再手動到監控裡面配置一遍嗎？顯然不是很合理，對吧？這個時候就需要CMDB能夠主動將新的對象資訊推送給監控系統，監控系統按照既有監控模板，下發agent、配置監控協議、啟動監控等。

另外，如果CMDB通過掃描發現某個主機的實際配置資訊與當前CMDB庫中存儲的資訊不一致，是不是也應該通過監控系統告警出來，通知到管理員進一步處理呢？

所以這裡你看，監控系統與CMDB之間是緊密關聯的。而更要命的是企業裡面往往監控系統不只一個，如果每個監控系統都要與CMDB做一遍集成，非累死不可。這裡面就需要有監控中台和統一告警管理的概念，我們不需要每個監控系統直接與CMDB集成，只需要把所有的監控系統接入到統一告警中心模組中來，由統一告警模組來與CMDB監控對接，共享資訊。這樣，我們的每一條告警在發出的時候，都可以依據CMDB中的資訊，變成標準化、立體化的告警，而不是扁平的告警。這樣的告警才能真正凸顯價值。

作者：趙海兵