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

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

在這種場景下，我們在之前的文章《如何改善監控問題，試試打造企業統一監控平臺體系！》

一文中探討過，就需要一個統一的監控中臺來對下管理多個告警源，中間進行告警數據的處理，對上提供可消費的監控數據。整體架構圖如下所示：

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?

▲統一監控能力架構

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

CMDB與監控

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

• CMDB需要為監控系統提供必要的支撐數據，來收斂、立體化、標準化告警信息。
  

• CMDB也需要打通到監控系統的通道，在新的對象加入CMDB的時候能夠自動將該對象加入監控系統；同時在配置數據發生變化的時候，能夠通過監控系統發出必要的告警信息。
  

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

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

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

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?

▲CMDB配置管理

兩者的集成與融合

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

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

這里，就需要CMDB具備提供數據給監控系統的能力，需要具備相應的數據查詢、讀取的接口信息，并且能夠方便的集成。

▲藍鯨API網關&CMDB的API接口列表

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

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

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

作者：趙海兵

—END—

往期回顧

【干貨】4種Oracle DBaaS部署模式，你在使用哪一種？

如何改善監控問題，試試打造企業統一監控平臺體系！

云計算 | 數據在云上安全嗎？DDoS***怎么辦？

如何基于TAPD實踐Scrum的敏捷開發？

嘉為出席GOPS全球運維大會：運維巔峰時代，研運中臺或是唯一選擇