運維思考 | 你知道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全球運維大會：運維巔峯時代，研運中臺或是惟一選擇